<!-- title: 图解PDU会话：从N4到数据转发 -->

# 图解PDU会话：从N4到数据转发原理

> 说明：本文写作时外部网络检索通道受限，文中内容基于通信行业通行的公开技术知识与经典教材整理；个别数据（如头部开销字节数）为标准协议定义值，可按文末参考来源自行核验。

## 一、从一个日常问题说起

你的手机上网时，视频App的数据包是怎么"进网"的？在4G时代，教科书告诉你：手机和分组核心网之间建立了一条"EPS承载"（E-RAB），数据沿着承载流动。到了5G，这个词换成了"PDU会话"（PDU Session）。很多工作了两三年的工程师对它的理解停留在"PDU会话就是5G版的承载"——这个理解对了一半，却漏掉了5G核心网最重要的一次架构革命：**控制面与用户面的彻底分离（CUPS）**，以及由此带来的全新协议PFCP。

本文要回答的核心问题有三个：

1. PDU会话到底"是"什么？它和4G承载的本质区别在哪？
2. SMF是怎么"遥控"UPF干活的？N4接口上到底跑了什么东西？
3. 一个IP包进了UPF之后，经历了怎样的处理流水线？

理解了这三个问题，你在现网排查"有信令没数据"、"话单少话单"、"边缘分流不生效"这类经典故障时，就有了完整的理论地图。

## 二、先建立全景：5G核心网的"人岗分离"

### 2.1 类比：餐厅的分工革命

想象一家老式餐厅，服务员一个人负责：点单、下单到厨房、端菜、收银、记账。客人一多就手忙脚乱。现代餐厅把它拆成了三种角色：

- **前台经理**（对客接待、安排座位）→ 对应 **AMF**（接入与移动性管理功能）
- **订单管理员**（决定这桌点什么菜、用哪个厨房、怎么计价）→ 对应 **SMF**（会话管理功能）
- **后厨与传菜通道**（真正做菜、传菜，不跟客人说话）→ 对应 **UPF**（用户面功能）

5G核心网的精髓正是这次"人岗分离"：**AMF只碰信令，永远不碰用户数据；SMF只做决策，自己不转发一个包；UPF只负责高速转发，自己不做决策**。决策者与执行者之间，靠一条叫 **N4** 的接口通信。

### 2.2 架构图：一张图看懂所有接口

```mermaid
flowchart TD
    UE["UE 手机"] -- "N1(NAS信令)" --> AMF
    AN["无线接入网<br/>(gNB)"] -- "N2(NGAP信令)" --> AMF
    UE -. "空口用户数据" .-> AN
    AN -- "N3(GTP-U隧道)<br/>用户数据" --> UPF
    subgraph 核心网控制面
        AMF["AMF<br/>移动性+信令中转"]
        SMF["SMF<br/>会话大脑"]
    end
    AMF -- "N11" --> SMF
    SMF == "N4 (PFCP)<br/>下发转发规则" ==> UPF["UPF<br/>用户面网关"]
    UPF -- "N6<br/>裸IP" --> DN["数据网络 DN<br/>(互联网/专网)"]
    UPF -. "N4上报事件/用量" .-> SMF
```

这张图里最值得记住的是**箭头的"虚实"**：

- **实线是信令**：N1（UE↔AMF的NAS消息）、N2（gNB↔AMF）、N11（AMF↔SMF）、N4（SMF↔UPF），这些线上跑的是"管理信息"。
- **虚线/粗线是数据**：空口→gNB→N3隧道→UPF→N6出口，这是用户数据的完整路径。注意 **AMF不在这条数据路径上**——它只在N1/N2信令链上。

这个设计回答了"为什么AMF不能顺便转发数据"：移动性管理（注册、寻呼、切换）是高频、强实时的信令事务，数据转发是高吞吐、低延迟的持续流量，两者的资源特征完全不同。混在一起部署，一次信令风暴就能把用户数据转发拖垮，反之亦然。分离之后，**控制面可以集中部署在大区机房（追求集中管控），用户面可以下沉到地市甚至基站机房（追求就近转发）**，部署位置解耦了。

## 三、PDU会话的本质：一条"逻辑专线"

### 3.1 技术定义与直觉

**PDU会话是UE与数据网络（DN）之间的一条逻辑连接**，它承诺两件事：

1. **地址连续性**：会话存续期间，UE在这条会话上使用的IP地址（IPv4/IPv6/两者都有）保持不变；
2. **QoS可协商**：会话内可以定义多条QoS流（QoS Flow），每条流有各自的速率保障、时延要求。

