5G PDU会话建立信令全链拆解：从NAS请求到数据面打通

基于 3GPP TS 23.502 V18.9.0 Section 4.3.2.2.1 深度解读

一、PDU会话建立：5G数据面打通的核心仪式

在5G系统中，PDU Session是UE与数据网络（DN）之间的逻辑连接，等同于4G EPS中的PDN Connection。但与4G不同的是，5G的PDU Session建立流程涉及8个网络功能之间的协同：UE、(R)AN、AMF、SMF、UPF、PCF、UDM、NRF，跨越N1/N2/N4/N7/N10/N11六条关键参考点。

本文聚焦 TS 23.502 Section 4.3.2.2.1 定义的"UE发起的PDU Session建立（非漫游和LBO场景）"，逐步拆解全部21个步骤中每条消息的关键IE，揭示5G QoS Flow模型的精妙设计。

触发场景

PDU Session建立流程在以下四种场景触发：

二、完整信令时序图

以下时序图展示了TS 23.502 Section 4.3.2.2.1定义的完整21步流程：

sequenceDiagram
    participant UE as UE
    participant RAN as (R)AN/gNB
    participant AMF as AMF
    participant SMF as SMF
    participant UDM as UDM
    participant PCF as PCF
    participant UPF as UPF

    Note over UE,UPF: Phase 1: NAS请求与SM Context创建 (Step 1-5)
    UE->>AMF: Step 1: NAS UL NAS Transport<br/>(PDU Session Establishment Request)
    Note right of AMF: Step 2: AMF确定S-NSSAI/DNN<br/>执行SMF选择
    AMF->>SMF: Step 3: Nsmf_PDUSession_CreateSMContext Request
    SMF->>UDM: Step 4: Nudm_SDM_Get/Subscribe<br/>(获取SM订阅数据)
    SMF-->>AMF: Step 5: Nsmf_PDUSession_CreateSMContext Response

    Note over UE,UPF: Phase 2: 策略控制与UPF选择 (Step 6-9)
    Note over SMF: Step 6: [可选] 二次认证/授权
    SMF->>PCF: Step 7a: Npcf_SMPolicyControl_Create<br/>(建立SM策略关联)
    PCF-->>SMF: Step 7b: PCC Rules + QoS参数
    Note over SMF: Step 8: SMF选择SSC Mode<br/>选择UPF, 分配IP地址
    SMF->>PCF: Step 9: [可选] Npcf_SMPolicyControl_Update

    Note over UE,UPF: Phase 3: N4会话与用户面资源建立 (Step 10-14)
    SMF->>UPF: Step 10a: N4 Session Establishment Request<br/>(PDR/FAR/QER/URR规则)
    UPF-->>SMF: Step 10b: N4 Session Establishment Response<br/>(CN Tunnel Info)
    SMF->>AMF: Step 11: Namf_Communication_N1N2MessageTransfer<br/>(N1 SM + N2 SM Info)
    AMF->>RAN: Step 12: N2 PDU Session Resource Setup Request
    RAN->>UE: Step 13: RRC Reconfiguration<br/>(DRB建立 + NAS转发)
    RAN-->>AMF: Step 14: N2 PDU Session Resource Setup Response<br/>(AN Tunnel Info)

    Note over UE,UPF: Phase 4: 数据面打通与注册 (Step 15-17)
    AMF->>SMF: Step 15: Nsmf_PDUSession_UpdateSMContext
    SMF->>UPF: Step 16a: N4 Session Modification Request<br/>(提供AN Tunnel Info)
    UPF-->>SMF: Step 16b: N4 Session Modification Response
    SMF->>UDM: Step 16c: Nudm_UECM_Registration
    SMF-->>AMF: Step 17: Nsmf_PDUSession_UpdateSMContext Response

    Note over UE,UPF: Phase 5: 后续处理 (Step 18-21)
    Note over SMF: Step 18: [失败时] 通知释放SM Context
    Note over SMF: Step 19: [IPv6] 发送Router Advertisement
    Note over SMF,UPF: Step 20-21: 5GS Bridge/Router处理

三、逐步IE级深度解析

Phase 1：NAS请求与SM Context创建（Step 1-5）

Step 1：UE → AMF — NAS UL NAS Transport

UE通过UL NAS TRANSPORT消息（TS 24.501 Section 8.2.7）携带N1 SM容器，内含PDU SESSION ESTABLISHMENT REQUEST（TS 24.501 Section 8.3.1）。

