5G PDU会话建立原理全解：一条数据通路是如何被打通的

一、从一个生活类比说起

想象你要给一位国外的朋友寄一个包裹。你并不是自己跑到海关、机场、转运中心去办手续，而是把包裹交给快递公司。快递公司内部有一套分工：客服负责接你的单、登记你的信息；调度中心负责根据目的地选择走哪条航线、交给哪个枢纽；分拣转运仓库负责实际把包裹装箱、贴标签、送上飞机。

5G 核心网里，当你打开手机想上网的那一刻，发生的事情和寄快递几乎一模一样：

• UE（手机） 就是你，发起"我要上网"的请求；
• AMF（接入与移动性管理功能） 就是客服，接单、登记；
• SMF（会话管理功能） 就是调度中心，规划路线、选择仓库、下发指令；
• UPF（用户面功能） 就是分拣转运仓库，真正搬箱子、贴标签、送数据。

所谓 PDU 会话（PDU Session），就是手机到外部数据网络（比如互联网、企业内网）之间建立起来的一条端到端的数据通路。PDU（Protocol Data Unit，协议数据单元）是数据流的基本单位——可以粗略理解为"一个个数据包"。PDU 会话建立，本质上就是这条数据通路从无到有、被一步步打通的全过程。

理解这个过程，是理解 5G 核心网的"任督二脉"。几乎所有核心网故障排查、切片部署、边缘计算下沉，最终都会回到这条流程上。

二、先搞清楚：5G 和 4G 在"建会话"这件事上的根本差异

很多工程师对 4G 的"承载（Bearer）"概念很熟，但到了 5G 却犯迷糊。其实只要抓住一个核心变化——控制面与用户面的彻底分离——一切就豁然开朗了。

在 4G 时代，负责"管账"的网元（MME/SGW/PGW 的控制部分）和负责"搬货"的网元（SGW/PGW 的用户面部分）是耦合在一起的，或者至少在概念上绑得很紧。到了 5G，设计者把它们彻底拆开：SMF 只管信令、不下发任何用户数据包；UPF 只管搬数据、不参与任何信令决策。两者之间用一条专门的 N4 接口连接。

下表是 4G 与 5G 在会话/承载概念上的对照：

为什么要这样改？ 因为 5G 要同时服务三类差异巨大的业务：手机上网（eMBB）、海量物联网（mMTC）、工业超低时延（URLLC）。如果控制面和用户面还绑在一起，你想把一个靠近工厂部署的"搬运工"（UPF）下沉到边缘，就会连带着把"调度中心"也拽过去，造成信令洪流和部署成本失控。分离之后，控制面可以集中部署在大机房统一调度，用户面可以灵活地、按需地、分布式地部署到任何地方——这就是 5G 支持边缘计算（MEC）和网络切片的底层基石。

三、核心角色图解：谁干什么活

先把这场戏里的"演员表"理清楚。一次 PDU 会话建立，主角是 UE、AMF、SMF、UPF，配角有 UDM、PCF、NRF、（R)AN。

flowchart LR
    UE[UE 手机] -->|N1 NAS 信令| AMF
    subgraph 控制面["控制面 Control Plane"]
        AMF[AMF<br/>接入与移动性管理<br/>= 客服接单]
        SMF[SMF<br/>会话管理<br/>= 调度中心]
        UDM[UDM<br/>签约数据]
        PCF[PCF<br/>策略与计费]
        NRF[NRF<br/>网元发现登记]
    end
    subgraph 用户面["用户面 User Plane"]
        UPF[UPF<br/>用户面转发<br/>= 分拣仓库]
    end
    RAN[(R)AN 基站 gNB]
    DN[(数据网络 DN<br/>互联网/企业网)]

    AMF -->|N11 SBI| SMF
    SMF -->|查询签约| UDM
    SMF -->|获取策略| PCF
    AMF -.->|N2 NGAP| RAN
    SMF ==>|N4 PFCP 下发规则| UPF
    RAN ==>|N3 GTP-U| UPF
    UPF ==>|N6| DN
    RAN <-->|空口 DRB| UE

    classDef cp fill:#e8f0fe,stroke:#4285f4,stroke-width:2px
    classDef up fill:#fce8e6,stroke:#ea4335,stroke-width:2px
    class AMF,SMF,UDM,PCF,NRF cp
    class UPF up

注意图里实线箭头（==>) 是用户面数据通路，虚线/普通箭头 是控制面信令。一个直观结论：UPF 是唯一真正接触用户业务数据的网元，其他所有控制面网元（AMF、SMF、UDM、PCF）处理的都是"指令"，不是你的微信、视频流量本身。

