N4 PFCP四类规则链与包处理模型深度解析

一、引言：为什么N4是5GC用户面的"心脏"

5G核心网实现了控制面（CP）与用户面（UP）的彻底分离，而N4接口（PFCP协议，定义于TS 29.244）正是这条分割线上的"神经索"。SMF通过N4向UPF下发四类核心规则——PDR（包检测规则）、FAR（转发动作规则）、QER（QoS执行规则）和URR（使用量上报规则），构成一个精密的包处理流水线，决定每一个用户面报文的命运：识别、转发、限速、计费。

本文基于3GPP TS 29.244 V18.6.0（Release 18），深度解析PFCP会话建立过程中的规则链设计、包处理模型、规则关联机制及其工程实战要点。

二、PFCP会话建立全流程信令解析

2.1 前置条件：PFCP关联建立

PFCP会话建立之前，SMF与UPF必须先建立PFCP关联（PFCP Association）。根据TS 29.244 Section 5.8.1，一对CP/UP功能之间只能有一个PFCP关联，但一个SMF可与多个UPF建立关联，反之亦然。

sequenceDiagram
    participant SMF as SMF (CP)
    participant UPF as UPF (UP)

    Note over SMF,UPF: 阶段一：PFCP关联建立
    SMF->>UPF: PFCP Association Setup Request
    Note right of SMF: Node ID, CP Function Features,<br/>Recovery Time Stamp
    UPF->>SMF: PFCP Association Setup Response
    Note left of UPF: Node ID, UP Function Features,<br/>Recovery Time Stamp

    Note over SMF,UPF: 阶段二：PFCP会话建立（由PDU Session触发）
    SMF->>UPF: PFCP Session Establishment Request
    Note right of SMF: CP F-SEID, Create PDR,<br/>Create FAR, Create QER, Create URR,<br/>Create BAR(可选), UE IP Address
    UPF->>SMF: PFCP Session Establishment Response
    Note left of UPF: UP F-SEID, Cause,<br/>Created PDR (含F-TEID),<br/>Created URR (可选)

    Note over SMF,UPF: 阶段三：用户面数据传输激活
    Note over SMF,UPF: UL/DL数据可通过UPF转发

2.2 PFCP Session Establishment Request关键IE拆解

根据TS 29.244 Section 7.5.2，PFCP Session Establishment Request消息携带以下关键IE：

设计意图：PFCP采用"一次下发全套规则"的设计哲学，在Session Establishment Request中一次性下发所有PDR/FAR/QER/URR，避免多轮交互。这极大降低了PDU会话建立时延，但也意味着SMF必须精确计算所有规则参数。

三、四类规则链深度剖析

3.1 规则关联模型

根据TS 29.244 Section 5.2.1，PFCP的包处理模型基于PDR为核心节点的规则关联图：

graph LR
    PKT[入向报文] --> PDR1[PDR-1<br/>包检测规则]
    PKT --> PDR2[PDR-2<br/>包检测规则]
    PKT --> PDR3[PDR-3<br/>包检测规则]

    PDR1 -->|关联1个| FAR1[FAR<br/>转发动作规则]
    PDR1 -->|关联0..N个| QER1[QER<br/>QoS执行规则]
    PDR1 -->|关联0..N个| URR1[URR<br/>使用量上报规则]

    PDR2 -->|关联1个| FAR2[FAR]
    PDR2 -->|关联0..1个| QER2[QER]

    PDR3 -->|关联1个| FAR1

    FAR1 -->|可选关联| BAR[BAR<br/>缓存动作规则]
    FAR2 -->|可选关联| BAR

    style PDR1 fill:#e1f5fe
    style FAR1 fill:#f3e5f5
    style QER1 fill:#e8f5e9
    style URR1 fill:#fff3e0
    style BAR fill:#fce4ec

核心关联约束（TS 29.244 Section 5.2.1）：

1. 每个PDR必须关联恰好1个FAR —— 这是强制要求
2. 每个PDR可选关联0或多个QER —— QoS执行
3. 每个PDR可选关联0或多个URR —— 使用量测量
4. FAR可选关联BAR —— 缓存行为控制
5. FAR、QER、URR只能关联同一个PFCP会话内的PDR —— 跨会话隔离
6. 多个PDR可共享同一个FAR/QER/URR —— 规则复用

