UPF与PFCP：把“指挥”和“搬运”分开的艺术

在前几轮我们讲过调制、波束、切换这些“空口侧”的原理。这一次我们钻进核心网，看一个5G网络里真正“搬数据包”的网元——UPF（User Plane Function，用户面功能），以及它和“大脑”SMF之间那套精巧的协作机制：PFCP协议与PDR/FAR转发规则模型。

这是5G核心网里最贴近“转发路由器”的部分，也是边缘计算、本地分流、话单计费这些现网功能的物理基础。理解了它，你看抓包里满屏的PFCP消息时，看到的就不再是神秘的十六进制，而是一条条清晰的“指令清单”。

一、从一个外卖类比说起：中央厨房为什么要拆成“厨房+前置仓”

假设你经营一个全国连锁的外卖品牌，有两种组织方式：

方式A（一体化模式）：每家门店既是厨房又是收银台又是配送站。菜谱更新、促销策略、菜品研发全部在这家店里完成。问题是——总部想统一调整一个促销规则，就得挨个通知几千家门店；顾客在城东下单，可能因为调度逻辑被分配到城西的中央厨房出餐，绕了一大圈。

方式B（分离模式）：总部只管“定规则”——菜单、价格、配送策略；城市里布满前置仓/卫星店，只管“照单执行”——按总部下发的规则出餐、打包、就近配送。规则改动只需总部下发一次，所有站点立即生效；顾客永远由离他最近的站点服务。

4G时代的一体化网关（SGW/PGW合设的“大网关”）就是方式A：控制逻辑和转发引擎焊死在一起。流量爆炸后，两个问题越来越痛：

1. 转发路径绕远：网关部署集中，用户在广东上网，数据可能要回到北方的省级网关再出去，时延和传输成本都高；
2. 扩容不对称：流量增长快但信令增长慢，想多加转发能力，却被迫连同控制逻辑一起扩容，投资效率低。

于是行业在4G后期引入了CUPS（Control and User Plane Separation，控制面与用户面分离）架构，5G将其继承为原生设计：SMF专心“定规则”，UPF专心“执行规则”，两者之间用一条标准接口通信。这条接口就是N4，其上跑的协议就是PFCP（Packet Forwarding Control Protocol，包转发控制协议）。

flowchart TB
    subgraph CP [控制面：定规则]
        SMF[SMF 会话管理功能]
    end
    subgraph UP [用户面：执行规则]
        UPF1[UPF 锚点1<br/>靠近核心侧]
        UPF2[UPF 锚点2<br/>靠近边缘/园区]
    end
    UE((手机UE)) -->|空口| RAN[gNB 基站]
    RAN -->|N3接口 GTP-U隧道| UPF1
    RAN -.->|N3接口 就近接入| UPF2
    UPF1 -->|N9接口 GTP-U隧道| UPF2
    UPF1 -->|N6接口| DN1[(数据网络<br/>互联网/中心云)]
    UPF2 -->|N6接口 本地卸载| DN2[(本地业务服务器<br/>园区/MEC)]
    SMF -->|N4接口 PFCP<br/>下发转发规则| UPF1
    SMF -->|N4接口 PFCP| UPF2
    UPF1 -.->|N4 会话事件上报| SMF

这张图里藏着CUPS最核心的两个设计红利，后面都会展开：

• 同一个SMF可以指挥多个UPF（图中的锚点1、锚点2），规则可以按需下发到任意一个；
• 用户流量可以就近从边缘UPF卸载（N6直接到本地服务器），这就是5G边缘计算在核心网侧的落点。

二、UPF到底干什么：它不是“高级路由器”

很多工程师初见UPF会说：“不就是个能跑GTP的路由器吗？”这个理解漏掉了它最关键的身份——一个按远程指令动态改变转发行为的策略执行点。普通路由器的转发表由路由协议收敛生成，规则是“全网拓扑”驱动的；而UPF的转发规则由SMF逐会话、逐业务流地下发，规则是“每个用户的每条业务”驱动的。

按功能性质，UPF的活可以分成三类：

第三类常被忽视，却解释了很多现网现象：手机待机被寻呼，根源就在UPF——下行数据到达UPF时若用户面未激活，UPF按规则缓存数据并向SMF上报“下行数据通知”，SMF再联动AMF发起寻呼。计费话单里的流量数，同样来自UPF按规则吐出的统计报告。

三、PFCP：一份可以远程“改菜谱”的协议