各角色职责速记表：

四、两个必须先懂的关键概念

在看完整流程之前，有两个概念是"地基"，必须先夯实：N4 接口与 PFCP 协议、GTP-U 隧道与 TEID。

4.1 N4 接口与 PFCP：SMF 如何"遥控"UPF

SMF 和 UPF 物理上分离，SMF 要怎么告诉 UPF"遇到这样的包就这样处理"？答案是一条专门的协议——PFCP（Packet Forwarding Control Protocol，包转发控制协议），跑在 N4 接口上。

UPF 本质上是一个"傻瓜式"的高速转发引擎——它没有业务逻辑，不会自己思考，所有行为都由 SMF 通过 PFCP 下发的"规则"来定义。一次 PDU 会话，SMF 会给 UPF 装上一整套规则，主要包括五类：

它们之间的协作关系是一条流水线：

flowchart LR
    PKT[ incoming<br/>数据包 ] --> PDR
    subgraph N4规则集["UPF 内部规则流水线 (由 SMF 经 N4 下发)"]
        PDR[PDR<br/>检测识别<br/>PDI: TEID/QFI/IP...]
        FAR[FAR<br/>转发动作<br/>FORWARD/DROP/BUFFER]
        QER[QER<br/>QoS 限速<br/>QFI/MBBR/Gate]
        URR[URR<br/>用量统计]
        PDR --> FAR
        PDR --> QER
        PDR --> URR
    end
    FAR --> OUT[OUT<br/>送出/丢弃/缓存]
    classDef rule fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    class PDR,FAR,QER,URR rule

为什么设计成"规则表 + 转发引擎"这种模式？ 因为这样可以让 UPF 用硬件或 DPDK/智能网卡以线速（几十上百 Gbps）做最简单的查表转发，而把复杂的策略计算（哪个用户能用多少带宽、哪条流走哪条路）留给 SMF 慢慢算。这就像现实中的快递分拣——分拣线只看条码贴标签（极快），复杂的路由规划在后台系统算好（可慢可复杂）。这是 5G 能够支撑 Tbps 级转发流量的核心架构智慧。

每个 PDR 有一个 Precedence（优先级） 字段，数值越小优先级越高。当一个包同时匹配多条 PDR 时，按优先级最高的那条处理，规则匹配可以用下式表达：

$$ \text{Action}(pkt) = \text{FAR}\big(\,\underset{i \in \text{matched PDRs}}{\arg\min}\; \text{Precedence}_i \,\big) $$

4.2 GTP-U 隧道与 TEID：数据怎么"隔"开

5G 用户面沿用了 4G 的 GTP-U（用户面 GPRS 隧道协议）。它的思路很朴素：在基站和 UPF 之间，把每个用户的每个会话的数据，封装进一条"隧道"里传输，用 TEID（Tunnel Endpoint ID，隧道端点标识） 来区分。

打个比方：N3 接口（基站到 UPF）是一条公共高速公路，上面跑着无数用户的数据。GTP-U 隧道就像给每辆车上挂一个唯一的车牌号（TEID），UPF 收到车看一眼车牌就知道这是谁的数据、该往哪转。

一个 PDU 会话要双向通信，需要两个方向的隧道端点都配齐：

• 上行（UE → UPF）：UPF 分配一个 N3 侧的 TEID，告诉基站"上行数据发到这个 TEID"；
• 下行（UPF → UE）：基站分配一个 N3 侧的 TEID，告诉 UPF"下行数据发到这个 TEID"。

这两个 TEID 不是一开始就都有的——这是初学者最容易踩坑的地方，也是整条流程"分两段、要倒回去一次"的根本原因。下面看流程时就明白了。

五、完整流程：一次 PDU 会话建立的信令时序

下面是端到端的时序图（注册和安全认证之后发生）。请重点体会流程为什么会被"分成上下两半"：