PDU SESSION ESTABLISHMENT REQUEST消息IE详解（TS 24.501 Table 8.3.1.1.1）：

设计意图：UE在Request中提供"能力声明"（5GSM capability）和"偏好声明"（SSC mode、PDU session type），但不提供具体的QoS需求——QoS由网络侧的PCF基于订阅数据决策。这种"UE声明能力、网络决定策略"的设计哲学贯穿整个5G QoS模型。

Step 2：AMF处理 — SMF选择

AMF收到请求后，执行以下决策：

1. 确定S-NSSAI：基于UE请求的S-NSSAI和Allowed NSSAI
2. 确定DNN：基于UE请求的DNN或UDM中的默认DNN
3. SMF选择：查询NRF（Nnrf_NFDiscovery），基于S-NSSAI + DNN + UE位置选择合适的SMF实例

SMF选择的输入参数（TS 23.501 Section 6.3.2）： - S-NSSAI（网络切片标识） - DNN（数据网络名称） - UE Location（TAI + Cell Identity） - PLMN ID - 是否需要IP地址保存（SSC Mode 2/3场景）

Step 3：AMF → SMF — Nsmf_PDUSession_CreateSMContext Request

这是N11接口（AMF-SMF）上的SBI服务调用，定义于TS 29.502 Section 5.2.2.2。

graph TD
    A[AMF] -->|"HTTP POST<br/>/nsmf-pdusession/v1/sm-contexts"| B[SMF]

    subgraph Request Body
        C1[SUPI]
        C2[DNN]
        C3[S-NSSAI]
        C4[PDU Session ID]
        C5[AMF ID]
        C6[Request Type]
        C7[N1 SM Container]
        C8[User Location Info]
        C9[Access Type]
        C10[RAT Type]
        C11[PEI]
        C12[GPSI]
    end

关键参数说明：

HTTP方法：POST，URL为 {apiRoot}/nsmf-pdusession/v1/sm-contexts

成功响应：201 Created，Location header包含SM Context的URI 失败响应：4xx/5xx，body中包含SmContextCreateError（含PDU Session Reject的N1 SM信息）

Step 4：SMF → UDM — 获取订阅数据

SMF调用Nudm_SDM_Get（TS 29.503）获取Session Management订阅数据，包括：

SMF同时调用Nudm_SDM_Subscribe订阅数据变更通知，确保UE订阅数据更新时能及时感知。

Step 5：SMF → AMF — 创建SM Context响应

如果Step 4中订阅数据验证失败（如请求的DNN不在允许列表中），SMF直接返回PDU SESSION ESTABLISHMENT REJECT（封装在N1 SM Container中），Cause值可能为： - #27 "Missing or unknown DNN" - #28 "Unknown PDU session type" - #43 "Invalid PDU session identity"

Phase 2：策略控制与UPF选择（Step 6-9）

Step 7a/7b：SMF → PCF — SM策略关联建立

SMF调用Npcf_SMPolicyControl_Create（TS 29.512 Section 4.2.2.2），建立SM策略关联。这是N7接口上的核心交互。

SMF提供给PCF的关键信息：

PCF返回的PCC Rules包含：

Step 8：UPF选择与IP地址分配

UPF选择是SMF最关键的决策之一，选择依据（TS 23.501 Section 6.3.3）：

1. DNN + S-NSSAI：匹配UPF支持的数据网络和切片
2. UE Location：选择就近的UPF（降低时延）
3. DNAI（Data Network Access Identifier）：用于边缘计算场景的本地分流
4. UPF负载和能力：通过NRF获取UPF实例信息
5. SSC Mode：SSC Mode 2/3可能需要特定UPF支持

IP地址分配：SMF负责为UE分配IP地址/前缀，方式包括： - IPv4：SMF本地分配或通过DHCPv4 - IPv6：通过IPv6前缀委派或无状态地址自动配置（SLAAC） - IPv4v6：同时分配IPv4地址和IPv6前缀

Phase 3：N4会话与用户面资源建立（Step 10-14）

Step 10a/10b：SMF → UPF — N4会话建立

这是N4接口上的PFCP协议交互（TS 29.244 Section 7.5.2/7.5.3）。

