# 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严格区分两个状态层级，初学者最易混淆： ```mermaid flowchart LR subgraph Node["节点级 PFCP Association"] A1["Association Setup Request
Node ID + UP Features"] --> A2["Association Setup Response
能力协商"] end subgraph Sess["会话级 PFCP Session"] B1["Session Est. Request
CP F-SEID + 五类规则"] --> B2["Session Est. Response
UP F-SEID + F-TEID"] end Node -- "首次/周期维护" --> Sess Sess -- "Modification/Deletion
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会话建立： ```mermaid 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
[Hdr: SEID=CP F-SEID, MsgType=50]
Create PDR + Create FAR + Create QER + Create URR Note right of UPF: 安装规则
为N3下行分配F-TEID(CH=1) UPF-->>SMF: PFCP Session Establishment Response
[Hdr: SEID=CP F-SEID, MsgType=51]
UP F-SEID + Created PDR(F-TEID) + Cause SMF->>AMF: Namf N1N2MessageTransfer
(N2 SM: 含UPF分配的N3 TEID) AMF->>AN: NGAP PDU Session Resource Setup Request AN-->>AMF: NGAP PDU Session Resource Setup Response
(含AN侧N3 TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM Resp) Note over SMF,UPF: 阶段2：N4会话修改（补装上行检测规则） SMF->>UPF: PFCP Session Modification Request
[Hdr: SEID=UP F-SEID]
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）**： ```mermaid 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)
剥离GTP-U/IP"] PDI --> SRC["Source Interface (8.2.2)
Access=0 / Core=1 / SGi=2"] PDI --> TEID["F-TEID (8.2.4)
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态下行缓存）与寻呼触发的协同点。 ### 规则之间的引用关系 ```mermaid 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参数速查表 | IE名称 | 规范章节 | 关键字段 | 作用 | |--------|---------|---------|------| | CP/UP F-SEID | §8.2.3 | SEID(8字节)+IPv4/v6 | 会话级双向寻址 | | F-TEID | §8.2.4 | TEID(4字节)+IP+CH/CHID | N3/N9 GTP-U隧道标识，CH=1请求UPF分配 | | Create PDR | §7.5.2.2 | PDR ID/Precedence/PDI/OHR | 检测入向报文，含PDI全套 | | PDI | §8.2.5 | SrcIntf/F-TEID/UE IP/SDF/QFI | 报文匹配条件集合 | | Outer Header Removal | §8.2.13 | Description(0~4) | 剥离GTP-U/UDP/IP层次 | | Create FAR | §7.5.2.3 | Apply Action/Fwd Params | 决定转发/丢弃/缓存 | | Outer Header Creation | §8.2.43 | GTP-U/UDP/IP位图+TEID+IP | 为转发报文封装外层 | | Destination Interface | §8.2.24 | Access=0/Core=1/SGi=2 | 出向逻辑接口 | | Create QER | §7.5.2.5 | QFI/Gate/MBR/Session-AMBR | 限速与QoS标记 | | Create URR | §7.5.2.4 | MeasMethod/Triggers/Period | 计量与上报 | | Create BAR | §7.5.2.6 | Buffering Params | 缓存策略 | ## 六、两类关联对比：Association vs Session | 维度 | PFCP Association | PFCP Session | |------|------------------|--------------| | 寻址标识 | Node ID | SEID（CP/UP各一） | | 生命周期 | 节点级，长期存在 | 会话级，随PDU会话生灭 | | 主要消息 | Assoc Setup/Update/Release（MsgType 5~10） | Session Est/Mod/Del/Report（MsgType 50~57） | | 协商内容 | UP/CP Function Features能力集 | 五类转发规则 | | 承载端口 | UDP 8805 | UDP 8805 | | 失效影响 | 该UPF所有会话受影响 | 仅该会话 | ## 七、设计意图：为什么是这样编排 这套看似繁琐的"五规则+两级状态"架构，背后有几条清晰的工程逻辑： **解耦检测与动作**。把"识别报文"（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)` 的嵌套结构。 ### 常见故障点 | 故障现象 | 排查方向 | |---------|---------| | Response Cause=53（No Established PFCP Association） | 节点级关联未建或已释放，先查 Assoc Setup 的Node ID与Features | | Response Cause=52（Rule creation/modification failure） | UPF不支持某规则（如SDF Filter数量超限、不支持某QER特性），查UP Features | | N3隧道建起但无流量 | 检查PDR是否命中、Precedence冲突、QER门控是否被关、FAR是否为Forward而非Drop | | 下行不通、上行通 | 第二阶段Modification未补装上行PDR，或AN侧F-TEID写入错误 | | 计费缺量 | URR的Measurement Method/Triggers未配，或Period过长 | ## 常见问题 **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)](https://www.3gpp.org/DynaReport/29244.htm) — §7.5.2 Session Establishment Request、§7.5.3 Response、§8.2 IEs 2. [TS 29.244 §7.5.2 — iTecSpec在线索引](https://itecspec.com/3gpp/29.244/s/7.5.2) — Create PDR/FAR/URR/QER/BAR/MAR子节结构 3. [Packet Forwarding Rules (PDR/FAR/QER/URR/BAR) — DeepWiki/open5gs](https://deepwiki.com/open5gs/open5gs/5.1.2-packet-forwarding-rules-(pdrfarqerurrbar)) — 五类规则数据结构与引用关系 4. [3GPP TS 23.502 — System procedures](https://www.3gpp.org/DynaReport/23502.htm) — §4.3.2.2 UE-requested PDU Session Establishment 5. [PFCP Session Lifecycle in free5GC](https://free5gc.org/blog/20260204/20260204/) — 会话建立/修改/释放全生命周期与规则归属 --- > 本文由「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 等场景全覆盖。