# 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建立关联，反之亦然。
```mermaid
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,
Recovery Time Stamp
UPF->>SMF: PFCP Association Setup Response
Note left of UPF: Node ID, UP Function Features,
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,
Create FAR, Create QER, Create URR,
Create BAR(可选), UE IP Address
UPF->>SMF: PFCP Session Establishment Response
Note left of UPF: UP F-SEID, Cause,
Created PDR (含F-TEID),
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：
| IE名称 | 类型 | 必选/条件 | 描述 |
|--------|------|----------|------|
| **Node ID** | 必选 | M | 标识发送请求的SMF |
| **CP F-SEID** | 必选 | M | SMF侧的会话端点标识符，包含SEID和IP地址 |
| **Create PDR** | 条件 | C | 包检测规则，含PDI、Precedence、关联的FAR/QER/URR ID |
| **Create FAR** | 条件 | C | 转发动作规则，含Apply Action和转发参数 |
| **Create QER** | 可选 | O | QoS执行规则，含Gate Status、MBR、GBR、QFI |
| **Create URR** | 可选 | O | 使用量上报规则，含Measurement Method、Reporting Triggers |
| **Create BAR** | 可选 | O | 缓存动作规则，控制DL数据缓存行为 |
| **Create Traffic Endpoint** | 可选 | O | 流量端点，用于PDI优化（共享匹配字段） |
| **PDN Type** | 可选 | O | PDU会话类型（IPv4/IPv6/Ethernet/Unstructured） |
| **User Plane Inactivity Timer** | 可选 | O | 用户面不活动定时器 |
**设计意图**：PFCP采用"**一次下发全套规则**"的设计哲学，在Session Establishment Request中一次性下发所有PDR/FAR/QER/URR，避免多轮交互。这极大降低了PDU会话建立时延，但也意味着SMF必须精确计算所有规则参数。
## 三、四类规则链深度剖析
### 3.1 规则关联模型
根据TS 29.244 Section 5.2.1，PFCP的包处理模型基于**PDR为核心节点**的规则关联图：
```mermaid
graph LR
PKT[入向报文] --> PDR1[PDR-1
包检测规则]
PKT --> PDR2[PDR-2
包检测规则]
PKT --> PDR3[PDR-3
包检测规则]
PDR1 -->|关联1个| FAR1[FAR
转发动作规则]
PDR1 -->|关联0..N个| QER1[QER
QoS执行规则]
PDR1 -->|关联0..N个| URR1[URR
使用量上报规则]
PDR2 -->|关联1个| FAR2[FAR]
PDR2 -->|关联0..1个| QER2[QER]
PDR3 -->|关联1个| FAR1
FAR1 -->|可选关联| BAR[BAR
缓存动作规则]
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匹配字段详解
| PDI字段 | 说明 | 匹配层级 |
|---------|------|---------|
| **Source Interface** | 报文来源接口：ACCESS（上行）、CORE（下行）、CP-function、SGi-LAN/N6-LAN | 必选 |
| **Local F-TEID** | 本地GTP-U隧道端点标识 | 外层IP/UDP |
| **UE IP Address** | UE的IP地址/前缀 | 内层IP |
| **SDF Filter** | 业务数据流过滤器（五元组） | 内层IP/TCP/UDP |
| **Application ID** | 应用标识（基于深度包检测） | 应用层 |
| **QFI** | QoS Flow Identifier（5GC特有） | GTP-U扩展头 |
| **Ethernet Packet Filter** | 以太网过滤器（Ethernet PDU会话） | L2 |
| **Network Instance** | 网络实例（VRF/路由域） | 路由域 |
#### 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中的标志位控制：
| Apply Action标志 | 含义 | 典型场景 |
|-----------------|------|---------|
| **FORW** | 转发报文 | 正常UL/DL数据转发 |
| **DROP** | 丢弃报文 | 策略控制、未授权流量 |
| **BUFF** | 缓存报文 | UE处于CM-IDLE时缓存DL数据 |
| **NOCP** | 通知控制面 | 缓存首个DL包时通知SMF触发寻呼 |
| **DUPL** | 复制报文 | 合法监听、流量镜像 |
| **DFRT** | 冗余传输复制 | URLLC双隧道冗余传输 |
| **EDRT** | 冗余传输去重 | URLLC接收端去重 |
| **IPMA** | 接受IP组播加入 | IPTV场景 |
| **IPMD** | 拒绝IP组播加入 | 组播策略控制 |
| **BDPN** | 缓存DL包通知（每SDF） | 精细化DL数据通知 |
| **DDPN** | 丢弃DL包通知（每SDF） | 缓存溢出时通知 |
**FORW标志配套参数**（Forwarding Parameters IE）：
| 参数 | 说明 |
|------|------|
| **Destination Interface** | 目标接口：ACCESS(下行→AN)、CORE(上行→DN)、CP-function |
| **Outer Header Creation** | 添加GTP-U封装（IP+TEID） |
| **Transport Level Marking** | DSCP/TOS标记 |
| **Forwarding Policy** | 转发策略标识（预配置） |
| **Header Enrichment** | 上行HTTP头部增强（插入特定Header） |
| **Linked Traffic Endpoint ID** | 关联反向方向Traffic Endpoint |
**关键设计**：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功能 | 对应IE | 说明 |
|---------|--------|------|
| **门控** | Gate Status | OPEN允许/ CLOSED禁止（分UL/DL独立控制） |
| **Session-AMBR限速** | MBR (UL/DL) | 会话级最大比特率 |
| **GBR保障** | GBR (UL/DL) | 保证比特率（GBR QoS Flow） |
| **QFI标记** | QFI | 下行报文的QoS Flow标识 |
| **反射QoS** | RQI (Reflective QoS Indication) | UE通过反射学习上行QoS |
| **包速率限制** | Packet Rate (UL/DL) | 每秒包数限制 |
**QER的分层设计**：
```mermaid
graph TB
subgraph "Session级QER"
SQER["QER-1
Session-AMBR
UL/DL MBR"]
end
subgraph "Bearer/QoS Flow级QER"
BQER1["QER-2
GBR QoS Flow
GBR+MBR+QFI"]
BQER2["QER-3
Non-GBR QoS Flow
QFI only"]
end
subgraph "SDF级QER"
SDQER["QER-4
门控控制
Gate Status"]
end
SQER -.->|"Session AMBR
多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：
| URR参数 | 说明 |
|---------|------|
| **Measurement Method** | 测量方法：VOLUME（流量）、DURATION（时长）、EVENT（事件） |
| **Reporting Triggers** | 上报触发条件 |
| **Volume Threshold** | 流量阈值（达到即上报） |
| **Time Threshold** | 时间阈值 |
| **Volume Quota** | 流量配额（在线计费） |
| **Time Quota** | 时间配额 |
| **Quota Holding Time** | 配额保持时间（无流量后多久回收配额） |
| **Monitoring Time** | 监控时间窗口 |
| **Inactivity Detection Time** | 不活动检测时间 |
**Reporting Triggers关键触发条件**：
| 触发条件 | 说明 |
|---------|------|
| **PERIO** | 周期性上报 |
| **VOLTH** | 达到流量阈值 |
| **TIMTH** | 达到时间阈值 |
| **QUHTI** | 配额保持时间到期 |
| **START** | 检测到SDF/应用开始 |
| **STOPT** | 检测到SDF/应用停止 |
| **LIUSA** | 配额使用完毕 |
| **IMMEDIATE** | 立即上报（PFCP Modification中请求） |
| **DROTH** | 丢弃DL流量达到阈值 |
| **TERM** | 会话终止时上报 |
## 四、包处理流水线：UPF内部处理顺序
UPF收到一个用户面报文后的完整处理流程（基于TS 29.244 Section 5.2.1 Figure 5.2.1-1）：
```mermaid
flowchart TD
A[报文到达UPF] --> B[步骤1: 识别PFCP会话
通过Local F-TEID / UE IP]
B --> C[步骤2: PDR匹配查找
按Precedence从高到低]
C --> D{找到匹配PDR?}
D -->|否| E[丢弃报文]
D -->|是| F[步骤3: 执行关联QER
门控检查→速率限制→QFI标记]
F --> G{Gate Status = CLOSED?}
G -->|是| H[丢弃报文
可能触发URR丢弃计数]
G -->|否| I[步骤4: 执行关联FAR
Apply Action决定报文去向]
I --> J{Apply Action}
J -->|FORW| K[转发: 添加Outer Header→发送]
J -->|DROP| L[丢弃报文]
J -->|BUFF| M[缓存报文
可选触发NOCP通知SMF]
J -->|DUPL| N[复制报文→转发到监听接口]
I --> O[步骤5: 更新关联URR
流量统计/时间统计]
O --> P[检查Reporting Triggers
是否需要上报]
P --> Q{触发上报?}
Q -->|是| R[生成PFCP Session Report
发送给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中下发以下规则集：
```mermaid
graph TB
subgraph "上行规则 (Source Interface = ACCESS)"
ULPDR1["UL PDR-1
Precedence=100
PDI: Local F-TEID + QFI=1
(默认QoS Flow)"]
ULPDR2["UL PDR-2
Precedence=50
PDI: Local F-TEID + QFI=2 + SDF
(GBR QoS Flow)"]
ULPDR1 --> ULFAR["UL FAR
Apply Action=FORW
Outer Header Creation:
N6接口 → DN"]
ULPDR2 --> ULFAR
ULPDR1 --> SQER["Session QER
Session-AMBR限制
UL MBR=100Mbps"]
ULPDR2 --> SQER
ULPDR2 --> GQER["GBR QER
GBR=10Mbps, MBR=20Mbps
QFI=2"]
ULPDR1 --> URR1["URR-1
Volume + Duration
Periodic上报"]
ULPDR2 --> URR1
end
subgraph "下行规则 (Source Interface = CORE)"
DLPDR1["DL PDR-1
Precedence=100
PDI: UE IP + QFI=1"]
DLPDR2["DL PDR-2
Precedence=50
PDI: UE IP + QFI=2 + SDF"]
DLPDR1 --> DLFAR["DL FAR
Apply Action=FORW
Outer Header Creation:
N3接口 → gNB
(GTP-U IP+TEID)"]
DLPDR2 --> DLFAR
DLPDR1 --> SQER2["Session QER
Session-AMBR限制
DL MBR=100Mbps"]
DLPDR2 --> SQER2
DLPDR2 --> GQER2["GBR QER
QFI=2, RQI=0"]
DLPDR1 --> URR2["URR-2
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分配：
| 步骤 | SMF行为 | UPF行为 |
|------|---------|---------|
| 1 | 在PDR的Local F-TEID IE中设置CHOOSE=1 | - |
| 2 | 可通过CHOOSE ID让多个PDR共享同一F-TEID | - |
| 3 | - | 收到请求后分配N3 UL F-TEID |
| 4 | - | 在Response的Created PDR IE中返回F-TEID |
### 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**：
| 不使用PDI优化 | 使用PDI优化 |
|-------------|------------|
| 每个PDR独立包含Local F-TEID、UE IP、Network Instance | 创建Traffic Endpoint（含共享字段），PDR通过ID引用 |
| 多个PDR中相同的IE重复传输 | 一次定义，多处引用 |
| 修改UE IP需更新所有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 Est Response Cause = "Rule creation/modification Failure" | PDR的PDI字段冲突或无效SDF Filter语法 | 检查Failed Rule ID IE，定位失败的规则 |
| 用户面不通，PFCP会话建立成功 | FAR的Outer Header Creation配置错误（IP/TEID错误） | 对比SMF下发的F-TEID与UPF分配的F-TEID |
| 上行正常但下行不通 | DL PDR的UE IP Address不匹配 | 检查DL PDR的PDI中UE IP是否正确 |
| QoS未生效 | QER未关联到PDR | 检查Create PDR中的QER ID是否正确 |
| 计费数据缺失 | URR的Reporting Triggers未正确配置 | 确认Volume Threshold和Periodic触发器 |
| PFCP Session Est Response Cause = "No resources available" | UPF资源耗尽（TEID池满、会话数超限） | 检查UPF负载和资源使用率 |
| Cause = "Conditional IE missing" | 缺少条件必选IE（如5GC场景缺少Create PDR） | 对照TS 29.244 Table 7.5.2-1检查 |
## 九、Cause值全解析
PFCP Session Establishment Response中的Cause值（TS 29.244 Section 8.2.1）是排错的核心入口：
| Cause值 | 含义 | SMF应采取的行动 |
|---------|------|---------------|
| Request accepted (success) | 所有规则创建成功 | 继续PDU会话建立流程 |
| Request rejected (reason not specified) | 未知原因拒绝 | 日志记录，可选重试 |
| Session context not found | SEID不存在 | 检查CP F-SEID分配 |
| Mandatory IE missing | 缺少必选IE | 根据Offending IE定位缺失字段 |
| Conditional IE missing | 缺少条件IE | 检查场景相关条件 |
| Invalid length | IE长度无效 | 检查编码问题 |
| Mandatory IE incorrect | 必选IE值无效 | 检查IE取值范围 |
| Invalid F-TEID allocation option | SMF尝试自行分配F-TEID（5GC不允许） | 改为设置CHOOSE标志 |
| No resources available | UPF资源不足 | 选择其他UPF或等待资源释放 |
| Rule creation/modification Failure | 规则创建失败 | 检查Failed Rule ID定位具体规则 |
| Request partially accepted | 部分规则创建成功（PSUCC特性） | 检查哪些规则失败并修正 |
## 十、常见问题
**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](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/18.06.00_60/ts_129244v180600p.pdf) — PFCP协议规范，Section 5.2.1包处理模型、Section 5.2.3 FAR处理、Section 7.5.2会话建立消息定义
2. [3GPP TS 23.501 V18.x](https://www.3gpp.org/DynaReport/23501.htm) — 5G系统架构，Section 5.8.2 UPF功能、Section 6.3 N4参考点定义
3. [3GPP TS 23.502 V18.x](https://www.3gpp.org/DynaReport/23502.htm) — 5G系统流程，Section 4.3.2 PDU会话建立流程中N4交互
4. [DeepWiki - Open5GS PFCP Rules](https://deepwiki.com/open5gs/open5gs/5.1.2-packet-forwarding-rules-(pdrfarqerurrbar)) — PDR/FAR/QER/URR规则关联关系图解
5. [Devopedia - PFCP](https://devopedia.org/packet-forwarding-control-protocol) — 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 等场景全覆盖。