graph TB
    subgraph "PFCP Session Establishment Request (SMF→UPF)"
        A1[Node ID - 必选]
        A2[CP F-SEID - 必选<br/>SMF的PFCP会话端点标识]
        A3[Create PDR - 必选<br/>包检测规则]
        A4[Create FAR - 必选<br/>转发动作规则]
        A5[Create URR - 条件必选<br/>使用量报告规则]
        A6[Create QER - 条件必选<br/>QoS执行规则]
        A7[S-NSSAI - 可选]
        A8[User Plane Inactivity Timer - 可选]
        A9[APN/DNN - 可选]
    end

    subgraph "PFCP Session Establishment Response (UPF→SMF)"
        B1[Node ID - 必选]
        B2[Cause - 必选<br/>成功/部分成功/拒绝]
        B3[UP F-SEID - 条件必选<br/>UPF的PFCP会话端点]
        B4[Created PDR - 条件必选<br/>含Local F-TEID + UE IP]
    end

    A1 & A2 & A3 & A4 & A5 & A6 --> B1 & B2 & B3 & B4

PFCP四大规则体系：

PDR与FAR的关联关系：每个PDR引用一个FAR ID，指示检测到的数据包应该如何处理。

F-TEID（Fully Qualified TEID）：UPF在Response中返回的CN Tunnel Info包含： - UPF IP地址（用于GTP-U隧道） - TEID值（隧道端点标识）

这个隧道信息将通过SMF→AMF→RAN传递给gNB，用于建立N3接口的GTP-U隧道。

Step 11：SMF → AMF — N1N2消息传递

SMF调用Namf_Communication_N1N2MessageTransfer（TS 29.518 Section 5.2.2.3），这是一个"双信封"消息：

N2 SM Information关键IE（用于NGAP）：

PDU SESSION ESTABLISHMENT ACCEPT消息IE详解（TS 24.501 Table 8.3.2.1.1）：

Step 12-14：AMF → RAN → UE — NGAP与RRC交互

Step 12中，AMF向gNB发送PDU SESSION RESOURCE SETUP REQUEST（TS 38.413 Section 8.2.1）。

graph TD
    AMF -->|"NGAP: PDU SESSION RESOURCE<br/>SETUP REQUEST"| gNB
    gNB -->|"RRC Reconfiguration<br/>(DRB建立)"| UE
    gNB -->|"NGAP: PDU SESSION RESOURCE<br/>SETUP RESPONSE"| AMF

    subgraph "NGAP Request内容"
        D1[PDU Session ID]
        D2[QoS Flow List with QFI+QoS Profile]
        D3["UL NG-U UP TNL Information<br/>(UPF IP + TEID)"]
        D4[Session-AMBR]
        D5[Security Indication]
    end

    subgraph "NGAP Response内容"
        E1[PDU Session ID]
        E2["DL NG-U UP TNL Information<br/>(gNB IP + TEID)"]
        E3[Accepted QFI List]
        E4[Rejected QFI List + Cause]
    end

gNB的处理逻辑： 1. 为每个成功建立的PDU Session创建至少一个DRB（Data Radio Bearer） 2. 将每个accepted QoS Flow关联到DRB（多个QoS Flow可映射到同一DRB） 3. 存储UL NG-U UP TNL Information作为上行数据终点 4. 根据Security Indication决定是否启用用户面完整性保护和加密 5. 处理Session-AMBR，确保总速率不超限

Step 13中，gNB通过RRC Reconfiguration建立DRB，同时将PDU SESSION ESTABLISHMENT ACCEPT通过RRC容器转发给UE。

Step 14中，gNB返回PDU SESSION RESOURCE SETUP RESPONSE，包含： - AN Tunnel Info：gNB侧的N3隧道终点（IP + TEID） - Accepted QFI List：成功建立的QoS Flow - Rejected QFI List：未能建立的QoS Flow及原因（如资源不足）

Phase 4：数据面打通与注册（Step 15-17）

Step 15-16b：AN Tunnel Info回传与N4更新

AMF将gNB返回的AN Tunnel Info通过Nsmf_PDUSession_UpdateSMContext转发给SMF。SMF随即发起N4 Session Modification，将AN Tunnel Info提供给UPF，完成下行数据路径的打通。

此时，完整的N3双向GTP-U隧道已建立： - 上行：gNB → UPF（使用Step 10b中UPF提供的CN Tunnel Info） - 下行：UPF → gNB（使用Step 14中gNB提供的AN Tunnel Info）