3.2 PDR：包检测规则（Packet Detection Rule）

PDR是整个包处理模型的入口和调度中心。根据TS 29.244 Section 5.2.1A.1，每个PDR包含一个PDI（Packet Detection Information），定义了如何匹配入向报文。

PDI匹配字段详解

PDR优先级与匹配规则

TS 29.244 Section 5.2.1定义了严格的PDR匹配优先级规则：

1. UPF首先识别PFCP会话（通过Local F-TEID、UE IP等确定属于哪个PDU会话）
2. 在同一PFCP会话内，按Precedence值从高到低查找 —— Precedence值越小优先级越高
3. 只有最高优先级的匹配PDR被选中 —— 找到第一个匹配PDR即停止查找
4. 未匹配任何PDR的报文应被丢弃

报文到达 → 识别PFCP会话 → 按Precedence排序PDR → 逐一匹配PDI → 首匹配即执行 → 关联FAR/QER/URR

设计博弈：Precedence机制允许同一会话内PDR重叠。例如一个精确匹配（五元组SDF）的PDR可以设置更高优先级，一个通配匹配（仅UE IP）的PDR设置更低优先级。这实现了"精确流优先，默认兜底"的分层策略。

3.3 FAR：转发动作规则（Forwarding Action Rule）

FAR告诉UPF"识别到报文后做什么"。根据TS 29.244 Section 5.2.3.1，通过Apply Action IE中的标志位控制：

FORW标志配套参数（Forwarding Parameters IE）：

关键设计：FAR中的转发参数（如Outer Header Creation）即使当前Apply Action设为BUFF也可以保留配置。这样UE从CM-IDLE回到CM-CONNECTED时，SMF只需修改Apply Action从BUFF→FORW，无需重新下发转发参数——一次修改替代完整重建，极大降低了信令开销。

3.4 QER：QoS执行规则（QoS Enforcement Rule）

QER执行门控、速率限制和QoS标记。根据TS 29.244 Section 5.2.5：

QER的分层设计：

graph TB
    subgraph "Session级QER"
        SQER["QER-1<br/>Session-AMBR<br/>UL/DL MBR"]
    end

    subgraph "Bearer/QoS Flow级QER"
        BQER1["QER-2<br/>GBR QoS Flow<br/>GBR+MBR+QFI"]
        BQER2["QER-3<br/>Non-GBR QoS Flow<br/>QFI only"]
    end

    subgraph "SDF级QER"
        SDQER["QER-4<br/>门控控制<br/>Gate Status"]
    end

    SQER -.->|"Session AMBR<br/>多PFCP会话共享"| BQER1
    SQER -.-> BQER2
    BQER1 --> SDQER

    style SQER fill:#e8f5e9
    style BQER1 fill:#c8e6c9
    style BQER2 fill:#c8e6c9
    style SDQER fill:#a5d6a7

关键机制——QER Correlation ID（TS 29.244 Section 5.2.1）：多个PFCP会话中的QER如果设置了相同的QER Correlation ID，UPF会将它们关联执行——这是实现Session-AMBR跨PDU会话限速的核心机制。例如一个UE有3个PDU会话，它们的Session-AMBR QER使用相同的Correlation ID，UPF在执行限速时会聚合计算所有PDU会话的总带宽。

3.5 URR：使用量上报规则（Usage Reporting Rule）

URR控制流量测量与计费上报。根据TS 29.244 Section 5.2.2：

Reporting Triggers关键触发条件：

四、包处理流水线：UPF内部处理顺序

UPF收到一个用户面报文后的完整处理流程（基于TS 29.244 Section 5.2.1 Figure 5.2.1-1）：

flowchart TD
    A[报文到达UPF] --> B[步骤1: 识别PFCP会话<br/>通过Local F-TEID / UE IP]
    B --> C[步骤2: PDR匹配查找<br/>按Precedence从高到低]
    C --> D{找到匹配PDR?}
    D -->|否| E[丢弃报文]
    D -->|是| F[步骤3: 执行关联QER<br/>门控检查→速率限制→QFI标记]
    F --> G{Gate Status = CLOSED?}
    G -->|是| H[丢弃报文<br/>可能触发URR丢弃计数]
    G -->|否| I[步骤4: 执行关联FAR<br/>Apply Action决定报文去向]
    I --> J{Apply Action}
    J -->|FORW| K[转发: 添加Outer Header→发送]
    J -->|DROP| L[丢弃报文]
    J -->|BUFF| M[缓存报文<br/>可选触发NOCP通知SMF]
    J -->|DUPL| N[复制报文→转发到监听接口]

    I --> O[步骤5: 更新关联URR<br/>流量统计/时间统计]
    O --> P[检查Reporting Triggers<br/>是否需要上报]
    P --> Q{触发上报?}
    Q -->|是| R[生成PFCP Session Report<br/>发送给SMF]
    Q -->|否| S[继续处理下一个报文]

