5G N4接口PFCP会话建立机制与五类转发规则全链拆解

一、N4接口定位：为什么5GC需要PFCP

在5G核心网控制与用户面分离（CUPS）架构下，会话管理功能（SMF）只管信令，真正的报文转发交给用户面功能（UPF）。SMF与UPF之间的这条标准接口就是 N4，其承载的协议即 PFCP（Packet Forwarding Control Protocol），定义于 3GPP TS 29.244。

PFCP承担三件事：建立并维护节点级关联、为每个PDU会话安装一组数据面规则、周期性上报使用量与故障告警。其中最核心、也最值得深入理解的就是 PFCP Session Establishment（会话建立）——这一步把抽象的"会话"转化为UPF数据面上可执行的转发流水线。本文聚焦 TS 29.244 第7.5.2节（PFCP Session Establishment Request）与第7.5.3节（Response），并向上追溯到 TS 23.502 §4.3.2.2 的PDU会话建立流程，向下打通到 TS 38.413 NGAP的资源建立。

需要强调：N4会话并非一对一映射PDU会话。一个PDU会话在UPF侧由一个N4会话承载，但一个N4会话内部可包含多个Traffic Endpoint（用于多PDU会话、IPv6多前缀、ATSSS多路径等场景）。理解这一点是后续规则编排的基础。

二、两个层次：Association与Session

PFCP严格区分两个状态层级，初学者最易混淆：

flowchart LR
    subgraph Node["节点级 PFCP Association"]
        A1["Association Setup Request<br/>Node ID + UP Features"] --> A2["Association Setup Response<br/>能力协商"]
    end
    subgraph Sess["会话级 PFCP Session"]
        B1["Session Est. Request<br/>CP F-SEID + 五类规则"] --> B2["Session Est. Response<br/>UP F-SEID + F-TEID"]
    end
    Node -- "首次/周期维护" --> Sess
    Sess -- "Modification/Deletion<br/>Report" --> Sess

PFCP Association（节点级关联） 用 Node ID 寻址，发生在任何会话之前，负责能力协商：SMF声明自己是CP功能、UPF回报自身支持的UP Function Features（如是否支持F-TEID分配、End Marker、分片、以太网PDU会话等）。对应 TS 29.244 §7.4 的节点相关消息。这个阶段没有SEID。

PFCP Session（会话级会话） 用 SEID 寻址。每条会话由一对F-SEID标识：

• CP F-SEID：SMF分配，在Request消息头部的SEID字段携带；
• UP F-SEID：UPF分配，在Response中返回，之后SMF发往UPF的所有消息头部SEID都用它寻址。

这种"双向、各自分配标识"的设计，让SMF与UPF的会话上下文可以独立扩展、独立回收——这也是CUPS解耦的精髓。

三、完整信令时序：从PDU会话建立触发

N4会话建立并非孤立发生，它嵌在 TS 23.502 §4.3.2.2 的PDU会话建立主流程中。当SMF完成UDM订阅获取、PCF策略关联建立后，便会向所选UPF发起N4会话建立：

sequenceDiagram
    autonumber
    participant AN as (R)AN / gNB
    participant AMF
    participant SMF
    participant UPF
    Note over SMF,UPF: 阶段0：节点级关联（首次或已建立）
    SMF->>UPF: PFCP Association Setup Request (Node ID, UP Features)
    UPF-->>SMF: PFCP Association Setup Response (Cause, UP Features)
    Note over SMF,UPF: 阶段1：N4会话建立
    SMF->>UPF: PFCP Session Establishment Request<br/>[Hdr: SEID=CP F-SEID, MsgType=50]<br/>Create PDR + Create FAR + Create QER + Create URR
    Note right of UPF: 安装规则<br/>为N3下行分配F-TEID(CH=1)
    UPF-->>SMF: PFCP Session Establishment Response<br/>[Hdr: SEID=CP F-SEID, MsgType=51]<br/>UP F-SEID + Created PDR(F-TEID) + Cause
    SMF->>AMF: Namf N1N2MessageTransfer<br/>(N2 SM: 含UPF分配的N3 TEID)
    AMF->>AN: NGAP PDU Session Resource Setup Request
    AN-->>AMF: NGAP PDU Session Resource Setup Response<br/>(含AN侧N3 TEID)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM Resp)
    Note over SMF,UPF: 阶段2：N4会话修改（补装上行检测规则）
    SMF->>UPF: PFCP Session Modification Request<br/>[Hdr: SEID=UP F-SEID]<br/>Update PDR(写入AN侧F-TEID)
    UPF-->>SMF: PFCP Session Modification Response

这段时序揭示了三个关键工程事实：