sequenceDiagram
    autonumber
    participant UE
    participant RAN as (R)AN 基站
    participant AMF
    participant SMF
    participant UDM
    participant PCF
    participant UPF

    Note over UE,UPF: 第一阶段：请求与SMF选择
    UE->>AMF: PDU Session Establishment Request (N1 NAS)
    AMF->>SMF: 按 S-NSSAI + DNN 选 SMF, CreateSMContext (含N1容器)

    Note over SMF,PCF: 第二阶段：签约与策略
    SMF->>UDM: 获取签约数据 (Session-AMBR/默认5QI/允许的DNN)
    SMF->>PCF: 建立 SM 策略关联, 拿 PCC 规则
    SMF->>SMF: 选择 UPF (按位置/切片/负载/DNAI)

    Note over SMF,UPF: 第三阶段：N4建立，先拿到UPF侧隧道
    SMF->>UPF: N4 PFCP Session Establishment Request (PDR/FAR/QER)
    UPF-->>SMF: N4 Response (返回 CN Tunnel Info = N3 上行 TEID)
    SMF-->>AMF: CreateSMContext Response (含N1 Accept + N2信息)

    Note over AMF,UE: 第四阶段：建无线承载，拿到基站侧隧道
    AMF->>RAN: N2 PDU Session Resource Setup (带 UPF 上行TEID + QoS)
    RAN->>UE: RRC Reconfiguration (建DRB, 带N1 PDU Session Accept + IP)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>AMF: N2 Setup Response (返回 AN Tunnel Info = 下行 TEID)

    Note over SMF,UPF: 第五阶段：把基站TEID告诉UPF，打通下行
    AMF->>SMF: UpdateSMContext (转发 AN Tunnel Info)
    SMF->>UPF: N4 Modification (配置下行FAR, 填入gNB TEID)
    UPF-->>SMF: N4 Mod Response
    Note over UE,UPF: 🎉 双向数据通路打通!

整个过程可以归纳为"五个阶段、一次回马枪"。下面逐阶段拆解，重点讲清楚"为什么"。

六、五阶段详解：每一步的设计意图

阶段一：请求与 SMF 选择（建立会话的"立项"）

手机发起请求时，会带上三个最关键的身份信息：

• PDU Session ID：手机自己分配，唯一标识这条会话；
• S-NSSAI：我要用哪个网络切片；
• DNN：我要接入哪个数据网络（类似 4G 的 APN，比如 internet 还是 company-vpn）。

AMF 收到后做一件关键的事：根据切片和 DNN 选择 SMF。这里有个设计巧思——AMF 不直接管会话，而是把会话管理职责"外包"给专门的 SMF。为什么不让 AMF 一把抓？ 因为一个用户可能同时有多个 PDU 会话（比如一条上互联网、一条连企业内网、一条连边缘工业网），这些会话可能由不同的 SMF 管理（不同切片/不同厂商/不同地域）。AMF 负责接单和移动性，SMF 负责每个会话的生命周期，职责正交、互不耦合。

AMF 把手机的 NAS 消息（N1 容器）原封不动透传给选中的 SMF，并附上 UE 的位置信息、RAT 类型等上下文，请求创建 SM Context（会话管理上下文）。

阶段二：签约核验与策略建立（拿到"规章制度"）

SMF 此时还不知道这个用户能干什么，于是它分两路取证：

1. 问 UDM 要签约数据：这个用户的套餐允许用哪些 DNN？总速率上限 Session-AMBR 是多少？默认的 QoS 等级（5QI）是什么？默认的 SSC 模式是什么？
2. 问 PCF 要策略：基于用户等级、时段、网络拥塞情况，PCF 决定具体的 QoS 规则、计费规则、流量路由策略。

为什么要把签约（UDM）和策略（PCF）分成两个网元？ 签约是"静态的、用户相关的"事实（你买了什么套餐）；策略是"动态的、网络相关的"决策（现在网络拥塞，给你限速）。分开存放，套餐变更不触发策略重算，策略调整不影响签约档案，灵活性和解耦度都更高。

同时，SMF 根据用户位置、切片、负载、DNAI（数据网络接入标识）等选择 UPF。如果用户要接边缘计算，就选靠近用户的 UPF；要接漫游网络，可能要串联中间 UPF。

阶段三：N4 会话建立（配置 UPF，拿到上行隧道）⭐

这是整条流程最核心的一步。SMF 把算好的一整套规则（PDR/FAR/QER）通过 PFCP 下发给 UPF，并请求 UPF 为这条会话分配一个核心网侧的隧道端点（CN Tunnel Info，即 N3 上行方向的 TEID）。

UPF 安装规则后，回送给 SMF 它分配的 TEID。此时 UPF 已经"整装待发"——它知道怎么识别这个用户的包、怎么限速、往哪记账，上行方向已就绪（一旦基站把数据发到这个 TEID，UPF 就能转发出去）。

但下行方向还不行——因为 UPF 还不知道基站在哪里、该把下行数据发到哪个 TEID。这个信息要等下一步基站建好无线承载后才知道。

阶段四：无线资源建立（建 DRB，拿到基站隧道）

SMF 把 UPF 的上行 TEID 和 QoS 参数，通过 AMF 转给基站（N2 消息）。基站据此：

