5G N4接口PFCP会话建立与PDR/FAR/QER/URR报文处理规则全链拆解

聚焦 3GPP TS 29.244，从 N4 会话建立信令到 UPF 数据面报文流水线，逐级解析 SMF 如何用四类规则把"一张白纸"的 UPF 编程为一台能检测、转发、限速、计费的智能转发引擎。

一、N4接口在5G系统中的定位

5G 核心网最深刻的架构变革之一，就是控制面与用户面的彻底解耦：SMF（会话管理功能）只负责信令与策略决策，UPF（用户面功能）只负责高速数据转发。二者之间唯一的耦合点，就是 N4 接口。N4 上运行的协议是 PFCP（Packet Forwarding Control Protocol，报文转发控制协议），由 TS 29.244 定义。

PFCP 的核心思想可以一句话概括：SMF 不直接转发数据包，而是向 UPF 下发一组"规则（Rules）"，UPF 按规则自主处理每一个数据包。 这种"规则下发 + 数据面自治"的设计，使 UPF 可以用硬件/DPU/SmartNIC/可编程交换芯片实现线速处理，而 SMF 完全不必关心每一帧报文。

理解 N4，必须先把它放回 PDU 会话建立的大流程里。根据 TS 23.502 Section 4.3.2.2.1（UE-initiated PDU Session Establishment），N4 信令发生在 SMF 选定 UPF 之后、PDU Session Establishment Accept 下发之前。

sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN/gNB
    participant AMF
    participant SMF
    participant UPF
    participant PCF

    UE->>AMF: NAS PDU Session Establishment Request<br/>(DNN, S-NSSAI, Request Type)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext<br/>(SUPI, PDU Session ID, DNN)
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(获取PCC规则、QoS、计费)
    Note over SMF: 选定UPF(基于DNN/S-NSSAI/UL-CL)
    SMF->>UPF: PFCP Session Establishment Request<br/>(Create PDR/FAR/QER/URR)
    UPF->>SMF: PFCP Session Establishment Response<br/>(UPF分配的N3 F-TEID, Cause)
    SMF->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(含N2 SM信息:PDU Session Resource Setup List)
    AMF->>RAN: N2 PDU Session Resource Setup Request<br/>(含QoS Flow、N3 TEID)
    RAN->>UE: RRC Reconfiguration + NAS<br/>PDU Session Establishment Accept
    UE->>RAN: 上行数据(GTP-U, N3 TEID)
    RAN->>UPF: GTP-U上行报文(N3)
    Note over UPF: PDR匹配 → FAR转发 → QER限速 → URR计费

可以看到，第 6 步的 PFCP Session Establishment Request 是整个会话能跑通数据的"点睛之笔"——在这条消息之前，UPF 不知道该为谁服务、不知道收到的包该怎么处理；在这条消息之后，UPF 立即具备了对该 PDU 会话所有上下行报文的完整处理能力。

二、PFCP消息结构与N4会话建立流程

2.1 PFCP消息头（TS 29.244 Clause 6.1）

所有 PFCP 消息都遵循 "固定头 + 可变 IE（Information Element）" 结构。会话相关消息的头部包含一个关键的 SEID（Session Endpoint Identifier，64位），它全局唯一标识一个 N4 会话——UPF 与 SMF 各持一端。

2.2 PFCP消息类型码（TS 29.244 Clause 7.1）

抓包识别 N4 流程时，Message Type 字节是第一判据。下表是 N4 会话生命周期中最常用的类型码：

2.3 N4会话建立时序与关键IE组

在 TS 29.244 Clause 5.8.2（PFCP Session Establishment Procedure） 中定义的流程，本质就是 SMF 把一个 PDU 会话"翻译"成一组规则，原子化地下发给 UPF：

sequenceDiagram
    autonumber
    participant SMF
    participant UPF

    Note over SMF: 1.为UE分配UE IP地址<br/>2.生成SEID(本地端+对端)<br/>3.按PCC规则翻译为PDR/FAR/QER/URR
    SMF->>UPF: PFCP Session Establishment Request
    Note right of UPF: 消息体含IE组:<br/>· Create PDR (一组)<br/>· Create FAR (一组)<br/>· Create QER (一组)<br/>· Create URR (可选)<br/>· Create BAR (可选)<br/>+ UE IP Address / PDN Type / Node ID
    Note over UPF: 校验能力位、分配N3/N9 F-TEID、<br/>安装规则到数据面、建立转发表项
    UPF->>SMF: PFCP Session Establishment Response
    Note left of SMF: 含:<br/>· Cause(成功/失败原因)<br/>· UP F-TEID(UPF分配的TEID与IP)<br/>· Created PDR(回带每个PDR的F-TEID)<br/>· Usage Report(若已有用量)
    Note over SMF,UPF: N4会话激活,UPF可处理上下行报文