"会话"这个词很准确——它不是物理电路，而是一组分布在UE、RAN、UPF三处的**转发状态的集合**。PDU会话建立的过程，本质上就是网络在这三个地方**同步安装一套一致的匹配与转发规则**的过程。

### 3.2 和4G承载对比：从"铁轨"到"公路"

| 对比维度 | 4G EPS承载 | 5G PDU会话 |
|---------|-----------|-----------|
| 基本单位 | 承载（Bearer），默认承载+专有承载 | 会话（Session），建立时只建一条默认QoS流 |
| QoS粒度 | 承载级，同一承载内业务"同坐一车厢" | QoS流级，同一会话内按流区分（如IMS信令流与语音流分开） |
| 控制面/用户面 | 逻辑上分离（CUPS后期才引入），网元紧耦合 | 原生分离，SMF/UPF独立扩容、独立选点部署 |
| 锚点灵活性 | SGW/PGW相对固定 | 支持SSC模式+上行分类器（UL CL），锚点可"搬家"或"多点分流" |
| 网络切片 | 不支持 | 会话建立时绑定S-NSSAI切片标识 |

关键差异用一个比喻：4G承载像**火车站的铁轨**——车（业务）进哪条轨道，-QoS就定死了；5G PDU会话像一条**多车道高速公路**——同一条路（会话）上，救护车（GBR语音流）、货车（大流量下载）、私家车（普通上网）各行其道，交警（SMF）只需在入口处给每类车发不同的通行规则。

### 3.3 UPF是怎么选出来的：不是随便指派的

当SMF接到建立会话的请求时，它要回答的第一个问题是"用哪个UPF"。选择依据是一个多维匹配问题：

- **DNN**（数据网络名称，类似4G的APN）：你要去互联网还是去"企业专网"？
- **S-NSSAI**（切片标识）：这是大带宽切片还是低时延切片？
- **UE位置**：TA（跟踪区）/小区在哪，就近选下沉UPF；
- **UPF能力与负载**：是否支持N6口的特定功能、当前负荷如何。

这解释了很多现网现象：为什么同一个用户，在公司园区里上网走的是园区边缘UPF，出了园区走到市中心就换成了市中心机房的UPF——**位置变了，"最优UPF"的答案就变了，会话锚点就要迁移**，这就引出了SSC模式。

## 四、SSC模式：锚点的三种"搬家哲学"

PDU会话的锚点（Anchor）就是那个持有UE的IP地址、连接N6出口的UPF。当UE移动到远离锚点的位置时，锚点怎么办？5G定义了三种策略，由网络按DNN+切片配置决定：

| SSC模式 | 锚点行为 | 业务连续性 | 适用场景 | 直觉类比 |
|---------|---------|-----------|---------|---------|
| SSC模式1 | 锚点永远不变 | IP不变，但远离锚点后路径绕远 | 普通上网 | 老家的固定电话号码，人走号不变，但人在外地打电话要"绕回家" |
| SSC模式2 | 先断旧会话，再建新会话（新锚点） | IP会变，短暂中断 | 对连续性不敏感的业务 | 搬家时先注销旧宽带，再装新宽带 |
| SSC模式3 | **先建新会话，再断旧会话** | 新旧并行，接近无损切换 | 语音、实时游戏 | 搬家前先在新家装好宽带并测试通过，再停旧宽带 |

现网绝大多数上网流量是模式1；VoNR语音和URLLC业务倾向模式3。调试边缘计算（MEC）分流问题时，SSC模式的选择直接决定了"用户靠近边缘节点后，流量是否以及何时能分流到本地UPF"。

## 五、N4接口与PFCP：大脑如何遥控四肢

### 5.1 为什么需要一条专门的"遥控协议"

SMF在机房A，UPF在机房B，SMF要让UPF"凡是目的地址是10.1.2.3的包，封装进GTP-U隧道发往某gNB，且限速500Mbps，并统计字节数"。这需要一个标准化的遥控语言——**PFCP（Packet Forwarding Control Protocol）**，跑在N4接口上。

PFCP的工作分两个阶段：