处理顺序的精妙设计：

1. QER在FAR之前执行：先检查门控和限速，再做转发决策。如果门控关闭或超速，直接丢弃，节省转发处理开销
2. URR在FAR之后更新：只对实际被处理（转发/丢弃/缓存）的报文进行统计，确保计费准确
3. FAR的BUFF+NOCP组合：缓存DL数据并通知SMF，SMF触发寻呼唤醒UE，形成CM-IDLE→CM-CONNECTED的完整闭环

五、典型PDU会话的规则配置实例

以一个典型5G PDU会话（IPv4，含默认QoS Flow和一个GBR QoS Flow）为例，SMF在PFCP Session Establishment Request中下发以下规则集：

graph TB
    subgraph "上行规则 (Source Interface = ACCESS)"
        ULPDR1["UL PDR-1<br/>Precedence=100<br/>PDI: Local F-TEID + QFI=1<br/>(默认QoS Flow)"]
        ULPDR2["UL PDR-2<br/>Precedence=50<br/>PDI: Local F-TEID + QFI=2 + SDF<br/>(GBR QoS Flow)"]

        ULPDR1 --> ULFAR["UL FAR<br/>Apply Action=FORW<br/>Outer Header Creation:<br/>N6接口 → DN"]
        ULPDR2 --> ULFAR

        ULPDR1 --> SQER["Session QER<br/>Session-AMBR限制<br/>UL MBR=100Mbps"]
        ULPDR2 --> SQER
        ULPDR2 --> GQER["GBR QER<br/>GBR=10Mbps, MBR=20Mbps<br/>QFI=2"]

        ULPDR1 --> URR1["URR-1<br/>Volume + Duration<br/>Periodic上报"]
        ULPDR2 --> URR1
    end

    subgraph "下行规则 (Source Interface = CORE)"
        DLPDR1["DL PDR-1<br/>Precedence=100<br/>PDI: UE IP + QFI=1"]
        DLPDR2["DL PDR-2<br/>Precedence=50<br/>PDI: UE IP + QFI=2 + SDF"]

        DLPDR1 --> DLFAR["DL FAR<br/>Apply Action=FORW<br/>Outer Header Creation:<br/>N3接口 → gNB<br/>(GTP-U IP+TEID)"]
        DLPDR2 --> DLFAR

        DLPDR1 --> SQER2["Session QER<br/>Session-AMBR限制<br/>DL MBR=100Mbps"]
        DLPDR2 --> SQER2
        DLPDR2 --> GQER2["GBR QER<br/>QFI=2, RQI=0"]

        DLPDR1 --> URR2["URR-2<br/>Volume + Duration"]
        DLPDR2 --> URR2
    end

    style ULPDR1 fill:#e1f5fe
    style ULPDR2 fill:#e1f5fe
    style DLPDR1 fill:#fff3e0
    style DLPDR2 fill:#fff3e0

这个配置揭示了几个关键点：

1. UL和DL使用不同的PDR集，通过Source Interface区分方向
2. GBR QoS Flow的PDR优先级更高（Precedence=50 < 100），确保精确匹配的GBR流量优先处理
3. Session-AMBR的QER被多个PDR共享，UPF在限速时聚合计算
4. FAR中的Outer Header Creation对上行/下行不同：上行→N6接口去往DN，下行→N3接口去往gNB

六、F-TEID分配机制与运营商成本博弈

6.1 UPF侧F-TEID分配

根据TS 29.244 Section 5.5.1，F-TEID只能由UPF分配（5GC强制要求）。SMF在Create PDR IE的Local F-TEID中设置CHOOSE标志，请求UPF分配：

6.2 多PDR共享F-TEID