这里有一个常被忽略的设计要点：F-TEID 由谁来分配？ 在 5G 中，N3 接口（RAN↔UPF）的 GTP-U TEID 通常由 UPF 分配并在 Establishment Response 中回带给 SMF，SMF 再通过 N2 消息（TS 38.413 的 PDU Session Resource Setup）传给 gNB。这意味着 SMF 在建立 N4 会话时，Create PDR 里的 F-TEID 字段会带上 TEID-CHID/V4/V6 标志，请求 UPF 分配——这就是为什么 Created PDR IE 必须出现在 Response 中。

三、五大报文处理规则深度拆解

UPF 数据面的一切行为，都由五类规则驱动。它们之间通过 Rule ID 相互引用，形成一个 DAG（有向无环图）：

flowchart TD
    PKT[上行/下行数据报文] --> PDR{PDR匹配<br/>按Precedence}

    PDR -->|命中第一条| DET[检测成功<br/>提取UE IP/TEID/SDF]
    DET --> FAR[FAR: Apply Action<br/>转发/丢弃/缓存/复制]
    DET --> QER[QER: QoS执行<br/>门控/限速/打QFI]
    DET --> URR[URR: 用量测量<br/>统计流量/时长]

    FAR -->|FORW| OHCR[Outer Header<br/>Creation<br/>封装GTP-U]
    FAR -->|BUFF| BAR[BAR: 缓存控制<br/>下行通知]
    QER --> MARK[打QFI/Reflective QoS]
    URR --> RPT[触发Session Report]

    OHCR --> OUT[送出N3/N9/N6]
    MARK --> OUT

3.1 PDR——Packet Detection Rule（报文检测规则，Clause 5.2.1A）

PDR 是整个体系的"入口"。 UPF 收到任意一个报文，第一件事就是拿它去匹配一组 PDR，以 Precedence 值最小（优先级最高）的那条命中规则为准（Precedence IE 见 Clause 8.2.11）。

PDR 的灵魂是它内含的 PDI（Packet Detection Information，报文检测信息），PDI 定义了"什么样的包属于我"：

• Source Interface（Clause 8.2.2）：标识报文来自接入侧（Access/N3）、核心侧（Core/N9）、还是 N6。这是最粗粒度的分流。
• F-TEID：用于 GTP-U 隧道接入的检测——如果 UPF 是按 N3 隧道接入上行报文，PDI 就用 (本地IP, 本地TEID) 来匹配。
• UE IP Address：用于非 GTP 接入（如 N6 上行/以太网 PDU 会话）按内层 IP 检测。
• SDF Filter（业务数据流过滤器）：5/7 元组（协议、IP五元组）包过滤器，可实现应用级精细检测，引用 TS 23.501 的 QoS/计费规则。
• Application ID：基于 DPI 识别的应用。

除 PDI 外，PDR 还携带：

• Precedence：决定匹配优先级，值越小优先级越高。这是 PDR 体系区别于传统 ACL 的关键——它是一个全局有序的匹配表。
• Outer Header Removal：告诉 UPF 在检测后剥掉哪些外层头（GTP-U/UDP/IP 或 VLAN），露出内层 payload 供后续 QER/URR 处理。
• 关联引用：FAR ID list、QER ID list、URR ID list、BAR ID——PDR 是"枢纽"，通过这些 ID 把检测到的包路由到对应的执行规则。

3.2 FAR——Forwarding Action Rule（转发行为规则，Clause 5.2.3）

FAR 回答"检测到的包要做什么"。 核心字段是 Apply Action，取值见下表（第二张表）：

• FORW（Forward）：转发。此时 FAR 必须携带 Forwarding Parameters，其中最关键的是 Outer Header Creation——它告诉 UPF 用什么外层头封装（N3/N9 用 GTP-U，需要写入对端 TEID、对端 IP、源 IP、QFI），以及 Destination Interface（Access/Core/SGi-LAN/N6 LAN）和 Network Instance（DNN）。
• DROP：直接丢弃（如策略拒绝、过载丢弃）。
• BUFF（Buffer）：缓存，配合 BAR 使用，典型场景是寻呼未完成时缓存下行数据。
• NOCP（Notify CP）：通知控制面——触发 UPF 向 SMF 发 PFCP Session Report（如检测到首个下行包需寻呼 UE）。
• DUPL（Duplicate）：复制，配合 Duplicating Parameters，用于合法拦截（LI）、双发选收（冗余传输）等场景。

3.3 QER——QoS Enforcement Rule（QoS执行规则，Clause 5.4 / 5.2.4）

