<!-- title: 5G PDU会话建立全链路信令拆解 -->
<!-- domain: protocols -->

# 5G PDU Session Establishment全链路信令与QoS Flow建立深度拆解

## 一、为什么PDU Session Establishment是5GC最复杂的过程

PDU Session Establishment（TS 23.502 Section 4.3.2.2.1）是5G系统中**涉及NF最多、信令交互最长**的单次NAS过程。一次完整的UE-Initiated PDU Session Establishment需要穿越**UE → gNB → AMF → SMF → UDM → PCF → UPF**七个节点，产生至少15条信令消息。与4G EPS的PDN Connectivity相比，5G引入了**QoS Flow替代EPS Bearer**、**N4/PFCP替代Gx/GTP-C**、**SBI服务化接口替代Diameter**三大架构变革，使得这个过程的信息元素（IE）和决策路径远比4G复杂。

本文聚焦TS 23.502 V18.10.0 Figure 4.3.2.2.1-1定义的**UE-requested PDU Session Establishment for non-roaming**场景，逐条信令拆解关键IE，深入分析QoS Flow建立机制，并结合Wireshark抓包实战给出排错方法。

---

## 二、完整信令时序图

以下是TS 23.502 Section 4.3.2.2.1定义的完整UE-Initiated PDU Session Establishment流程：

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

    Note over UE,UPF: Phase 1: UE发起请求 → SMF创建SM Context
    UE->>gNB: NAS UL NAS TRANSPORT<br/>(PDU Session Establishment Request)
    gNB->>AMF: N2 UL NAS TRANSPORT<br/>(NAS PDU + User Location Info)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>(SUPI, DNN, S-NSSAI, PDU Session ID, AMF ID)
    SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(SM Context创建确认)

    Note over UE,UPF: Phase 2: SMF策略与订阅数据获取
    SMF->>UDM: Nudm_SDM_Get<br/>(SUPI, DNN, S-NSSAI)
    UDM-->>SMF: 订阅数据(Session AMBR, 5QI, subscribed DNN)
    SMF->>UDM: Nudm_SDM_Notification<br/>(注册SMF为serving SMF)
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(SUPI, DNN, S-NSSAI, PDU Session Type)
    PCF-->>SMF: PCC Rules (SDF, 5QI, ARP, GBR/MBR, Charging)

    Note over UE,UPF: Phase 3: UPF选择与N4会话建立
    SMF->>UPF: N4 Session Establishment Request<br/>(PDR, FAR, QER, URR, BAR)
    UPF-->>SMF: N4 Session Establishment Response<br/>(F-SEID, UPF N3 TEID)

    Note over UE,UPF: Phase 4: N1N2消息传递与空口资源建立
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N1 SM Container + N2 SM Info)
    AMF->>gNB: N2 PDU Session Resource Setup Request<br/>(NAS PDU + N2 SM Info + QoS Profile)
    gNB->>UE: RRC Reconfiguration<br/>(DRB配置 + NAS PDU Session Establishment Accept)
    UE-->>gNB: RRC Reconfiguration Complete
    gNB-->>AMF: N2 PDU Session Resource Setup Response<br/>(AN Tunnel Info + TEID)

    Note over UE,UPF: Phase 5: 数据面隧道打通
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(N2 SM Info: AN Tunnel Endpoint)
    SMF->>UPF: N4 Session Modification Request<br/>(更新FAR: AN Tunnel Endpoint)
    UPF-->>SMF: N4 Session Modification Response
    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