PFCP运行在UDP之上，知名端口是 8805（它是4G时代CUPS研究中原名"Sx"协议的正式继任者，所以老资料里会看到Sxa/Sxb/Sxc接口的说法）。它把SMF和UPF之间的交互分成两个层次，理解这个分层对排障极其重要：

1. 节点级流程（Node Related）——“两家店先建立合作关系”

• PFCP关联建立（Association Setup）：SMF与UPF初次见面，互相通报能力（我支持哪些特性、能处理哪些功能特性比特）。没有关联，一切会话规则都免谈。一个SMF可以同时关联多个UPF，一个UPF也可以被多个SMF管理（不同切片/不同DNN的场景）。
• 心跳（Heartbeat）：双方周期互探活。心跳连续多次无响应，SMF会判定该UPF失联，触发将其从服务列表摘除、把会话迁往备份UPF等保护动作。现网大量“用户突然全部掉线”的故障，根因就是N4心跳失败被误判。

2. 会话级流程（Session Related）——“给每一笔订单下具体指令”

每个PDU会话建立时，SMF通过PFCP会话建立请求把一组规则对象打包下发给选定的UPF；会话修改（如新增QoS流、切换后更新隧道端点）走会话修改请求；释放则走删除。UPF执行后逐条响应，成功或失败原因值都会带回。

sequenceDiagram
    participant UE as UE/基站
    participant SMF as SMF
    participant UPF as UPF
    participant DN as 数据网络

    Note over SMF,UPF: 阶段0：节点级（开机后一次性）
    SMF->>UPF: PFCP Association Setup
    UPF-->>SMF: Response（互相通报能力）
    loop 周期性
        SMF->>UPF: Heartbeat Request
        UPF-->>SMF: Heartbeat Response
    end

    Note over SMF,UPF: 阶段1：用户开机，PDU会话建立
    UE->>SMF: 请求建立PDU会话（经AMF中转N11）
    SMF->>UPF: PFCP Session Establishment Request<br/>（携带PDR+FAR+QER+URR规则包）
    UPF-->>SMF: Response（含UPF侧分配的上行F-TEID）
    SMF->>UE: 会话建立接受（经基站，含核心侧隧道信息）

    Note over UE,UPF: 阶段2：数据开始流动
    UE->>UPF: 上行GTP-U包（N3，外层TEID=UPF分配的F-TEID）
    UPF->>DN: 解封装后按FAR转发（N6）

    Note over SMF,UPF: 阶段3：事件触发反向交互
    DN->>UPF: 下行包到达（用户面空闲）
    UPF->>SMF: PFCP Session Report（下行数据通知）
    SMF->>UPF: 缓存指示（BAR联动）
    SMF-->>UE: 联动AMF对UE发起寻呼

注意时序图里一个容易忽略的细节：UPF在会话建立响应里会把自己分配的上行F-TEID带回SMF，SMF再通过基站的N2信令把它交给gNB。也就是说，N3隧道的“上行钥匙”是UPF造的，“下行钥匙”是gNB造的（经SMF用PFCP下发给UPF放进FAR）。抓包看到GTP-U的TEID对不上时，沿这条链路核对即可定位是哪一段配置/信令出了问题。

四、规则四件套：PDR、FAR、QER、URR（外加BAR）

这是本文的核心。SMF下发给UPF的不是一个笼统的“转发条目”，而是一组解耦的对象：识别（PDR）、动作（FAR）、限速（QER）、计量（URR）、缓存建议（BAR）。它们之间用ID互相引用，像乐高积木一样拼装。

PDR：识别是第一位的

PDI（Packet Detection Information）是PDR的“匹配条件集合”，可以包含：源接口（Access=N3侧来的、Core=N9侧来的、N6-LAN侧来的、CP-function=核心网自己发的）、F-TEID（隧道端点标识）、UE的IP地址、SDF过滤器（五元组/IP五元组通配的业务流描述）、QFI（QoS流标识）等。多个PDR共存时靠优先级值（Precedence）裁决，规则很简单：

$$\text{命中规则} = \arg\min_{p \in {\text{PDI匹配成功的PDR}}} \text{Precedence}(p)$$

即：在所有匹配的PDR里，取优先级数值最小者——数值越小越优先。这是排障时的黄金检查点：两条PDR范围重叠且优先级配置颠倒，流量就会持续走错规则，表现为“该本地卸载的流量上了中心机房”或“特定业务没被限速”。