1. **PFCP关联建立（Association Setup）**：SMF与UPF先"握手认识"，交换能力与特性（比如你支持F-TEID分配吗？支持以太网PDU会话吗？）。关联断了，这条SMF-UPF之间的所有会话控制都失效。之后还有周期性**心跳（Heartbeat）**保活。
2. **PFCP会话管理**：针对每一个PDU会话，SMF下发PFCP Session Establishment Request，把一组规则装进UPF。

一个极易被忽略的设计点：**"关联"与"会话"是两级概念**。关联好比开店（一次性的合作关系），会话是每笔订单（每个用户一条）。现网故障排查时，如果所有用户的会话建立同时失败，先查关联和心跳；如果只有个别用户失败，查具体规则冲突。

### 5.2 UPF里的五类规则：PDR/FAR/QER/URR/BAR

SMF通过PFCP装进UPF的不是一句模糊的"转发它"，而是一套**结构化规则集**。理解这五类规则，等于拿到了UPF的"源代码"：

| 规则类型 | 全称 | 职责 | 生活类比 |
|---------|------|------|---------|
| **PDR** | Packet Detection Rule | 定义"哪些包归我管"：按TEID、IP五元组、QFI等匹配 | 快递分拣员手里的面单识别规则 |
| **FAR** | Forwarding Action Rule | 定义"匹配到的包怎么办"：FORWARD / DROP / BUFFER / DUPLICATE，以及怎么封装 | 分拣后的去向指令：发货/丢弃/暂存/复印一份 |
| **QER** | QoS Enforcement Rule | 执行限速/门控：达到速率上限就丢包或降优先级 | 高速收费站限速杆 |
| **URR** | Usage Report Rule | 统计用量（字节数/包数/时长），触发计费上报 | 计量电表，定期抄表送电力公司 |
| **BAR** | Buffering Action Rule | 指导下行数据缓存（如UE空闲时先攒着） | 收件人不在家时的代收点 |

### 5.3 一个数据包的旅程：UPF内部的流水线

当N3隧道里的包到达UPF，它经历的是一条规则流水线：

```mermaid
flowchart TD
    A["GTP-U包到达 N3 口"] --> B["解封装: 剥掉外层IP/UDP/GTP头"]
    B --> C{"PDR匹配<br/>按优先级(Precedence)<br/>找第一条命中的规则"}
    C -- "未命中任何PDR" --> X["DROP<br/>(静默丢弃)"]
    C -- "命中PDR" --> D["取出关联的FAR/QER/URR"]
    D --> E{"FAR动作?"}
    E -- "DROP" --> X
    E -- "BUFFER" --> F["缓存, 等UE可及后<br/>发Data Notification给SMF"]
    E -- "FORWARD" --> G{"QER门控/限速"}
    G -- "超速" --> X
    G -- "合规" --> H["按FAR重写封装:<br/>外层IP/UDP/GTP(F-TEID)或裸IP"]
    H --> I["URR计数器累加<br/>(字节/包数)"]
    I --> J["从N6发出 或 经N3发往gNB"]
```

这里有一个"为什么这样设计"的精髓：**PDR之间靠优先级（Precedence）区分先后，数值越小优先级越高，UPF只执行第一条命中的规则**。这允许SMF下发"通用规则+特例规则"：比如优先级10的规则说"该UE的所有包都走互联网锚点"，优先级5的规则说"但目的地址是10.0.0.0/8企业专网的包走UL CL分流"。没有优先级机制，规则之间就会互相打架。

匹配逻辑可以用伪代码表达为：

$$
\text{执行规则} = \text{Precedence最小且匹配的PDR} = \min_{p \in \text{命中PDR集合}} \{ \text{precedence}(p) \}
$$

## 六、端到端建立流程：一封"会话建立"的完整时序

把前面的概念串起来，看一次完整的PDU会话建立信令时序：

```mermaid
sequenceDiagram
    autonumber
    participant UE as UE
    participant AMF as AMF
    participant SMF as SMF
    participant UPF as UPF
    participant RAN as gNB

    UE->>AMF: NAS: PDU会话建立请求<br/>(DNN/S-NSSAI/请求类型)
    AMF->>SMF: N11: 创建会话请求<br/>(带UE上下文、位置信息)
    Note over SMF: 1.与UDM签约核对<br/>2.选择UPF(DNN+切片+位置)
    SMF->>UPF: N4: PFCP会话建立请求<br/>(下发PDR/FAR/QER/URR)
    UPF-->>SMF: N4: PFCP会话建立响应(成功)
    SMF-->>AMF: N11: 创建会话响应<br/>(含N2参数:核心网侧F-TEID/QoS配置)
    AMF->>RAN: N2: PDU会话资源建立请求
    RAN->>UE: RRC重配置(建立DRB, 分配QFI)
    UE-->>RAN: RRC重配置完成
    RAN-->>AMF: N2: PDU会话资源建立响应<br/>(含RAN侧F-TEID)
    AMF->>SMF: N11: 更新会话(带RAN侧隧道信息)
    SMF->>UPF: N4: PFCP会话修改请求<br/>(补全下行FAR: 隧道对端=其gNB)
    UPF-->>SMF: 响应
    AMF-->>UE: NAS: PDU会话建立完成<br/>(含IP地址)
```