Step 16c：SMF → UDM — 注册PDU Session

SMF调用Nudm_UECM_Registration向UDM注册自身为该PDU Session的 Serving SMF。这确保： - 后续UE移动时，新AMF能从UDM找到当前服务的SMF - UDM能通知SMF订阅数据变更

四、5G QoS Flow模型：与PDU Session建立的关系

PDU Session建立过程中，5G QoS Flow模型的几个关键操作同步完成：

graph TB
    subgraph "PDU Session"
        subgraph "Default QoS Flow (QFI=1)"
            F1["5QI=9 (Default)"]
            F2[ARP Priority=5]
            F3[Non-GBR]
        end
        subgraph "Dedicated QoS Flow (QFI=2) [可选]"
            F4["5QI=7 (IMS Voice)"]
            F5[ARP Priority=1]
            F6[GBR: GFBR=50Mbps]
        end
    end

    subgraph "SMF的QoS Flow绑定"
        G1[PCC Rule from PCF] --> G2{匹配已有QoS Flow?}
        G2 -->|Yes| G3[绑定到现有QoS Flow]
        G2 -->|No| G4[创建新QoS Flow<br/>分配新QFI]
    end

    F1 & F4 --> G1

QoS Flow的三个表征要素（TS 23.501 Section 5.7.1.1）：

QFI分配规则： - Non-GBR + standardized 5QI（值 < 64）：5QI值可直接用作QFI（如5QI=9, QFI=9） - 其他情况：SMF动态分配QFI，通过N2将QoS Profile和QFI一起提供给gNB - QFI在PDU Session内唯一，跨PDU Session不唯一

默认QoS Flow： - 每个PDU Session建立时必须创建一个默认QoS Flow - 默认QoS Flow始终为Non-GBR类型 - 关联的默认QoS Rule在每个PDU Session的生命周期内始终存在 - 默认QoS Rule的Packet Filter Set可以为空（匹配所有上行流量）

五、SSC Mode对UPF选择的影响

PDU Session建立过程中的SSC Mode选择直接影响UPF选择策略和会话连续性：

SSC Mode 1是最常见的模式，适用于大多数数据业务。SSC Mode 2/3主要用于需要UPF重定位的场景（如边缘计算中UE移动到新的边缘站点）。

六、NAS消息结构对比

REQUEST vs ACCEPT消息结构

graph LR
    subgraph "REQUEST (UE→Network)"
        R1[Extended Protocol Discriminator<br/>0x2E - 5GS SM]
        R2[PDU Session ID]
        R3[PTI]
        R4[Message Type: 0xC1]
        R5[Integrity Protection<br/>Max Data Rate]
        R6["PDU Session Type<br/>(可选)"]
        R7["SSC Mode<br/>(可选)"]
        R8["5GSM Capability<br/>(可选)"]
        R9["ePCO<br/>(可选)"]
    end

    subgraph "ACCEPT (Network→UE)"
        A1[Extended Protocol Discriminator<br/>0x2E - 5GS SM]
        A2[PDU Session ID]
        A3[PTI]
        A4[Message Type: 0xC2]
        A5[Selected PDU Session Type]
        A6[Selected SSC Mode]
        A7[Authorized QoS Rules<br/>★核心IE★]
        A8[Session AMBR]
        A9["PDU Address<br/>(分配的IP)"]
        A10["S-NSSAI<br/>(可选)"]
        A11["Authorized QoS Flow<br/>Descriptions (可选)"]
    end

    R1 & R2 & R3 --> A1 & A2 & A3

设计意图对比： - REQUEST中UE只提供"偏好和能力"，不包含具体QoS需求 - ACCEPT中网络做出"最终决定"：Selected PDU Session Type可能与请求不同（如请求IPv4v6但只授权IPv4） - QoS Rules是ACCEPT中最重要的IE，它告诉UE"哪些流量匹配哪个QoS Flow"，是UE上行分类的唯一依据

七、抓包识别与排错实战

7.1 抓包关键检查点

7.2 常见故障点与排错