QER 负责质量保障：限速、门控、打 QFI。 它实现了 TS 23.501 QoS 模型在用户面的最终落地点。关键字段：

• QFI（QoS Flow Identifier）：在转发时封装到 GTP-U 扩展头或反射给 UE。
• Gate Status（UL/DL）：Open 允许通过，Closed 直接丢弃——这是计费策略中"流量暂停/恢复"的用户面抓手。
• MBR（Maximum Bit Rate，上/下行）：令牌桶限速，超出 MBR 的报文被丢弃（对 Non-GBR）或标记。
• RQI（Reflective QoS Indication）：指示 UE 反射派生 QoS 规则。
• PPI（Paging Policy Indicator）：影响寻呼优先级，与切片/业务优先级联动。

3.4 URR——Usage Reporting Rule（用量报告规则，Clause 5.2.2）

URR 是计费与策略计费（PCC）的数据来源。 它定义"测量什么、何时上报"。关键字段：

• Measurement Method：VOLUME（字节数）、DURATION（时长）、EVENT（基于事件，如应用检测）。
• Reporting Triggers：触发上报的条件——PERIO（周期）、VOLTH（流量阈值）、TIMTH（时长阈值）、VOL_QU/TIME_QU（配额耗尽）、LIUSA（链路使用率）、IPMJL（立即上报）等。
• Volume/Time Quota：SMF 下发的配额；耗尽时 UPF 通过 PFCP Session Report（消息类型 56）向 SMF 上报并请求新配额。
• Linked URR ID：URR 之间可嵌套，实现分层统计（如子规则统计、父规则汇总）。

3.5 BAR——Buffering Action Rule（缓存行为规则，Clause 5.2.5）

BAR 是 BUFF 动作的细节控制器。 当 FAR 的 Apply Action 设为 BUFF 时，BAR 提供：

• Downlink Data Notification Delay：下行数据通知的延迟参数。
• Suggested Buffering Packets Count：建议缓存的最大报文数（超出的丢弃）。

BAR 在寻呼场景中至关重要：当 UE 处于 CM-IDLE 状态且有下行数据到达，UPF 通过 NOCP + BAR 机制通知 SMF，SMF 触发寻呼，期间下行包缓存在 UPF。

四、IE参数说明表（表1）

下表汇总四类核心规则的 IE 字段，便于协议开发与抓包对照：

五、FAR Apply Action取值与触发场景（表2）

设计意图：FORW/DROP/BUFF 是互斥的"主动作"，NOCP/DUPL 可叠加。 这种位图式编码使一条 FAR 可同时表达"转发 + 复制到LI接口"。

六、报文处理流水线的设计哲学

理解了五类规则，再回头看 PFCP 的设计，会发现三个精妙的工程取舍：

第一，"枢纽-执行"解耦。 PDR 只管"检测和分流"，不关心"怎么处理"；FAR/QER/URR 只管"执行"，不关心"包从哪来"。PDR 通过 ID 列表把检测命中的包"扇出"到多个执行规则。这意味着同一条 QER（如限速 10Mbps）可被多个 PDR 引用，避免规则膨胀。

第二，Precedence 全局有序匹配。 与传统 ACL 的"first-match"不同，PFCP 用显式 Precedence 值排序。这解决了 UL-CL（上行分类器）分流场景的歧义：当上行包同时匹配"主会话 PDR"和"UL-CL PDR"时，Precedence 小的胜出，结果确定且可复现——这对运营商编排分流策略至关重要。

第三，控制面无状态化与数据面有状态化。 SMF 永远不下发任何数据包，只在状态变化时下发/修改规则（增删改 IE 组用 Create/Update/Remove 前缀区分）。而 UPF 在数据面维护每条规则的有状态计数器（URR 的字节数/时长）。这种分工使 SMF 可以水平扩展到海量会话，UPF 可以下沉到边缘。

七、N4会话状态机（状态转换图）

stateDiagram-v2
    [*] --> ESTABLISHED: Establishment Request成功<br/>(Cause=Accept)
    ESTABLISHED --> MODIFIED: Modification Request<br/>(加UL-CL/切换/QoS变更)
    MODIFIED --> ESTABLISHED: Modification Response成功
    ESTABLISHED --> REPORTING: Session Report<br/>(用量上报/事件)
    REPORTING --> ESTABLISHED: Report Response<br/>(SMF下发新配额)
    ESTABLISHED --> DELETED: Deletion Request<br/>(PDU会话释放)
    MODIFIED --> DELETED: Deletion Request
    DELETED --> [*]: 释放所有规则与TEID
    ESTABLISHED --> [*]: UPF故障/心跳超时<br/>(隐式释放)