1. F-TEID的"choose"机制：SMF在Create PDR的PDI里把F-TEID IE的 CH（Choose）标志置1，请求UPF自行分配N3下行隧道的TEID；UPF在Response的Created PDR中回填。这解释了为什么 N2资源建立 必须在 N4会话建立Response之后——因为AMF要拿UPF分配的TEID去通知(R)AN。
2. 会话建立分两步走：第一次Session Establishment只能装下行（Core→Access）方向规则，因为此时AN侧F-TEID还未产生；待NGAP Response带回AN侧TEID后，SMF再用一次 Session Modification 把上行（Access→Core）检测规则补装上。
3. 消息类型码：Session Establishment Request/Response 的PFCP Message Type分别为 50（0x32）和51（0x33），是抓包过滤时最直接的锚点（见第五节）。

四、五类转发规则：Create IE逐个拆解

PFCP Session Establishment Request（§7.5.2）的消息体是一组 Create xxx 分组IE。按 TS 29.244 §7.5.2 的子节划分，依次为：Create PDR（§7.5.2.2）、Create FAR（§7.5.2.3）、Create URR（§7.5.2.4）、Create QER（§7.5.2.5）、Create BAR（§7.5.2.6）；Rel-15后还扩展了Create Traffic Endpoint（§7.5.2.7）、Create MAR（§7.5.2.8，ATSSS多路径）、Create SRR、ATSSS控制信息（§7.5.2.10）、RDS配置（§7.5.2.11）等。本文聚焦最核心的五类。

1. PDR — 包检测规则（入口）

PDR是数据面流水线的入口，负责"识别进入UPF的报文属于哪条流"。其核心是 PDI（Packet Detection Information）：

flowchart TB
    PDR["Create PDR IE (§7.5.2.2)"]
    PDR --> PDRID["PDR ID (8.2.9)"]
    PDR --> PREC["Precedence 优先级 (8.2.11)"]
    PDR --> PDI["PDI (8.2.5)"]
    PDR --> OHR["Outer Header Removal (8.2.13)<br/>剥离GTP-U/IP"]
    PDI --> SRC["Source Interface (8.2.2)<br/>Access=0 / Core=1 / SGi=2"]
    PDI --> TEID["F-TEID (8.2.4)<br/>CH=1请求UPF分配"]
    PDI --> UEIP["UE IP Address"]
    PDI --> SDF["SDF Filter 业务流过滤器"]
    PDI --> QFI["QFI (QoS Flow ID)"]

Precedence决定当多条PDR同时命中时的匹配顺序（值越小优先级越高），这正是5G"每流检测+优先级仲裁"的关键。下行方向的PDR一般用 UE IP + SDF Filter 匹配，上行方向的PDR用 N3 GTP-U的 F-TEID 匹配——这种"下行靠IP、上行靠隧道"的非对称设计，源于上下行承载机制的根本差异。

2. FAR — 转发动作规则（出口）

FAR定义匹配到PDR的报文"做什么"。关键字段是 Apply Action：Forward（转发）/ Drop（丢弃）/ Buffer（缓存）/ Notify（通知SMF）。

转发参数 Forwarding Parameters（§8.2.27）里最关键的是 Destination Interface（Access=0 / Core=1 / SGi-LAN=2 / CP-function=3）与 Outer Header Creation（§8.2.43）——后者告诉UPF为转发出去的报文封装怎样的外层（GTP-U/UDP/IP或裸UDP/IP），并写入对端TEID与目的IP。一个PDR通过其引用的FAR ID决定出口方向。

3. QER — QoS执行规则（限速标记）

QER负责速率控制与QoS标记：包含 QFI、Gate Status（开门/关门）、MBR（最大比特率）、Session-AMBR。门控位一旦置为"关"，对应方向的报文即被静默丢弃——这是实现GBR保障带宽、Session-AMBR限速的物理基础。QER通过Gate的开关，使计费/策略对数据面的控制可即时生效而无需重建会话。

4. URR — 使用量上报规则（计量）

URR定义如何计量与上报：Measurement Method（按Volume/Duration/Event）、Reporting Triggers（周期/阈值/立即）、Measurement Period。当上行因UE空闲而被缓存时，DL Buffer的报文触发 Buffered Packet Notify，进而引发SMF寻呼UE——这就是URR与寻呼机制的内在联系。

5. BAR — 缓存动作规则（缓冲）

BAR控制FAR处于Buffer状态时的缓存行为：Buffering Parameters（缓存报文数上限、缓存时长）。BAR仅在被FAR的Apply Action=Buffer引用时才生效，是省电（idle态下行缓存）与寻呼触发的协同点。

规则之间的引用关系