1. 与手机之间建立 DRB（数据无线承载）——这是空口上真正的"数据高速公路"；
2. 把 PDU Session Establishment Accept 消息（含分配给手机的 IP 地址、QoS 规则）通过 RRC 消息带给手机；
3. 自己分配一个 AN Tunnel Info（基站侧 N3 下行 TEID），回复给 AMF。

此刻，手机到基站、基站到 UPF 的上行通路全部打通，手机可以发上行数据了。手机也拿到了自己的 IP 地址（比如 10.45.0.5），可以开始组装 IP 包。

阶段五：下行隧道打通（回马枪）⭐

最后一步是流程里那个"回马枪"：AMF 把基站返回的 AN Tunnel Info 转给 SMF，SMF 再通过 N4 会话修改消息把它填进 UPF 的下行 FAR 规则里。此时 UPF 终于知道——"哦，这个用户的下行数据，要封装成 GTP-U 发到基站这个 TEID"。

至此，双向数据通路彻底打通：

$$ \text{Uplink:}\; UE \xrightarrow{\text{DRB}} gNB \xrightarrow{\text{GTP-U/TEID}_{UPF}} UPF \xrightarrow{\text{N6}} DN $$

$$ \text{Downlink:}\; DN \xrightarrow{\text{N6}} UPF \xrightarrow{\text{GTP-U/TEID}_{gNB}} gNB \xrightarrow{\text{DRB}} UE $$

同时，SMF 会把自己的身份（SMF ID + PDU Session ID）注册到 UDM，方便后续切换、寻呼时能找到它。

为什么流程要分成"上下两半"？ 因为隧道端点是对端临时分配的，存在循环依赖：UPF 的 TEID 要告诉基站，基站的 TEID 要告诉 UPF，二者都无法在第一时间就知道对方的值。所以设计者采取"先建一半、拿到对方端点后回头补另一半"的策略——这是控制面/用户面分离架构下不可避免的一次"往返"，理解了它，你就理解了为什么流程里有两次 N4 交互。

七、一个关键设计哲学：为什么把 UPF 做得"又傻又快"

你可能已经注意到，整条流程里 SMF 忙得不可开交（取签约、建策略、选 UPF、配 IP、两次下发 N4、回填隧道），而 UPF 看起来"很闲"——它只是收规则、分配 TEID、转发包。

这是刻意的。通信网络有个永恒矛盾：控制面需要灵活和智能（要算策略、做决策），用户面需要极致的速度（线速转发海量流量）。两者对硬件特性的要求完全相反：

把它们拆开，意味着可以独立扩展：流量涨了就堆 UPF，用户数涨了就堆 SMF；UPF 用智能网卡/可编程交换机加速，SMF 用普通服务器虚拟化运行。这就是"软硬件解耦、控制用户面分离"的全部价值。理解这一点，你就明白为什么 5G 能轻松支持 Tbps 级别的转发——复杂的事让"聪明的脑"做，简单的事让"快手的脚"做。

八、UPF 选择与多 UPF：从单点到拓扑

前面提到 SMF 会"选 UPF"。实际现网中，UPF 不是孤零零一个，而是一个拓扑。常见场景：

• 单锚点：一个 PSA UPF（PDU Session Anchor，会话锚点）直连数据网络，最简单；
• 中间 UPF（I-UPF）：当用户离锚点 UPF 很远时，插入一个中间 UPF 做本地分流或中继，降低时延；
• 多锚点 / UL-CL 上行分类器：一个会话同时连到多个数据网络（比如同时接互联网和边缘 MEC），UPF 根据目的地址把流量分流到不同出口。

flowchart LR
    UE --> RAN
    RAN --> IUPF["I-UPF 中间节点"]
    IUPF -->|分流| PSA1["PSA-UPF 锚点1 → 互联网"]
    IUPF -->|分流| PSA2["PSA-UPF 锚点2 → 边缘MEC/企业网"]
    classDef up fill:#fce8e6,stroke:#ea4335,stroke-width:2px
    class IUPF,PSA1,PSA2 up

这种灵活的"UPF 编排"能力，是 5G 网络切片和边缘计算能落地的物理基础——SMF 通过 DNAI（Data Network Access Identifier）参数精确控制每个会话"挂"在哪个/哪些 UPF 上。

九、工程师实战：调试时在哪里用这套知识

理论讲完，落到调试。PDU 会话建立失败是现网最常见的一类故障，掌握下面的排查路径能省下大量时间。

9.1 抓包与关键信令点