stateDiagram-v2
    [*] --> INACTIVE: UE发起PDU Session<br/>Establishment Request
    INACTIVE --> CREATE_PENDING: SM Context创建成功<br/>(Step 5)
    CREATE_PENDING --> ACTIVE: N4建立+NGAP完成<br/>(Step 14确认)
    CREATE_PENDING --> INACTIVE: PDU Session Reject<br/>(任意步骤失败)
    ACTIVE --> MODIFICATION_PENDING: SMF或UE发起<br/>PDU Session Modification
    MODIFICATION_PENDING --> ACTIVE: Modification完成
    ACTIVE --> RELEASE_PENDING: UE或网络发起<br/>PDU Session Release
    RELEASE_PENDING --> INACTIVE: Release完成
    ACTIVE --> ACTIVE: SSC Mode 2/3<br/>UPF重定位

状态说明： - INACTIVE：PDU Session不存在，无SM Context - ACTIVE：PDU Session完全建立，数据面双向打通 - 任何中间步骤失败都会导致回退到INACTIVE，SMF负责释放已分配的资源

常见问题

Q: PDU Session建立和EPS PDN Connection建立的主要区别是什么？

A: 核心区别有三：(1) QoS模型不同——5G使用QoS Flow（QFI标识），4G使用EPS Bearer（EBI标识），QoS Flow更灵活，支持不建立专用Bearer的情况下添加QoS Flow；(2) 控制面协议不同——5G使用SBI（HTTP/2），4G使用Diameter/GTP-C；(3) SMF与UPF分离——5G中SMF通过PFCP协议控制UPF，4G中MME/SGW/PGW通过GTP-C交互。

Q: 为什么N4 Session需要两次交互（Establishment + Modification）？

A: 第一次（Establishment，Step 10a）在SMF获取UPF后立即执行，目的是向UPF下发PDR/FAR/QER规则并获取上行隧道信息（CN Tunnel Info）。第二次（Modification，Step 16a）发生在gNB返回下行隧道信息（AN Tunnel Info）后，SMF需要将gNB的隧道终点告诉UPF，才能打通下行数据路径。这种设计是因为gNB的隧道信息在PDU Session建立的后期才产生。

Q: QoS Rules和QoS Flow Descriptions有什么区别？

A: QoS Rules（TS 23.501 Section 5.7.1.4）是给UE用的，包含Packet Filter Set + QFI + Precedence，UE用它来决定上行数据包匹配哪个QoS Flow。QoS Flow Descriptions（TS 24.501 Section 9.11.4.13）是网络向UE通知QoS Flow参数变化用的，包含QFI + Operation Code（create/modify/delete）+ QoS Parameters。简单说，QoS Rules定义"怎么分类"，QoS Flow Descriptions定义"QoS参数是什么"。

Q: 抓包时如何判断PDU Session建立成功？

A: 完整的成功链路：NAS Request(0xC1) → HTTP 201 Created → PFCP Session Estab. Success → NGAP PDU Session Resource Setup Response（含AN Tunnel Info）→ PFCP Session Mod. Success → NAS Accept(0xC2)。任何一步出现异常（Reject、Failure Cause、4xx/5xx HTTP响应），PDU Session建立失败。最常见的失败点是NAS Reject和NGAP中的QFI Rejection。

Q: PDU Session ID的分配规则是什么？

A: PDU Session ID由UE自行分配（TS 24.501 Section 9.10.1），取值范围0-255。其中值0预留给紧急服务PDU Session。UE需确保同一时间没有两个活跃的PDU Session使用相同的ID。在EPS到5GS的互操作场景中，UE可能使用与EPS Bearer关联的PDU Session ID来指示已有的PDN Connection。

参考来源

1. 3GPP TS 23.502 V18.9.0 — Section 4.3.2.2.1: UE-requested PDU Session Establishment (Non-roaming and LBO)
2. 3GPP TS 24.501 V18.10.0 — Section 8.3.1/8.3.2: NAS PDU Session Establishment Request/Accept消息定义
3. 3GPP TS 29.244 V18.9.0 — Section 7.5.2/7.5.3: PFCP Session Establishment Request/Response
4. 3GPP TS 29.502 V18.10.0 — Section 5.2.2.2: Nsmf_PDUSession_CreateSMContext服务操作
5. 3GPP TS 38.413 V18.5.0 — Section 8.2.1: PDU Session Resource Setup NGAP过程
6. 3GPP TS 23.501 V18.9.0 — Section 5.7.1: QoS Flow模型与QFI定义
7. ShareTechnote - 5G PDU Session Establishment — 流程图解与步骤说明
8. free5GC - PFCP Session Lifecycle — 开源5GC实现中的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 等场景全覆盖。