几个值得咀嚼的设计细节：

- **两段式N4交互**：第一步SMF先给UPF装上"上行规则"（能识别UE发来的包），但此时下行还不知道该往哪个gNB发——因为gNB侧的隧道端点还没回来。等N2流程带回gNB的F-TEID后，SMF再发PFCP会话**修改**请求补全下行FAR。这就是为什么抓包时会看到建立过程中出现"PFCP Session Modification"而感到困惑。
- **IP地址的授予时机**：UE拿到的IP地址是SMF在N4建立阶段就从UPF（或地址池）分配并带回的，但会话"建立完成"要等到空口DRB真正建立——**逻辑连接的"注册"和"通车"是两步**。

## 七、隧道与开销：GTP-U的算术账

N3接口上，用户的原始IP包被GTP-U封装后传输。封装结构为"外层IP + UDP + GTP头"，按外层IPv4计算：

$$
\text{封装开销} = \underbrace{20}_{\text{外层IPv4头}} + \underbrace{8}_{\text{UDP头}} + \underbrace{8}_{\text{GTP头(标准11字节中取8字节基础头)}} = 36 \text{ 字节}
$$

若外层采用IPv6（40字节固定头 + 可选扩展头），开销至少为 $40+8+8=56$ 字节。对MTU为1500字节的传输网：

$$
\text{N3链路最大有效载荷} = 1500 - 36 = 1464 \text{ 字节 (IPv4)}
$$

这组算术在现网的直接推论：**如果传输网MTU是1500而UE侧发出1500字节整包，N3隧道内封装后达到1536字节，超过出口MTU，包要么被分片要么被静默丢弃**——这就是经典的"MTU黑洞"故障：ping小包通、大包丢、网页打不开但即时消息正常（小包）。排查思路是核查N3/N9链路各段MTU，确保隧道封装后的总长仍不超限，或启用TCP MSS钳制。

（注：GTP头在无扩展头、无序列号场景下基础长度为8字节，带序列号等选项时为12字节，具体由报文标志位决定。）

## 八、进阶：UL CL与"多锚点"分流

对于边缘计算场景，5G设计了**上行分类器（UL CL，Uplink Classifier）**：在UE与锚点UPF之间的路径上插入一个"分流点"UPF。它不需要知道UE的IP地址分配情况，只按SMF下发的PDR（如目的网段匹配）把流量分叉：

- 命中"本地服务"规则的包 → 转发给本地UPF（MEC节点），就近处理；
- 其余包 → 继续沿隧道送给锚点UPF，出N6上互联网。

```mermaid
flowchart LR
    UE["UE"] -- "N3隧道" --> BP["分流UPF<br/>(UL CL / IPv6多宿主分支点)"]
    BP -- "命中本地规则<br/>(如访问园区服务器)" --> MEC["本地UPF/MEC<br/>就近卸载"]
    BP -- "未命中<br/>继续走锚点" --> ANCHOR["锚点UPF<br/>(持有UE的IP)"]
    ANCHOR --> NET["互联网"]
    MEC --> LAN["本地数据网络"]
    SMF2["SMF"] -. "N4动态增删分流PDR" .-> BP
```

UL CL的精妙之处在于**UE完全无感知**——它仍然以为自己在和锚点通信，IP地址不变、业务不中断。分流规则的增删由SMF通过N4动态控制，UE移动导致分流点不合适时，SMF可以平滑更换分流位置。这就是"用户在园区内访问公司内网快如飞、出了园区自动回到全网锚点"背后的机制。

## 九、实战连接：现网调试中的高频应用场景