FAR：五种动作

其中FORW的“外层包头创建”参数，就是GTP-U隧道封装的发源地：UPF给裸IP包套上外层UDP+GTP-U头，写入目的端TEID，扔向N3或N9对端。

QER与令牌桶：限速是怎么“限”出来的

QER对速率的执行，底层是经典的令牌桶算法：以速率 $r$ 向桶中匀速放令牌，桶容量上限 $B_{max}$，来一个包若桶中令牌足够（≥包长）则放行并扣减，否则丢弃或标记。任意时刻 $t$ 的令牌数为：

$$B(t) = \min\left(B_{max},\; B(t_0) + (t - t_0)\cdot r\right)$$

桶的存在允许短时突发（攒令牌一次性花），这正是“签约带宽100Mbps但瞬时抓包偶尔超过100Mbps”的原因——不是限速失效，而是令牌桶固有的突发容忍。QER还能分别对上、下行设置门控开关（开/关），实现“只准上行、禁止下行”这类门控语义。

URR：话单的源头

URR定义了“统计什么、何时上报”：按流量阈值、按周期、按事件触发。UPF累计计量后通过PFCP会话报告吐给SMF，SMF再转交计费系统生成话单。现网话单流量与实际流量对不上账，第一现场几乎都在URR——触发条件配错、阈值设置过大导致漏报、会话释放时机造成的尾包丢失，都是高频原因。

五、一个包的一生：UPF内部的流水线

把上面的积木拼起来，看一个上行数据包进入UPF后的完整旅程：

flowchart TB
    PKT[上行GTP-U包抵达N3口] --> P1{遍历PDR<br/>PDI逐字段匹配}
    P1 -->|无匹配| DROP1[静默丢弃]
    P1 -->|多个匹配| P2[取Precedence最小者]
    P2 --> RM[按PDR指令去除外层GTP-U/UDP头<br/>还原裸IP包]
    RM --> Q1{引用的QER门控是否放行?}
    Q1 -->|关闭| DROP2[丢弃]
    Q1 -->|开启| Q2{令牌桶是否够扣?}
    Q2 -->|不够| DROP3[丢弃或标记]
    Q2 -->|够| U1[URR累计流量统计]
    U1 --> F1{FAR动作类型?}
    F1 -->|FORW| ENC[按外层包头创建参数重新封装<br/>N6裸IP / N9再套GTP-U]
    ENC --> OUT[发往目的接口]
    F1 -->|BUFF| BUF[缓存+向SMF发会话报告]
    F1 -->|DUPL| DUP[复制发往监听探针+正常转发]
    F1 -->|DROP| DROP4[丢弃]

三条设计哲学值得咀嚼：

1. 识别与动作分离——换一个转发目的地只需SMF改下FAR，PDR原封不动；这让切换、本地分流开通变得轻量。
2. 规则集是逐会话私有的——一百万个PDU会话就是一百万套规则实例，UPF的数据结构设计（如用TEID做哈希索引快速定位PDR）直接决定其转发性能。
3. 一切观测皆有开关——不加URR就没有计量，不加监听规则就没有复制。性能调优时“关掉不必要的URR上报频率”是常用手段。

六、进阶：ULCL与本地分流——边缘计算的核心网引擎

有了“多UPF+逐流规则”的能力，5G玩出了一个精妙结构：在一条PDU会话路径上插入一个上行分类器（ULCL，Uplink Classifier）。它本身也是个UPF角色，靠PDR里的SDF过滤器识别特定业务（比如访问公司OA的流量），上行时把匹配流量“岔”到本地锚点UPF（PSA2）就近卸载，其余流量照旧送远端锚点（PSA1）。

flowchart LR
    UE((UE)) -->|N3| BP[UPF<br/>ULCL 分岔点]
    BP -->|匹配本地业务的流量<br/>N9| PSA2[本地锚点UPF PSA2]
    PSA2 -->|N6| LOC[(园区/边缘服务器)]
    BP -->|其余流量 N9| PSA1[中心锚点UPF PSA1]
    PSA1 -->|N6| NET[(互联网/中心云)]
    SMF2[SMF] -.PFCP统一指挥三个UPF.-> BP
    SMF2 -.-> PSA1
    SMF2 -.-> PSA2