flowchart TD
    PKT["入向报文"] -->|"按 Precedence 匹配"| PDR["PDR (检测)"]
    PDR -->|"引用 FAR ID"| FAR["FAR (动作:Forward/Drop/Buffer)"]
    PDR -->|"引用 QER ID"| QER["QER (限速/门控/标记)"]
    PDR -->|"引用 URR ID"| URR["URR (计量上报)"]
    FAR -->|"Buffer时引用 BAR ID"| BAR["BAR (缓存策略)"]
    FAR --> OUT["外向报文 (封装/剥离)"]

理解这张"以PDR为中心、四向引用"的拓扑，是分析任何N4故障的入口：报文能转发的必要条件是命中一条PDR，且该PDR引用的FAR为Forward、QER的门控为开。

五、关键IE参数速查表

六、两类关联对比：Association vs Session

七、设计意图：为什么是这样编排

这套看似繁琐的"五规则+两级状态"架构，背后有几条清晰的工程逻辑：

解耦检测与动作。把"识别报文"（PDR）与"处置报文"（FAR）拆开，使一条FAR可被多条PDR复用——例如同一会话内多个SDF Filter共享一套转发出口，避免规则冗余。这也是open5gs、free5GC等开源实现中FAR/QER被独立维护为链表的根本原因。

能力协商前置。Association阶段先确认UPF是否支持F-TEID分配（FTUP）、End Marker、UE IP分配等特性，再决定Session阶段如何编排规则。若UPF不支持Choose分配，SMF就必须自己分配TEID并下发，否则N3隧道无法建立。

增量更新而非整体重建。Modification阶段只下发Update/Delete的差量IE，由SEID定位会话上下文。一次切换、一次QoS调整，只需一个Modification报文，极大降低信令风暴风险。

支持多维扩展。Rel-16的Create MAR服务于ATSSS多接入流量分发，Rel-17的RDS配置支持按需下行流复制。这套"Create IE插件化"的结构，让新功能无需改动消息框架即可扩展，体现了3GPP向前的兼容性考量。

八、实战连接：抓包与排错

抓包识别

PFCP承载于 UDP 8805。在Wireshark中，过滤式 pfcp 或 udp.port == 8805 即可。定位一次完整会话建立的关键过滤串：

pfcp && (pfcp.msg_type == 50 || pfcp.msg_type == 51)

其中 pfcp.msg_type == 50 即Session Establishment Request，51 为Response。展开PDU后依次可见 Create PDR → Packet Detection Information → F-TEID (CH=1) 的嵌套结构。

常见故障点

Q1：F-SEID与F-TEID有什么区别？ A：F-SEID（§8.2.3）是会话级标识，标识CP与UP之间的一个N4会话；F-TEID（§8.2.4）是用户面隧道级标识，标识N3/N9上的一条GTP-U隧道。前者用于PFCP信令寻址，后者用于用户报文封装。一个会话内可有多条F-TEID（如N3、N9各一）。

Q2：为什么PDU会话建立要分两次N4交互（Establishment+Modification）？ A：因为建会话时(R)AN侧的N3 TEID尚未分配，SMF只能先装下行规则并请求UPF分配下行TEID；待NGAP Response带回AN侧TEID后，再用Modification补装上行PDR。这是 TS 23.502 §4.3.2.2 步骤11~14 的必然结果。

Q3：CH（Choose）标志置1意味着什么？ A：表示SMF请求UPF本地分配该F-TEID的TEID值（依赖UPF的FTUP能力）。UPF分配后通过Created PDR回填。若UPF不支持，SMF必须自行分配TEID并下发给UPF，否则隧道无法建立。

Q4：QER的Gate（门控）关掉后报文去哪了？ A：被静默丢弃，用于实现Session-AMBR超限后的限速、或GBR保障带宽不足时的丢弃策略。它不影响会话状态，门控重开后即恢复转发，无需重建会话。

Q5：一个N4会话是否只对应一个PDU会话？ A：通常一一对应，但N4会话内可通过多个Traffic Endpoint（§7.5.2.7）承载多PDU会话或IPv6多前缀场景；ATSSS还会用Create MAR管理多接入路径。会话是逻辑容器，规则才是转发的真正主体。

参考来源

1. 3GPP TS 29.244 — Interface between CP and UP nodes (PFCP) — §7.5.2 Session Establishment Request、§7.5.3 Response、§8.2 IEs
2. TS 29.244 §7.5.2 — iTecSpec在线索引 — Create PDR/FAR/URR/QER/BAR/MAR子节结构
3. Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) — DeepWiki/open5gs — 五类规则数据结构与引用关系
4. 3GPP TS 23.502 — System procedures — §4.3.2.2 UE-requested PDU Session Establishment
5. PFCP Session Lifecycle in free5GC — 会话建立/修改/释放全生命周期与规则归属

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