说明：本文写作时外部网络检索通道受限，文中内容基于通信行业通行的公开技术知识与经典教材整理；个别数据（如头部开销字节数）为标准协议定义值，可按文末参考来源自行核验。
你的手机上网时，视频App的数据包是怎么"进网"的？在4G时代，教科书告诉你：手机和分组核心网之间建立了一条"EPS承载"（E-RAB），数据沿着承载流动。到了5G，这个词换成了"PDU会话"（PDU Session）。很多工作了两三年的工程师对它的理解停留在"PDU会话就是5G版的承载"——这个理解对了一半，却漏掉了5G核心网最重要的一次架构革命：控制面与用户面的彻底分离（CUPS），以及由此带来的全新协议PFCP。
本文要回答的核心问题有三个：
理解了这三个问题，你在现网排查"有信令没数据"、"话单少话单"、"边缘分流不生效"这类经典故障时，就有了完整的理论地图。
想象一家老式餐厅，服务员一个人负责：点单、下单到厨房、端菜、收银、记账。客人一多就手忙脚乱。现代餐厅把它拆成了三种角色：
5G核心网的精髓正是这次"人岗分离"：AMF只碰信令，永远不碰用户数据；SMF只做决策，自己不转发一个包；UPF只负责高速转发，自己不做决策。决策者与执行者之间，靠一条叫 N4 的接口通信。
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
这张图里最值得记住的是箭头的"虚实"：
这个设计回答了"为什么AMF不能顺便转发数据"：移动性管理（注册、寻呼、切换）是高频、强实时的信令事务，数据转发是高吞吐、低延迟的持续流量，两者的资源特征完全不同。混在一起部署，一次信令风暴就能把用户数据转发拖垮，反之亦然。分离之后，控制面可以集中部署在大区机房（追求集中管控），用户面可以下沉到地市甚至基站机房（追求就近转发），部署位置解耦了。
PDU会话是UE与数据网络（DN）之间的一条逻辑连接，它承诺两件事：
"会话"这个词很准确——它不是物理电路，而是一组分布在UE、RAN、UPF三处的转发状态的集合。PDU会话建立的过程，本质上就是网络在这三个地方同步安装一套一致的匹配与转发规则的过程。
| 对比维度 | 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）只需在入口处给每类车发不同的通行规则。
当SMF接到建立会话的请求时，它要回答的第一个问题是"用哪个UPF"。选择依据是一个多维匹配问题：
这解释了很多现网现象：为什么同一个用户，在公司园区里上网走的是园区边缘UPF，出了园区走到市中心就换成了市中心机房的UPF——位置变了，"最优UPF"的答案就变了，会话锚点就要迁移，这就引出了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"。
SMF在机房A，UPF在机房B，SMF要让UPF"凡是目的地址是10.1.2.3的包，封装进GTP-U隧道发往某gNB，且限速500Mbps，并统计字节数"。这需要一个标准化的遥控语言——PFCP（Packet Forwarding Control Protocol），跑在N4接口上。
PFCP的工作分两个阶段：
一个极易被忽略的设计点："关联"与"会话"是两级概念。关联好比开店（一次性的合作关系），会话是每笔订单（每个用户一条）。现网故障排查时，如果所有用户的会话建立同时失败，先查关联和心跳；如果只有个别用户失败，查具体规则冲突。
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空闲时先攒着） | 收件人不在家时的代收点 |
当N3隧道里的包到达UPF，它经历的是一条规则流水线：
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会话建立信令时序：
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地址)
几个值得咀嚼的设计细节：
N3接口上，用户的原始IP包被GTP-U封装后传输。封装结构为"外层IP + UDP + GTP头"，按外层IPv4计算：
$$ \text{封装开销} = \underbrace{20}{\text{外层IPv4头}} + \underbrace{8} $$}} + \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字节，具体由报文标志位决定。）
对于边缘计算场景，5G设计了上行分类器（UL CL，Uplink Classifier）：在UE与锚点UPF之间的路径上插入一个"分流点"UPF。它不需要知道UE的IP地址分配情况，只按SMF下发的PDR（如目的网段匹配）把流量分叉：
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可以平滑更换分流位置。这就是"用户在园区内访问公司内网快如飞、出了园区自动回到全网锚点"背后的机制。
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，而修改贯穿全程。
本文由「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 等场景全覆盖。