1. **"有信令无数据"三板斧**：UE注册成功、会话建立也"完成"了，但上不了网。按数据路径逐段核查：① UPF的N6口NAT/DNS是否正常；② N3隧道两端F-TEID是否匹配（gNB与UPF互指对端）；③ N4会话里的FAR是否是FORWARD而非BUFFER（UE状态异常时常卡在缓存）。
2. **PFCP心跳与"雪崩式掉线"**：SMF与UPF之间心跳超时达到阈值后，SMF会释放该UPF上的关联与会话。表现为：某机房网络抖动后，该UPF下**所有用户**瞬间掉线重建。抓包看PFCP Heartbeat Request/Response的时延与丢包是定位关键。
3. **话单缺斤短两**：计费系统发现某类业务话单量偏少。根因常在URR：上报触发条件（按量阈值/周期/事件）配置过松，或会话释放时"停止上报并生成最后一份话单"的通知链路异常。核对口是SMF侧的话单记录与UPF侧URR计数器。
4. **边缘分流不生效**：配置了UL CL但流量没走本地UPF。依次检查：分流PDR的优先级是否被更高优先级规则"截胡"（Precedence数值更小的先命中）、分流规则的IP网段是否与业务实际目的地址匹配、UL CL所在UPF是否支持相应特性（关联建立时能力协商是否声明）。
5. **会话建立失败的cause定位**：NAS拒绝消息带的cause是最快的路标——签约问题（DNN/切片未开通）指向UDM数据；资源不足指向UPF/切片容量；"UE上下文不一致"多见于重附着残留。

## 十、常见误解与调试陷阱

- **误解一："AMF也转发用户数据"**。AMF只有信令面。数据流量异常时去AMF侧找吞吐是走错片场。
- **误解二："PDU会话=一条QoS"**。一个会话可挂多条QoS流，Web流量和语音可以共享一条会话却享受不同QoS待遇。
- **误解三："N4失败=UPF坏了"**。N4失败可能是关联未建立、心跳超时、规则资源超限、license缺失等多种原因，先分清"关联级"还是"会话级"失败。
- **陷阱：优先级顺序想当然**。自认为加了分流规则就生效，结果被优先级更高的默认PDR提前命中。规则数量多了以后，**优先级规划要有全局表**，这是很多边缘分流项目返工的根因。

## 常见问题

**Q: PDU会话和QoS流是什么关系？**
A: 包含关系。PDU会话是UE到数据网络的逻辑"管道"，QoS流是管道内的"车道"。会话建立时至少生成一条QoS流；后续可通过SMF动态增删（比如VoNR通话时新增一条GBR语音流）。QoS执行点分布在UPF（N4的QER规则）和gNB（空口调度）两处。

**Q: SMF和UPF分离后，如果N4断链，用户数据还通吗？**
A: 短期内通，之后不通。已下发的PDR/FAR仍留在UPF内存里，数据转发不依赖SMF在线；但心跳超时触发关联释放后，SMF会要求UPF释放会话，用户就会掉线。所以N4链路质量直接决定用户面稳定性。

**Q: 4G用户在5G网络里用的也是PDU会话吗？**
A: 互操作时存在映射关系。4G侧的EPS承载在5G核心网（ NSA/互操作场景）会被映射为一条PDU会话来处理，核心网内部以PDU会话为统一模型，对接4G无线侧时再做承载级转换。理解这一点对排查4/5G互操作掉线问题很重要。

**Q: 为什么UPF要下沉到边缘，而不是全部集中在大区？**
A: 物理定律决定的。时延≈距离/光速×往返系数，集中部署时用户到机房的单程距离可达数百公里，往返时延难以满足车联网、工业控制等毫秒级需求。CUPS架构让"大脑"（SMF）集中管控、四肢（UPF）伸到离用户最近的地方，是集中管控与就近转发这对矛盾的工程最优解。

**Q: 抓包时看到PFCP Session Modification比Establishment还多，正常吗？**
A: 正常。会话生命周期中任何参数变化（QoS更新、切换后隧道端点变化、UL CL分流规则增删、计费触发条件变更）都通过修改流程下发。只有会话建立/释放才出现Establishment/Release，而修改贯穿全程。

## 参考来源

3. [3GPP 官网 5G System Overview](https://www.3gpp.org/technologies/5g-system-overview) — 5G系统架构各功能实体的官方技术综述页
4. 图书资料：《5G核心网原理与实践》（51学通信出品）——PDU会话建立流程与N4/PFCP实战章节
5. 图书资料：《通信原理》（经典教材）——封装开销、隧道与分组转发的基础原理章节

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

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)