状态机的核心是 ESTABLISHED——这是唯一能让数据正常转发的稳态。所有规则都挂在该会话下；一旦进入 DELETED，UPF 删除该 SEID 关联的全部 PDR/FAR/QER/URR，并释放 F-TEID。

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

8.1 抓包识别 N4 流程（TShark）

N4 走 PFCP，UDP，端口 8805（多播发现用 224.0.0.250 / IPv6 ff02::a:b:c:d）。常用过滤器：

# 1. 仅看PFCP
tshark -i eth0 -Y "pfcp" -V

# 2. 仅看某次会话建立(SMF→UPF的Establishment Request)
tshark -i eth0 -Y "pfcp.msg_type==50"

# 3. 追踪某个SEID的完整生命周期
tshark -i eth0 -Y "pfcp.seid==0x0000000000001234"

# 4. 解析所有Create PDR/FAR并导出规则
tshark -r n4.pcap -Y "pfcp.msg_type==50 || pfcp.msg_type==51" \
  -T fields -e pfcp.seid -e pfcp.msg_type -e pfcp.pdr_id \
  -e pfcp.precedence -e pfcp.far_id -e pfcp.qer_id

pfcp.msg_type==50 是排查"会话是否真正建立"的最快手段。若只有 50 没有 51，说明 UPF 未应答（多半是规则校验失败或 UPF 资源不足）。

8.2 常见故障点

Q1：PFCP 和 4G EPC 的 Sx 接口是什么关系？ A：PFCP 就是 CUPS（控制面用户面分离，TS 29.244 R14）引入的协议，4G 中 SGW-U/PGW-U 与 S/P-GW-C 之间也用 Sx/PFCP。5G 的 N4 直接沿用并扩展了 PFCP（增加 5G 特有 IE，如 QFI、S-NSSAI、UE IP 多归属）。因此 N4 与 4G Sx 在协议格式上高度兼容，差异主要在语义字段。

Q2：为什么是 PDR 引用 FAR/QER/URR，而不是反过来？ A：因为数据面处理顺序是固定的：先检测（PDR），再执行（FAR/QER/URR）。PDR 作为入口枢纽，把"一个检测命中"扇出到"多个执行动作"，符合流水线方向。反向引用会破坏匹配的唯一性——一个 QER 可被多个 PDR 共用（限速规则复用），这是性能关键。

Q3：Precedence 值到底怎么分配才合理？ A：原则是"越具体的规则优先级越高（值越小）"。例如 UL-CL 分流 PDR 的 Precedence 应小于主会话 PDR；每个应用级 SDF PDR 又小于 UL-CL PDR。运营商通常按 PCC 规则的优先级 + 业务类型分层映射，避免冲突时命中错误 PDR 导致数据走到错误隧道。

Q4：URR 的配额耗尽后流量会断吗？ A：不会立即断。UPF 在配额耗尽时通过 PFCP Session Report 上报 SMF，SMF 向 CHF（计费功能）申请新配额。若申请成功，SMF 用 Session Modification 下发新 Quota，UPF 继续放行；若申请失败或信用耗尽，SMF 才通过 Modification 把 FAR 改为 DROP。这个"先报后断"机制保证了计费准确性。

Q5：N4 会话修改和重新建立的区别？ A：Modification（msg_type=52/53）是增量操作，用 Update/Remove IE 组对现有规则做增删改，保留 SEID 与未变更的规则，开销小、速度快——切换、加 UL-CL、QoS 变更都用它。Establishment 是全量创建，用于会话首次建立。大量频繁变更若误用 Establishment，会导致 UPF 重建全部表项，严重浪费数据面资源。

参考来源

1. 3GPP TS 29.244 — Interface between the Control Plane and the User Plane nodes — N4/Sx接口PFCP协议主规范（Clause 5.2.1A PDR、5.2.3 FAR、5.2.4 QER、5.2.2 URR、5.8.2 会话建立流程、8.2.11 Precedence）
2. 3GPP TS 23.502 — System procedures — Section 4.3.2.2.1 UE-initiated PDU Session Establishment（N4步骤定位）
3. ETSI TS 129 244 V17.5.0 PDF — 规范全文PDF，含完整IE编码图
4. 华为云社区：5GS协议栈 PFCP PDR/FAR 报文检测与转发规则 — PDR/FAR 字段中文详解（对应 Clause 5.2.1A / 5.2.3）
5. free5GC PFCP Software Architecture within UPF 与 PFCP Session Lifecycle — 开源UPF实现视角的规则安装与报文处理流水线
6. DeepWiki: Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) — open5gs — open5gs 数据面规则应用实现

本文由「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 等场景全覆盖。