```

整个流程可清晰划分为**五个阶段**：SM Context创建、策略与订阅获取、UPF/N4会话建立、N1N2消息传递与空口资源配置、数据面隧道打通。其中**阶段4和阶段5是决定PDU Session能否真正可用的关键**——空口DRB建立和N3隧道打通缺一不可。

---

## 三、逐阶段关键IE深度解析

### 3.1 Phase 1：UE发起请求 → SMF创建SM Context

**NAS层：PDU Session Establishment Request**

UE通过NAS UL NAS TRANSPORT消息承载5GSM PDU Session Establishment Request，关键IE如下：

| IE名称 | 类型 | 说明 | TS引用 |
|--------|------|------|--------|
| PDU Session ID | Integer (0-255) | UE本地分配的会话标识 | TS 24.501 §9.11.3.41 |
| DNN | String | Data Network Name（等效4G APN） | TS 23.003 §28 |
| S-NSSAI | Composite | 切片选择信息（SST+SD） | TS 23.501 §5.15.2 |
| PDU Session Type | Enum | IPv4/IPv6/IPv4v6/Ethernet/Unstructured | TS 24.501 §9.11.3.42 |
| SSC Mode | Enum (1/2/3) | Session and Service Continuity模式 | TS 23.501 §5.6.5 |
| 5GSM Capability | Bitmap | UE支持的5GSM特性（Reflective QoS等） | TS 24.501 §9.11.3.18 |
| PCO (Protocol Config Options) | TLV | 请求的IP参数（DNS地址请求等） | TS 24.008 §10.5.6.3 |

**AMF行为**：AMF收到NAS消息后不解析5GSM内容，而是根据DNN和S-NSSAI进行**SMF选择**（TS 23.501 Section 6.3.2）。SMF选择可能通过NRF Discovery（`Nnrf_NFDiscovery`）完成，也可能使用AMF本地配置。选择完成后AMF调用`Nsmf_PDUSession_CreateSMContext Request`，携带SUPI、DNN、S-NSSAI、PDU Session ID、AMF ID、User Location Info等。

**设计意图**：AMF作为NAS消息的"中转站"，不参与会话管理决策。这种**控制面解耦**设计使得SMF可以独立演进，也使得AMF过载时不会因会话处理而进一步恶化。

### 3.2 Phase 2：SMF策略与订阅数据获取

SMF在创建SM Context后，需要获取**两份关键数据**：

**（1）UDM订阅数据获取（Nudm_SDM_Get）**

SMF调用`Nudm_SDM_Get`获取该用户在指定DNN和S-NSSAI下的签约数据：

```
Nudm_SDM_Get Response包含：
├── Session Management Subscription Data
│   ├── DNN Configuration
│   │   ├── PDU Session Types (allowed)
│   │   ├── SSC Modes (allowed)
│   │   ├── Default 5QI (通常为9)
│   │   ├── Default ARP
│   │   ├── Session-AMBR (UL/DL)
│   │   └── Subscribed IPv4/IPv6 prefix
│   ├── S-NSSAI
│   └── Interworking Information (EPS)
```

SMF同时调用`Nudm_SDM_Notification`（即SMF Register），将自己注册为该PDU Session的serving SMF。这样当UDM中订阅数据变更时，UDM可以通过`Nudm_SDM_Notification`通知SMF。

**（2）PCF策略关联建立（Npcf_SMPolicyControl_Create）**

SMF向PCF发起`Npcf_SMPolicyControl_Create`，建立SM Policy Association。PCF返回的PCC Rules是整个QoS Flow建立的**决策源头**：

```
PCC Rule (TS 29.512 Section 4.2.4):
├── Rule ID
├── SDF Template (Service Data Flow Filter)
│   └── Flow Description: permit out ip from <IP> to <IP> <port>
├── 5QI (e.g., 9 for default, 1 for voice)
├── ARP (Priority, Pre-emption Capability/Vulnerability)
├── MBR UL/DL (Maximum Bit Rate)
├── GBR UL/DL (Guaranteed Bit Rate)
├── Charging Key (Rating Group)
└── Precedence
```

SMF根据PCC Rule推导出：
- **QoS Flow**：将PCC Rule映射到QFI（QoS Flow Identifier）
- **N4 Rule**（PDR/FAR/QER/URR）下发给UPF
- **QoS Rule**通过NAS下发给UE
- **QoS Profile**通过N2下发给gNB

```mermaid
graph TB
    subgraph "PCF决策层"
        PCC[PCC Rule<br/>SDF + 5QI + ARP + GBR]
    end

    subgraph "SMF映射层"
        QF[QoS Flow<br/>QFI = 0x01]
        QR[QoS Rule → UE<br/>QoS Rule ID + Packet Filter]
        N4R[N4 Rules → UPF<br/>PDR + FAR + QER]
        QP[QoS Profile → gNB<br/>5QI + ARP + GBR]
    end

    PCC --> QF
    QF --> QR
    QF --> N4R
    QF --> QP

    style PCC fill:#e1f5fe
    style QF fill:#fff3e0
    style QR fill:#e8f5e9
    style N4R fill:#fce4ec
    style QP fill:#f3e5f5