• N1/NAS 侧：在 AMF 抓 NAS 消息，确认手机发的 PDU Session Establishment Request 是否到达，看 Reject 原因值（比如 27=missing or unknown DNN、67=insufficient resources）。
• N11/SBI 侧：看 AMF 是否成功选到 SMF，CreateSMContext 是否成功（失败常因切片/DNN 配置缺失或 NRF 发现不到 SMF）。
• N4/PFCP 侧：在 UPF 抓 PFCP，确认规则是否下发成功；最经典的失败是 PFCP Session Establishment Reject，常因 UPF 资源不足或规则冲突。
• N2/NGAP 侧：看基站是否成功建 DRB；基站回的 PDU Session Resource Setup Response 若带失败列表，多半是无线资源不足或 QoS 无法满足。

9.2 常见故障与陷阱

最大的调试陷阱：很多人看到"UE 拿到 IP"就以为会话建好了——错。拿到 IP 只说明阶段四完成（上行可用），下行要等阶段五的 N4 Modification 成功才真正打通。下行不通却到处查无线侧，是新人最常犯的方向性错误。

十、常见问题

Q1：PDU 会话和 EPS 承载到底什么关系？为什么 5G 换了个名字？ A：EPS 承载是 4G 里"一条 QoS 通路一个承载"的概念，粒度较粗且控制用户面耦合。5G 把它升级为"一个 PDU 会话内可包含多个 QoS Flow"，控制面（SMF）和用户面（UPF）彻底分离，并支持非 3GPP 接入统一管理。换名字是因为内核机制变了——PDU 会话是"会话 + 流"两级 QoS 架构，比承载灵活得多。

Q2：为什么 PDU 会话建立要走两次 N4（先 Establishment 后 Modification）？ A：因为隧道端点是对端动态分配的，存在循环依赖：UPF 的 TEID 要告诉基站，基站的 TEID 又要告诉 UPF。设计上只能"先建一半拿到对方端点、再回头补另一半"。第一次 N4 建立 UPF 侧规则和上行 TEID，第二次 N4 修改把基站的下行 TEID 回填进下行 FAR。

Q3：UPF 这么"傻"，只听 SMF 的规则，会不会成为瓶颈或单点故障？ A：UPF 的"傻"是优势——简单的查表转发能用硬件/智能网卡做线速加速。瓶颈通过分布式部署 + 独立扩容解决（堆 UPF 实例）。单点故障靠多 UPF 冗余和会话级故障转移机制应对。真正复杂的策略都在 SMF，而 SMF 的信令吞吐远低于 UPF 的数据吞吐，用普通服务器虚拟化即可承载。

Q4：Session-AMBR 和 QoS Flow 的 MFBR 有什么区别？ A：MFBR（最大比特率） 限制的是单个 QoS Flow 的速率，比如某条视频流的峰值；Session-AMBR 限制的是整个 PDU 会话所有 non-GBR 流加起来的总速率。手机同时跑多个 App 时，Session-AMBR 是"套餐总量上限"，由 UPF 的 QER 统一在会话级别聚合执行：

$$ \sum_{\text{flows} \in \text{Session}_{\text{non-GBR}}} r_i \;\leq\; \text{Session-AMBR} $$

Q5：不注册能不能建立 PDU 会话？ A：不能。PDU 会话建立发生在注册流程和安全认证之后。手机必须先注册到网络、完成 5G-AKA 鉴权，建立安全上下文，之后所有 NAS 信令（包括 PDU 会话请求）才被加密保护。这也是为什么流程开始前强调"所有消息都是加密的"——没有安全地基，谈不上会话。

十一、参考来源

1. 核心网-5GC PDU 会话建立流程 — kokomi 的笔记本 — 详细的 21 步分阶段信令拆解，含网络架构图与异常处理，是目前中文社区最清晰的 PDU 流程图解之一。
2. PDU session establishment in 5G — Spencer's Blog — 带具体 TEID/IP 示例的逐步讲解，给出了上行/下行数据通路的具体走法，适合建立工程直觉。
3. 5G UE 注册-建立会话-释放会话-注销信令流程 — 博客园 — 端到端信令流程串联，从注册到会话到释放的全生命周期视角。
4. PFCP Software Architecture within UPF — free5GC 官方文档 — 开源 5G 核心网项目中 UPF 的 PFCP 架构设计，含 PDR/FAR/QER 在代码层面的实现思路。
5. Understanding 5G User Plane Setup: PDU Session Update and UPF Activation — TelecomTrainer — 用户面建立与 UPF 激活机制的英文教程，侧重 N4/UPF 视角。

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