TS 29.244 Section 5.5.3允许SMF请求UPF为多个PDR分配相同的F-TEID——通过设置相同的CHOOSE ID值。这在以下场景中节省资源：

• 同一PDU会话的多个QoS Flow共用一个N3 GTP-U隧道
• 减少UPF的TEID池消耗
• 降低gNB侧隧道管理开销

但注意：共享F-TEID的PDR必须通过其他PDI字段（如QFI、SDF Filter）进行区分，否则会产生匹配冲突。

七、PDI优化（Traffic Endpoint）机制

TS 29.244 Section 5.2.1A.2引入了PDI优化特性，允许SMF将多个PDR中重复的匹配字段抽取为Traffic Endpoint：

实际收益：当一个PDU会话有10个PDR（多个SDF Filter），PDI优化可以将重复的Local F-TEID + UE IP + Network Instance从10次传输减至1次，信令开销减少约30-40%。对于大规模部署的运营商，这意味着SMF-UPF间的PFCP消息大小显著减小，处理延迟降低。

八、实战连接：抓包识别与故障排查

8.1 Wireshark抓包识别PFCP流程

PFCP使用UDP端口8805。关键过滤表达式：

# 过滤所有PFCP消息
udp.port == 8805

# 仅过滤PFCP Session Establishment Request (消息类型50)
pfcp.msg_type == 50

# 仅过滤PFCP Session Establishment Response (消息类型51)
pfcp.msg_type == 51

# 过滤特定SEID的会话
pfcp.seid == 0x1234567890abcdef

8.2 典型故障场景与排查

PFCP Session Establishment Response中的Cause值（TS 29.244 Section 8.2.1）是排错的核心入口：

十、常见问题

Q1: PFCP关联和PFCP会话是什么关系？ A: PFCP关联（Association）是SMF和UPF之间的传输层连接，在会话之前建立，一对SMF-UPF之间只有一个关联。PFCP会话（Session）对应一个PDU会话，一个关联上可以建立多个会话。关联建立时交换功能特性（Feature flags），会话建立时下发具体规则。

Q2: 为什么5GC要求F-TEID必须由UPF分配？ A: 这是TS 29.244 Section 5.5.1的强制要求。原因有三：(1) UPF是实际发送/接收GTP-U报文的节点，由它分配TEID可以保证本地唯一性；(2) 避免SMF和UPF的TEID池冲突；(3) 支持UPF故障恢复时重新分配F-TEID。在EPC中允许SMF侧分配，但5GC明确禁止。

Q3: PDR的Precedence值和4G中的precedence有什么区别？ A: 4G EPC中precedence在PCC规则中定义，由PCRF下发。5GC中PDR的Precedence由SMF根据PCC规则中的precedence映射设置，作用域限于同一PFCP会话内。不同PFCP会话的PDR之间不应重叠（TS 29.244 Section 5.2.1的约束），因此Precedence只解决同一会话内的匹配优先级冲突。

Q4: 多个PDR能否共享同一个QER？共享时限速怎么算？ A: 可以。TS 29.244 Section 5.2.1明确允许一个QER关联多个PDR。共享QER时，UPF将所有关联PDR匹配到的流量聚合计算。例如Session-AMBR QER关联了默认QoS Flow和IMS QoS Flow的PDR，UPF会将两者的带宽合并计算，确保总速率不超过Session-AMBR。

Q5: PFCP Session Modification和Session Establishment在规则处理上有什么核心区别？ A: Session Establishment是全量下发，所有规则从头创建。Session Modification是增量修改——根据TS 29.244 Section 5.6.3，SMF只需下发变更部分，UPF保持未变更的参数不变。这极大降低了后续QoS调整、策略更新时的信令开销。删除IE时可通过设length=0或使用Remove IE。

参考来源

1. 3GPP TS 29.244 V18.6.0 — PFCP协议规范，Section 5.2.1包处理模型、Section 5.2.3 FAR处理、Section 7.5.2会话建立消息定义
2. 3GPP TS 23.501 V18.x — 5G系统架构，Section 5.8.2 UPF功能、Section 6.3 N4参考点定义
3. 3GPP TS 23.502 V18.x — 5G系统流程，Section 4.3.2 PDU会话建立流程中N4交互
4. DeepWiki - Open5GS PFCP Rules — PDR/FAR/QER/URR规则关联关系图解
5. Devopedia - PFCP — 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 等场景全覆盖。