```

**关键设计点**：SMF是整个QoS映射的**中枢**——它将PCF的策略意图翻译为三个不同维度的规则，分别面向UE（QoS Rule）、UPF（N4 Rule）和gNB（QoS Profile）。这种"一次决策、三维下发"的架构确保了端到端QoS一致性。

### 3.3 Phase 3：UPF选择与N4会话建立

SMF根据DNN、S-NSSAI、UE位置、UPF负载等信息选择UPF（TS 23.501 Section 6.3.3）。选择完成后发起N4会话建立（基于PFCP协议，TS 29.244）：

**N4 Session Establishment Request中的关键规则**：

| 规则类型 | 功能 | 关键IE |
|---------|------|--------|
| **PDR** (Packet Detection Rule) | 流量检测 | Source Interface (Access/Core)、UE IP Address、F-TEID、QFI、SDF Filter |
| **FAR** (Forwarding Action Rule) | 转发动作 | Forward/Drop/Buffer、Destination Interface、Outer Header Creation (N3 TEID) |
| **QER** (QoS Enforcement Rule) | QoS执行 | QFI、Gate Status、MBR UL/DL、GBR UL/DL |
| **URR** (Usage Reporting Rule) | 用量上报 | Measurement Method (Volume/Time/Event)、Reporting Triggers |
| **BAR** (Buffering Action Rule) | 缓冲动作 | Buffering Packet Count、Suggested Buffering Packets Time |

**典型N4规则组合（默认QoS Flow）**：

```
PFCP Session Establishment Request:
├── Create PDR #1 (UL)
│   ├── Source Interface: ACCESS (from gNB)
│   ├── F-TEID: allocate new (检测UL GTP隧道)
│   ├── QFI: 0x09 (5QI=9, default non-GBR)
│   └── FAR ID: → FAR #1
├── Create PDR #2 (DL)
│   ├── Source Interface: CORE (from DN)
│   ├── UE IP Address: 10.1.1.x
│   ├── SDF Filter: (empty → catch-all)
│   └── FAR ID: → FAR #2
├── Create FAR #1 (UL→DN)
│   ├── Action: FORWARD
│   └── Destination Interface: CORE
├── Create FAR #2 (DL→gNB, initially BUFFER)
│   ├── Action: FORW (after AN tunnel info received)
│   ├── Destination Interface: ACCESS
│   └── Outer Header Creation: (待SMF收到AN Tunnel后更新)
├── Create QER #1
│   ├── QFI: 0x09
│   └── Gate: OPEN
└── Create URR #1
    ├── Measurement Method: VOLUME
    └── Reporting Trigger: TIME_QUOTA
```

**UPF的N4 Session Establishment Response**携带F-SEID（F-fully qualified SEID）和UPF侧的N3 TEID——这是后续gNB发往UPF的GTP隧道端点标识。

### 3.4 Phase 4：N1N2消息传递与空口资源建立

SMF通过`Namf_Communication_N1N2MessageTransfer`（TS 29.518 Section 6.1）将两份信息打包发送给AMF：

- **N1 SM Container**：`PDU Session Establishment Accept`（给UE的NAS消息）
- **N2 SM Information**：PDU Session Resource Setup参数（给gNB的NGAP信息）

**PDU Session Establishment Accept中的关键IE**（TS 24.501 Section 9.11.3.2）：

| IE | 说明 |
|----|------|
| PDU Session ID | 确认的会话标识 |
| Selected PDU Session Type | 网络确认的类型（如IPv4） |
| Selected SSC Mode | 网络确认的SSC模式 |
| QoS Rule(s) | **核心IE**：含Default QoS Rule和可选Dedicated QoS Rule |
| Session-AMBR | 会话聚合最大比特率（UL/DL） |
| PDU Address | 分配的IP地址（IPv4: 如10.1.1.100） |
| DNN | 确认的DNN |
| 5GSM Cause | 建立结果（值为#26 "text strings insufficient" 等指示成功） |

**Default QoS Rule的结构**（TS 24.501 Section 9.11.4.3）：

```
QoS Rule:
├── QoS Rule Identifier: 1 (默认规则ID)
├── QFI: 0x09 (对应5QI=9)
├── Packet Filter Count: 0  ← 无包过滤器=catch-all
├── Precedence: 255 (最低优先级)
├── QoS Parameters:
│   ├── 5QI: 9 (Non-GBR, Default)
│   └── ARP: Priority=15, Pre-emption=No, Vulnerable=No
└── Authorization QoS:
    └── Session-AMBR: UL=100Mbps, DL=1Gbps