对外，UE完全无感知——它始终以为自己只有一条会话、一个IP。对运营者，这意味着工业园区的视觉质检流量不出园区（低时延+数据合规），普通上网流量照走大网。这套能力的全部魔法，就是SMF往ULCL的PDR里多写了几条SDF过滤器规则。IPv6多归场景下的分支点（Branching Point）是同构的姊妹设计，只是按IPv6前缀而非五元组分岔。

七、现网实战：工程师会在哪里用到这些知识

排障场景一：整片用户突然断网，先查N4还是先查N3？ 看范围——如果SMF日志刷“PFCP心跳超时/关联释放”，是节点级问题（UPF宕机、防火墙拦了UDP 8805、N4网络抖动）；如果心跳正常但个别用户不通，是会话级问题（该用户的PDR/FAR安装失败、TEID冲突）。分层定位就是PFCP节点级/会话级分层在运维上的直接映射。

排障场景二：切换后用户面不通但信令全对。 九成是隧道端点错位：目标基站下行F-TEID没有正确写入UPF的FAR，或UPF新的上行F-TEID没有正确送达目标基站。抓N3包看GTP-U外层TEID，与PFCP会话修改消息里下发的值逐一比对，几分钟可定界。

排障场景三：“有些流量没走本地分流”。 检查ULCL上PDR的Precedence与SDF过滤器方向性。SDF过滤器是有方向语义的（描述的是上行流的五元组特征），把下行特征当上行配，规则永远命中不了。这是本地分流开通中最经典的配置陷阱。

常见误解三则： - “SMF挂了网络就断”——错。规则已安装在UPF上，存量会话的数据面会继续工作直到会话释放或规则到期；CUPS解耦的价值恰恰在此（但这不是SMF可以随意宕机的理由，新会话会受阻）。 - “UPF上看到的包都是解好的裸IP”——错。N3/N9方向收到的是双层封装（外层IP+UDP+GTP-U，内层UE IP），不剥外层直接按内层五元组匹配会莫名失配。 - “限速配置只影响下行”——错。QER上下行是独立的两套门控与令牌桶，只配下行会导致上行旁路。

常见问题

Q: PFCP和GTP-U的区别是什么？总有人混着说。 A: 完全不同层面的两个协议。PFCP是控制面协议，跑在SMF与UPF之间的N4口（UDP 8805），搬运的是“规则指令”；GTP-U是用户面隧道封装，跑在基站与UPF之间（N3）和UPF与UPF之间（N9），搬运的是“用户数据包”。类比：PFCP是总部下发的派单系统指令，GTP-U是外卖骑手保温箱里实际装的那份餐。

Q: PDR优先级（Precedence）配置冲突会怎样？怎么查？ A: 数值小的优先命中，且命中即止——不会报错、不会告警，流量“安静地”走错规则。排查方法：在UPF上导出生效规则表（多数商用UPF和开源UPF如free5GC/Open5GS都有调试接口），按目标流量特征手工走一遍匹配，找到被“抢走”命中的那条更高优先级PDR。

Q: 一条PDU会话为什么要分ULCL、PSA1、PSA2多个UPF？用户的IP在哪个上面？ A: 会话的IP锚点（分配UE IP的地方）在PSA上；ULCL和中间UPF不持有UE IP，只做识别与岔路。普通会话只有一个PSA；本地分流会话有两个PSA，两边的N6口都能以同一UE IP收发各自的流量。

Q: 心跳间隔应该配多短？是不是越短越安全？ A: 不是。心跳越短，故障发现越快，但N4面的信令负载越高，且网络轻微抖动就容易误判摘除UPF，引发会话迁移风暴。工程上通常取数十秒级间隔配合多次连续失败才判失效，关键在于心跳超时阈值要与N4网络的实际抖动水位匹配，而非一味求快。

Q: 4G的CUPS网关和5G的UPF是什么关系？ A: 同一思想的延续。4G后期把SGW/PGW拆成控制面（SGW-C/PGW-C）与用户面（SGW-U/PGW-U），用的正是PFCP前身（Sx）；5G把这套架构原生化，SGW-C+PGW-C合并演化为SMF，SGW-U/PGW-U统一为UPF。所以你会看到同一厂商的UPF产品通常同时支持4G/5G双模转发。

参考来源

2. Open5GS Documentation — 开源5G核心网官方文档，其SMF/UPF配置章节是验证PFCP参数（端口、心跳、会话规则）行为的可动手实验环境
3. free5GC Official Site — 开源5G核心网项目，可直接搭建UPF+SMF环境，用Wireshark抓PFCP包对照本文规则模型

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。