在5G核心网架构中,N4接口连接SMF(Session Management Function)与UPF(User Plane Function),是实现控制面与用户面分离(CUPS)的关键参考点。N4上承载的核心协议是PFCP(Packet Forwarding Control Protocol),定义于TS 29.244。
PFCP的核心设计理念是:SMF不处理任何用户面数据包,而是通过PFCP消息向UPF下发"规则",UPF依据规则对数据包进行检测、转发、QoS执行和用量上报。这种"规则编排"模式是5G用户面架构的基石。
PFCP协议的前身是EPC CUPS架构中的Sx接口协议(Release 14引入),在5GC中被标准化为N4接口,同时保持了对Sx的向后兼容。TS 29.244 V18.x(Release 18)已扩展支持Red Cap、Positioning等新场景的用户面规则。
PFCP协议采用两层抽象模型:
PFCP Association是SMF与UPF之间的节点级传输层关联,在任何Session操作之前必须先建立。Association通过PFCP Association Setup Procedure完成(TS 29.244 Section 7.3.1)。
sequenceDiagram
participant SMF
participant UPF
Note over SMF,UPF: PFCP Association Setup (节点级)
SMF->>UPF: PFCP Association Setup Request
Note right of SMF: 携带: Node ID(SMF),<br/>Recovery Time Stamp
UPF->>SMF: PFCP Association Setup Response
Note left of UPF: 携带: Node ID(UPF),<br/>Recovery Time Stamp,<br/>UP Function Features
Note over SMF,UPF: Association建立完成,可创建Session
Association建立过程中,双方交换的关键IE包括:
| IE名称 | 方向 | 说明 |
|---|---|---|
| Node ID | 双向 | 节点标识,IPv4/IPv6地址或FQDN |
| Recovery Time Stamp | 双向 | 节点恢复时间戳,用于状态判断 |
| UP Function Features | UPF→SMF | UPF能力声明(如支持FTUP、多PDR等) |
| CP Function Features | SMF→UPF | SMF能力声明 |
UP Function Features IE至关重要——SMF据此判断UPF是否支持特定功能(如F-TEID自分配、支持SDF Filter、UE IP地址池等),从而决定后续Session建立时如何编排规则。
PFCP Session对应一个PDU Session的用户面上下文,由SMF通过PFCP Session Establishment在UPF上创建(TS 29.244 Section 7.5.2)。每个Session包含一组规则(PDR/FAR/QER/URR/BAR),构成UPF处理该PDU Session数据包的完整逻辑。
Session通过SEID(Session Endpoint Identifier)唯一标识,SMF和UPF各自分配本地SEID,在消息中通过F-SEID(Fully Qualified SEID)传递,包含SEID值和IP地址。
graph TB
subgraph PFCP_Association["PFCP Association (节点级)"]
direction TB
subgraph Session1["PFCP Session 1"]
PDR1[PDR #1 - UL PDR]
PDR2[PDR #2 - DL PDR]
FAR1[FAR #1 - Forward to N6]
FAR2[FAR #2 - Forward to N3]
QER1[QER #1 - QoS Flow 1]
QER2[QER #2 - QoS Flow 2]
URR1[URR #1 - Usage Report]
BAR1[BAR #1 - DL Buffer]
end
subgraph Session2["PFCP Session 2"]
PDR3[PDR #3 - UL PDR]
PDR4[PDR #4 - DL PDR]
FAR3[FAR #3]
QER3[QER #3]
end
end
PDR1 -->|"关联"| FAR1
PDR1 -->|"关联"| QER1
PDR2 -->|"关联"| FAR2
PDR2 -->|"关联"| QER2
PDR2 -->|"关联"| URR1
PDR2 -->|"关联"| BAR1
PFCP Session Establishment是PDU Session建立过程中SMF与UPF之间的核心交互,定义在TS 29.244 Section 7.5.2。以下是嵌入PDU Session Establishment中的完整N4信令流程:
sequenceDiagram
participant UE
participant gNB
participant AMF
participant SMF
participant UPF
participant PCF
UE->>gNB: UL NAS Transport<br/>(PDU Session Establishment Request)
gNB->>AMF: N2 Message + NAS PDU
AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
Note right of SMF: DNN, S-NSSAI, SUPI<br/>PDU Session ID, Request Type
SMF->>PCF: Npcf_SMPolicyControl Create
PCF->>SMF: PCC Rules + QoS Parameters
Note right of SMF: 获得QoS策略、<br/>计费规则、SDF模板
Note over SMF: SMF选择UPF并构建<br/>PFCP规则集
rect rgb(230, 240, 255)
Note over SMF,UPF: N4/PFCP Session Establishment
SMF->>UPF: PFCP Session Establishment Request
Note right of SMF: Create PDR × N<br/>Create FAR × N<br/>Create QER × N<br/>Create URR × N<br/>Create BAR (可选)<br/>F-SEID, UE IP Address
UPF->>SMF: PFCP Session Establishment Response
Note left of UPF: Cause<br/>F-SEID (UPF侧)<br/>Created PDR (含F-TEID)<br/>UPF分配的N3隧道端点
end
SMF->>AMF: Namf_Communication_N1N2MessageTransfer
Note right of SMF: N1: PDU Session Estab Accept<br/>N2: N2 SM Info<br/>(含UPF N3 F-TEID)
AMF->>gNB: N2 PDU Session Resource Setup Request
gNB->>UE: RRC Reconfiguration<br/>(含PDU Session配置)
gNB->>AMF: N2 PDU Session Resource Setup Response<br/>(含gNB N3 F-TEID)
AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
rect rgb(230, 240, 255)
Note over SMF,UPF: N4/PFCP Session Modification (更新gNB隧道)
SMF->>UPF: PFCP Session Modification Request
Note right of SMF: Update FAR #DL<br/>更新N3 DL F-TEID为gNB隧道端点
UPF->>SMF: PFCP Session Modification Response
end
Note over UE,UPF: 双向用户面数据通路就绪
SMF向UPF发送的PFCP Session Establishment Request消息(TS 29.244 Section 7.5.2.1)包含以下核心IE:
| IE | 类型 | 说明 |
|---|---|---|
| Node ID | 必选 | SMF节点标识 |
| F-SEID | 必选 | SMF侧会话端点标识(SEID + IP) |
| Create PDR | 必选(可重复) | 创建包检测规则 |
| Create FAR | 必选(可重复) | 创建转发动作规则 |
| Create QER | 条件必选 | 创建QoS执行规则 |
| Create URR | 可选 | 创建用量上报规则 |
| Create BAR | 可选 | 创建缓存动作规则 |
| PDN Type | 必选 | IPv4/IPv6/IPv4v6/Ethernet |
| UE IP Address | 条件必选 | 分配给UE的IP地址 |
| FQ-CSID | 可选 | 故障关联标识 |
| User Plane Inactivity Timer | 可选 | 用户面不活跃定时器 |
UPF返回的PFCP Session Establishment Response消息(TS 29.244 Section 7.5.2.2)包含:
| IE | 类型 | 说明 |
|---|---|---|
| Node ID | 必选 | UPF节点标识 |
| Cause | 必选 | 响应原因值 |
| F-SEID | 必选 | UPF侧会话端点标识 |
| Created PDR | 条件必选 | 包含UPF分配的F-TEID |
| Load Control Information | 可选 | UPF负载信息 |
| Overload Control Information | 可选 | UPF过载控制信息 |
Cause值的典型取值(TS 29.244 Section 7.5.2.2):
| Cause值 | 编码 | 含义 |
|---|---|---|
| Request accepted | 1 | 成功接受所有规则 |
| Request rejected | 64 | 通用拒绝 |
| Session establishment rejected due to no resources | 66 | UPF资源不足 |
| Rule creation/modification failure | 67 | 规则创建失败(需检查Failed Rule ID) |
PDR是PFCP规则体系的核心入口。UPF收到数据包后,首先匹配PDR,匹配成功后执行关联的FAR/QER/URR。
每个PDR包含一个PDI(Packet Detection Information),定义了数据包的匹配条件(TS 29.244 Section 7.5.2.2-4):
graph TD
subgraph PDI["PDI - 包检测信息"]
direction TB
A[Source Interface<br/>Access/Core/SGI/LAN]
B[F-TEID<br/>GTP隧道端点标识]
C[Network Instance<br/>DNN/APN]
D[UE IP Address<br/>源/目的IP]
E[SDF Filter<br/>五元组流量模板]
F[QFI<br/>QoS Flow Identifier]
G[Application ID<br/>应用检测标识]
end
subgraph PDR["PDR - 包检测规则"]
PDI
H[PDR ID<br/>规则唯一标识]
I["Precedence<br/>优先级(0最高)"]
J[Outer Header Removal<br/>去除GTP-U/IPv6头]
K[Associated FAR ID]
L["Associated QER ID(s)"]
M["Associated URR ID(s)"]
end
典型PDR配置示例(一个PDU Session通常至少创建2个PDR):
| 参数 | UL PDR (上行) | DL PDR (下行) |
|---|---|---|
| PDR ID | 1 | 2 |
| Precedence | 100 | 100 |
| Source Interface | ACCESS (0) | CORE (1) |
| F-TEID | UPF N3接收TEID | — |
| UE IP Address | Source IP = UE IP | Destination IP = UE IP |
| SDF Filter | 允许所有 / 或按App | 允许所有 / 或按App |
| Outer Header Removal | Yes (GTP-U) | No |
| Associated FAR ID | FAR #1 | FAR #2 |
| Associated QER ID | QER #1 | QER #1 |
关键设计意图:UL PDR通过F-TEID匹配来自gNB的GTP-U隧道数据包,DL PDR通过目的IP匹配来自DN侧的数据包。PDR的Precedence字段决定匹配优先级——数值越小优先级越高。当多个PDR同时匹配时,UPF选择Precedence最小的PDR。
FAR定义了匹配到PDR的数据包应当如何处理(TS 29.244 Section 7.5.2.3):
| Apply Action值 | 编码 | 说明 |
|---|---|---|
| FORWARD (F) | 0x01 | 转发到指定接口 |
| DROP (D) | 0x02 | 丢弃数据包 |
| BUFFER (B) | 0x04 | 缓存数据包(UE idle时) |
| NOTIFY (N) | 0x08 | 通知SMF(触发DDN) |
FAR的转发参数(Forwarding Parameters)包含:
| IE | 说明 |
|---|---|
| Destination Interface | 目标接口:Access(0) / Core(1) / SGi-LAN(2) |
| Network Instance | 目标DNN |
| Redirect Information | 重定向URL(仅DL FAR) |
| Outer Header Creation | 创建GTP-U头(含N3/N9 F-TEID + IP) |
| Transport Level Marking | DSCP/Traffic Class标记 |
| Forwarding Policy | 转发策略标识 |
UL FAR示例:Apply Action = FORWARD, Destination Interface = Core, Outer Header Creation = N6(无GTP封装,直出IP到DN)或N9(封装GTP-U到中间UPF)。
DL FAR示例:Apply Action = FORWARD, Destination Interface = Access, Outer Header Creation = GTP-U(含gNB N3 F-TEID + gNB IP地址)。
QER实现UPF侧的QoS控制(TS 29.244 Section 7.5.2.5):
| IE | 说明 |
|---|---|
| QER ID | 规则唯一标识 |
| Gate Status | UL/DL门控状态(Open/Closed) |
| Maximum Bit Rate (MBR) | UL/DL最大比特率 |
| Guaranteed Bit Rate (GBR) | UL/DL保证比特率 |
| QoS Flow Identifier (QFI) | QoS流标识 |
| Packet Rate | UL/DL包速率限制 |
| DSCP/DSCP to DSCP Mapping | DSCP标记规则 |
QER的设计支持两级速率控制: - Session级QER:关联到所有PDR,执行Session-AMBR - SDF级QER:关联到特定SDF的PDR,执行GBR/MBR
URR控制流量计费和用量统计(TS 29.244 Section 7.5.2.4):
| IE | 说明 |
|---|---|
| URR ID | 规则唯一标识 |
| Measurement Method | Volume / Duration / Event |
| Reporting Triggers | 触发条件(周期/阈值/ quotas) |
| Volume Threshold | 流量阈值 |
| Time Threshold | 时间阈值 |
| Volume Quota | 流量配额 |
| Monitoring Time | 监控起始时间 |
| Measurement Period | 上报周期 |
BAR用于UE处于CM-IDLE状态时缓存下行数据并触发DDN(Downlink Data Notification)(TS 29.244 Section 7.5.2.6):
| IE | 说明 |
|---|---|
| BAR ID | 规则唯一标识 |
| Downlink Data Notification Delay | DDN延迟时间 |
| Suggested Buffering Packets Count | 建议缓存包数 |
| MTEDT(Maximum Traffic Eyecand Detection Time) | 最大流量检测时间 |
UPF收到数据包后的处理流程如下(TS 29.244 Section 5.8):
flowchart TD
A["收到数据包"] --> B["匹配PDR<br/>(按Precedence优先级)"]
B -->|"未匹配"| DROP1["丢弃"]
B -->|"匹配PDR #n"| C["应用关联的QER<br/>(QoS门控/速率控制)"]
C -->|"Gate=Closed"| DROP2["丢弃"]
C -->|"Gate=Open"| D["应用关联的FAR<br/>(转发/丢弃/缓存)"]
D -->|"DROP"| DROP3["丢弃"]
D -->|"BUFFER"| BUF["缓存数据包<br/>触发DDN通知SMF"]
D -->|"FORWARD"| E["封装/转发<br/>(Outer Header Creation)"]
E --> F["应用关联的URR<br/>(用量统计)"]
F --> G["发出数据包"]
style A fill:#e1f5fe
style G fill:#e8f5e9
style DROP1 fill:#ffebee
style DROP2 fill:#ffebee
style DROP3 fill:#ffebee
style BUF fill:#fff3e0
处理顺序的设计意图: 1. PDR先匹配:确保只处理合法会话的数据包 2. QER再执行:在转发前完成速率控制,避免无效转发浪费资源 3. FAR后转发:执行最终转发决策 4. URR最后统计:只对实际处理的流量计费
Session建立后,SMF通过PFCP Session Modification动态更新规则(TS 29.244 Section 7.5.4):
sequenceDiagram
participant SMF
participant UPF
Note over SMF,UPF: 场景1: gNB隧道更新
SMF->>UPF: PFCP Session Modification Request
Note right of SMF: Update FAR #DL:<br/>Outer Header Creation =<br/>新gNB N3 F-TEID
UPF->>SMF: PFCP Session Modification Response
Note over SMF,UPF: 场景2: 专用QoS Flow建立
SMF->>UPF: PFCP Session Modification Request
Note right of SMF: Create PDR #3 (专用SDF Filter)<br/>Create FAR #3<br/>Create QER #2 (GBR QoS)
UPF->>SMF: PFCP Session Modification Response
Note over SMF,UPF: 场景3: UE进入CM-IDLE
SMF->>UPF: PFCP Session Modification Request
Note right of SMF: Update FAR #DL:<br/>Apply Action = BUFFER<br/>Associated BAR #1
UPF->>SMF: PFCP Session Modification Response
Session Modification支持以下操作(TS 29.244 Section 7.5.4.1):
| 操作类型 | IE | 说明 |
|---|---|---|
| Create | Create PDR/FAR/QER/URR/BAR | 新增规则 |
| Update | Update PDR/FAR/QER/URR | 修改已有规则 |
| Delete | Remove PDR/FAR/QER/URR | 删除已有规则 |
PFCP Session的完整生命周期(TS 29.244 Section 5.8):
stateDiagram-v2
[*] --> AssociationSetup: SMF/UPF启动
AssociationSetup --> Idle: Association建立成功
Idle --> SessionEstablishment: PDU Session建立请求
SessionEstablishment --> Active: Session创建成功
Active --> SessionModification: QoS变更/切换/隧道更新
SessionModification --> Active: 修改成功
Active --> Suspended: UE进入CM-IDLE
Note right of Suspended: DL FAR改为BUFFER模式
Suspended --> SessionModification: UE重新寻呼<br/>恢复DL隧道
SessionModification --> Active: 恢复成功
Active --> SessionDeletion: PDU Session释放
Suspended --> SessionDeletion: PDU Session释放
SessionDeletion --> Idle: Session删除完成
Idle --> AssociationRelease: 节点下线
AssociationRelease --> [*]
PFCP使用UDP端口8805。Wireshark从3.2版本起内置PFCP解码器。
关键抓包过滤表达式:
# 过滤PFCP Session Establishment
pfcp.msg_type == 50
# 过滤PFCP Session Modification
pfcp.msg_type == 52
# 过滤特定SEID的PFCP消息
pfcp.seid == 0x1234567890abcdef
# 过滤PFCP Association
pfcp.msg_type == 6 || pfcp.msg_type == 7
PFCP消息类型编号(TS 29.244 Section 7.1):
| 消息 | 编号 |
|---|---|
| PFCP Association Setup Request | 5 |
| PFCP Association Setup Response | 6 |
| PFCP Session Establishment Request | 50 |
| PFCP Session Establishment Response | 51 |
| PFCP Session Modification Request | 52 |
| PFCP Session Modification Response | 53 |
| PFCP Session Deletion Request | 54 |
| PFCP Session Deletion Response | 55 |
| PFCP Session Report Request | 56 |
| PFCP Session Report Response | 57 |
| 故障现象 | 可能原因 | 排查方向 |
|---|---|---|
| PFCP Session Estab Response Cause = 66 | UPF资源不足 | 检查UPF负载、会话数限制、F-TEID池耗尽 |
| 上行数据可达但下行不通 | DL FAR的Outer Header Creation配置错误 | 检查gNB N3 F-TEID是否通过Session Mod更新到UPF |
| QoS不生效 | QER未关联到PDR | 检查PDR中的Associated QER ID是否匹配 |
| 用量报告缺失 | URR未创建或触发条件未配 | 检查SMF是否下发Create URR及Reporting Triggers |
| PDU Session建立后无数据 | PDR的PDI匹配条件错误 | 检查UL PDR的F-TEID与UPF实际分配的N3 TEID是否一致 |
| DL DDN未触发 | BAR未创建或DL FAR未切到BUFFER | 检查UE idle时SMF是否下发了FAR Update |
| ## 9. 与EPC Gx/GTP-C对比 |
| 对比维度 | EPC (Gx + GTP-C) | 5GC (PFCP on N4) |
|---|---|---|
| 接口数量 | Gx(PCEF-PCRF) + S5/S8(GTP-C) | N4(PFCP统一接口) |
| 规则下发 | Gx下PCC规则到PGW-U | PFCP直接从SMF到UPF |
| 隧道管理 | GTP-C Create Session | PFCP Session Establishment |
| QoS控制 | Gx下QCI/ARP/MBR | PFCP QER (QFI/GBR/MBR) |
| 包检测 | TFT (Traffic Flow Template) | SDF Filter + PDI |
| 转发控制 | 隐含在GTP隧道中 | 显式FAR (Forward/Drop/Buffer) |
| 扩展性 | 紧耦合 | 松耦合,规则可独立增删改 |
Q1: PFCP Association和PFCP Session是什么关系?
A: Association是节点级传输层连接(一对SMF-UPF只需一个),Session是会话级上下文(每个PDU Session一个)。一个Association上可以承载多个Session。Association必须在Session之前建立,但Association断开不意味着所有Session立即失效——取决于Recovery Time Stamp判断。
Q2: 一个PDU Session至少需要几个PDR和FAR?
A: 最少需要2个PDR和2个FAR——一个UL PDR+FAR对处理上行流量(Access→Core),一个DL PDR+FAR对处理下行流量(Core→Access)。如果有专用QoS Flow,可能需要额外的PDR对。Session级QER通常1个(Session-AMBR),每个GBR Flow还需要额外的SDF级QER。
Q3: UPF的F-TEID是SMF分配还是UPF自己分配?
A: 两种模式都支持。SMF在Create PDR的PDI中携带F-TEID(CH=0,即SMF分配)或携带空的F-TEID(CH=1,即请求UPF分配)。UPF在Response的Created PDR中返回分配的F-TEID。实际部署中,大多数UPF采用自分配模式以实现更好的负载均衡。
Q4: PFCP Session Report是什么,什么场景下触发?
A: PFCP Session Report(TS 29.244 Section 7.5.6)是UPF主动向SMF上报事件的机制,典型场景包括:(1) 用量达到URR中配置的阈值或配额;(2) DL数据缓存触发DDN;(3) 用户面不活跃超时;(4) 应用检测报告。SMF收到Report后返回Response确认。
Q5: 为什么5GC选择了PFCP而不是继续使用GTP-C?
A: 核心原因是控制面/用户面分离的设计哲学。GTP-C将隧道管理和策略控制混在一起,紧耦合。PFCP采用"规则编排"模式——SMF通过PDR/FAR/QER等规则显式定义UPF的行为,规则之间松耦合、可独立更新。这使得SMF可以灵活地增删改单条规则(如只更新QER的速率限制而不影响FAR),而不需要重建整个会话。
本文由「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 等场景全覆盖。