```

**N2 SM Information**（通过NGAP PDU Session Resource Setup传递给gNB）：

```
N2 SM Information:
├── PDU Session ID
├── S-NSSAI
├── QoS Flow Setup Request List
│   └── QoS Flow Item:
│       ├── QFI: 0x09
│       ├── QoS Profile:
│       │   ├── 5QI: 9
│       │   ├── ARP: Priority=15
│       │   └── Session-AMBR
│       └── UL/DL TNL Information (UPF N3 TEID)
├── PDU Session Type: IPv4
└── SGW UPF N3 TEID + IP Address
```

**gNB处理**：gNB收到N2 PDU Session Resource Setup Request后执行：
1. 根据QoS Profile建立DRB（Data Radio Bearer）
2. 将NAS PDU Session Establishment Accept通过RRC Reconfiguration带给UE
3. 分配AN侧N3 Tunnel Endpoint（gNB TEID + IP）
4. 通过N2 PDU Session Resource Setup Response返回AN Tunnel Info

### 3.5 Phase 5：数据面隧道打通

AMF将gNB返回的AN Tunnel Info通过`Nsmf_PDUSession_UpdateSMContext Request`转发给SMF。SMF收到后：

1. **更新UPF的FAR**：SMF向UPF发送N4 Session Modification Request，将FAR #2的DL方向从BUFFER状态改为FORWARD，并填入gNB的N3 TEID和IP地址
2. UPF确认后，**N3下行隧道打通**
3. 此时UPF可以下行发送数据包到gNB，gNB通过DRB转发给UE
4. 上行方向：UE发送上行数据包 → gNB封装到GTP（N3）→ UPF → DN

**至此，PDU Session全链路打通。**

---

## 四、QoS Flow建立机制深度分析

### 4.1 Default QoS Flow vs Dedicated QoS Flow

PDU Session建立时，**至少建立一个Default QoS Flow**。这个Flow的QFI通常为默认值，5QI为9（Non-GBR best effort），且其QoS Rule**不包含Packet Filter**——这意味着所有未被其他QoS Rule匹配的上行流量都映射到这个Flow。

```mermaid
graph TD
    subgraph "UE上行包分类"
        PKT1[上行IP包<br/>SIP:5060] -->|匹配Rule #2<br/>TFT: port=5060| QF2[QoS Flow #2<br/>QFI=1, 5QI=1<br/>IMS语音]
        PKT2[上行IP包<br/>TCP:80] -->|无匹配<br/>Catch-all| QF1[QoS Flow #1<br/>QFI=9, 5QI=9<br/>Default Best Effort]
    end

    subgraph "gNB DRB映射"
        QF2 --> DRB2[DRB #2<br/>5QI=1, GBR]
        QF1 --> DRB1[DRB #1<br/>5QI=9, Non-GBR]
    end

    subgraph "UPF N3封装"
        DRB2 --> GTP2[GTP-U<br/>QFI=1 in ext header]
        DRB1 --> GTP1[GTP-U<br/>QFI=9 in ext header]
    end

    GTP2 --> N6[DN / IMS]
    GTP1 --> N6

    style QF2 fill:#ffcdd2
    style QF1 fill:#c8e6c9
```

**注意**：gNB有权将多个QoS Flow复用到同一个DRB上（只要5QI兼容），这是gNB的**本地决策**，SMF不控制DRB映射。

### 4.2 三方规则映射关系

| 维度 | UE侧 | gNB侧 | UPF侧 |
|------|-------|--------|--------|
| **规则名称** | QoS Rule | QoS Profile | PDR + FAR + QER |
| **携带方式** | NAS SM Container | N2 SM Info (NGAP) | N4/PFCP |
| **流量分类** | Packet Filter (TFT) | 不做包级分类，按QFI映射DRB | SDF Filter (PDR) |
| **QoS标识** | QFI + 5QI | QFI + 5QI + GBR参数 | QFI (QER) |
| **优先级** | QoS Rule Precedence | ARP Priority | PDR Precedence |
| **默认规则** | Default QoS Rule（无filter） | Default QoS Profile | Default PDR（无SDF） |

### 4.3 QoS Flow的标准化5QI映射表（TS 23.501 Table 5.7.4-1摘录）

| 5QI | Resource Type | Priority Level | PDB | PER | 典型业务 |
|-----|--------------|----------------|-----|-----|---------|
| 1 | GBR | 20 | 100ms | 10⁻² | VoNR语音 |
| 2 | GBR | 40 | 150ms | 10⁻³ | VoNR视频通话 |
| 4 | Non-GBR | 70 | 300ms | 10⁻⁶ | 视频流媒体 |
| 7 | Non-GBR | 70 | 100ms | 10⁻³ | 语音/视频/交互 |
| 9 | Non-GBR | 90 | 300ms | 10⁻⁶ | **默认互联网** |
| 69 | Non-GBR | 55 | 60ms | 10⁻⁶ | IMS信令（SIP） |
| 80 | Non-GBR | 68 | 10ms | 10⁻⁶ | 低延迟V2X |
| 84 | Delay Critical GBR | 25 | 30ms | 10⁻⁵ | 工业以太网 |
| 128 | Non-GBR | 50 | 70ms | 10⁻⁶ | AR/VR |

---

## 五、状态转换与生命周期

```mermaid
stateDiagram-v2
    [*] --> PDU_SESSION_NOT_EXIST: UE Power On
    PDU_SESSION_NOT_EXIST --> PDU_SESSION_INACTIVE: PDU Session<br/>Establishment Request
    PDU_SESSION_INACTIVE --> PDU_SESSION_ACTIVE: 收到PDU Session<br/>Establishment Accept
    PDU_SESSION_ACTIVE --> PDU_SESSION_MODIFICATION: UE/Network发起<br/>PDU Session Modification
    PDU_SESSION_MODIFICATION --> PDU_SESSION_ACTIVE: Modification Complete
    PDU_SESSION_ACTIVE --> PDU_SESSION_INACTIVE: UE进入CM-IDLE<br/>(AN Release)
    PDU_SESSION_INACTIVE --> PDU_SESSION_ACTIVE: Service Request<br/>(恢复AN资源)
    PDU_SESSION_ACTIVE --> PDU_SESSION_NOT_EXIST: PDU Session<br/>Release
    PDU_SESSION_INACTIVE --> PDU_SESSION_NOT_EXIST: PDU Session<br/>Release

    note right of PDU_SESSION_ACTIVE
        CM-CONNECTED状态下
        N3隧道+DRB均激活
        可收发用户数据
    end note

    note right of PDU_SESSION_INACTIVE
        CM-IDLE状态下
        AN资源释放
        N3隧道保留但无活跃承载
        UPF缓冲下行数据
    end note
```

---

## 六、抓包识别与实战排错

### 6.1 Wireshark过滤技巧

| 过滤器 | 用途 |
|--------|------|
| `nas-5gs.sm.message_type == 0xc1` | 过滤PDU Session Establishment Request |
| `nas-5gs.sm.message_type == 0xc2` | 过滤PDU Session Establishment Accept |
| `nas-5gs.sm.message_type == 0xc3` | 过滤PDU Session Establishment Reject |
| `ngap.procedureCode == 36` | N2 PDU Session Resource Setup |
| `pfcp.message_type == 50` | PFCP Session Establishment Request |
| `pfcp.message_type == 51` | PFCP Session Establishment Response |

### 6.2 常见故障点与排错思路

| 故障阶段 | 现象 | 可能原因 | 排错方法 |
|---------|------|---------|---------|
| Phase 1 | SMF返回CreateSMContext失败 | DNN未配置、S-NSSAI不匹配、SMF过载 | 检查AMF日志中SMF Selection结果，验证DNN在UDM中是否签约 |
| Phase 2 | PCF返回Policy拒绝 | 用户未签约该DNN、超出最大PDU Session数 | 检查PCF Policy配置和UDM订阅数据 |
| Phase 3 | N4 Session建立失败 | UPF资源不足、PFCP关联未建立 | 检查SMF-UPF间PFCP heartbeat，验证UPF容量 |
| Phase 4 | gNB返回N2 Setup Failure | 无可用DRB资源、QoS Profile不兼容 | 检查gNB日志中DRB Admission Control结果 |
| Phase 5 | 数据不通但信令成功 | N3隧道配置错误、FAR未正确更新 | 抓包验证N3 GTP-U，检查UPF FAR中AN TEID是否正确 |
## 七、Rel-18增强特性

3GPP Release 18对PDU Session Establishment引入了以下关键增强（TS 23.502 V18.x.x）：

1. **卫星接入增强**：PDU Session Establishment支持NTN（Non-Terrestrial Network）场景下的高延迟N4链路适配，SMF可配置更长的PFCP定时器
2. **边缘计算集成**：通过Application Detection（ADC）规则，UPF在PDU Session建立时即可配置流量检测和本地分流规则，支持UL CL（Uplink Classifier）和Branching Point的提前部署
3. **Enhanced UPF冗余**：支持Stateful PFCP Replication，主备UPF间同步N4 Session状态，PDU Session切换时无需重新建立
4. **Alternative QoS Profile**：PCF可在PCC Rule中下发多个备选QoS Profile（TS 23.501 Section 5.7.1.2a），SMF和gNB可在运行时动态切换，无需触发PDU Session Modification
5. **Red Cap UE优化**：针对Reduced Capability UE，简化PDU Session建立过程中的部分QoS参数协商，降低信令开销

---

## 常见问题

**Q1: PDU Session和EPS Bearer有什么本质区别？**
A: 核心区别在于**QoS粒度**。4G EPS中一个PDN Connection包含Default Bearer + Dedicated Bearer，Bearer是QoS最小单位；5G中一个PDU Session包含多个QoS Flow，QoS Flow不等于Bearer——gNB可以将多个QoS Flow复用到一个DRB上。此外，5G的QoS Rule在UE侧执行包分类，而4G的TFT只在UE和PGW两端使用。

**Q2: Default QoS Rule为什么可以没有Packet Filter？**
A: 这是TS 23.501 Section 5.7.1.4的刻意设计。Default QoS Rule是唯一允许不包含Packet Filter的规则，它作为"兜底规则"（catch-all），将所有未被Dedicated QoS Rule匹配的上行流量映射到Default QoS Flow。这保证了UE在任何情况下都有可用的QoS Flow发送数据。

**Q3: 如果PCF不可用，PDU Session还能建立吗？**
A: 可以。根据TS 23.502 Section 4.3.2.2.1，SMF在PCF不可用时可使用本地策略（Local Policy）来推导QoS参数。这种降级机制保证了即使PCF故障，基本的PDU Session仍可建立，但无法提供动态PCC和计费功能。

**Q4: 为什么需要N4 Session Modification阶段？不能在N4 Session Establishment时就把AN Tunnel Info给UPF吗？**
A: 因为**时序约束**。N4 Session Establishment发生在SMF获得UPF N3 TEID之后、gNB建立DRB之前。此时gNB的AN Tunnel Endpoint还未分配。SMF必须先拿到UPF的N3 TEID，通过N2消息交给gNB，等gNB建立DRB后返回AN Tunnel Info，再用N4 Modification更新UPF的FAR。这是一个典型的**两端隧道信息异步交换**问题。

**Q5: 二次认证（Secondary Authentication）什么时候触发？**
A: 根据TS 23.502 Section 4.3.2.2.1 Step 9a，当UDM订阅数据指示该DNN需要Secondary Authentication时，SMF会在UDM获取数据后、N4会话建立前，向DN-AAA服务器发起EAP-based认证。这在企业专线、校园网等场景常见，UPF本身不参与认证过程。

---

## 参考来源

1. [3GPP TS 23.502 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — Section 4.3.2.2.1 UE-requested PDU Session Establishment
2. [3GPP TS 23.501 V18.x.x](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.7 QoS Model, Section 6.3.2 SMF Selection, Section 6.3.3 UPF Selection
3. [3GPP TS 29.244 V18.x.x](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5 N4/PFCP Session Establishment Procedures
4. [5G PDU Session Establishment and Wireshark trace - Derek Cheung (Medium)](https://derekcheung.medium.com/5g-core-part-2-pdu-session-establishment-and-call-flow-3a1e65cc8015) — 实战抓包分析
5. [ShareTechnote - 5G PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — 流程图与参数解读

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
MF session management
3. [3GPP TS 24.501 V18.7.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 8.3.6/8.3.7: NAS SM PDU Session Establishment messages
4. [3GPP TS 29.502 V18.6.0](https://www.3gpp.org/DynaReport/29502.htm) — Section 5.1: Nsmf_PDUSession Service API
5. [ShareTechnote 5G PDU Session](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — PDU Session Establishment signaling walkthrough

---
> 本文由「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)