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

# 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建立流程在以下四种场景触发：

| 场景 | 说明 | Request Type |
|------|------|-------------|
| 新建PDU Session | UE首次请求数据连接 | "initial request" |
| EPS到5GS切换 | 无N26接口的4G→5G互操作 | "initial request" |
| 接入类型切换 | 3GPP与非3GPP接入之间切换 | "existing PDU session" |
| 紧急服务 | 紧急呼叫触发 | "emergency request" |

## 二、完整信令时序图

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

```mermaid
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）：

| IEI | Information Element | 必选/可选 | 长度 | 说明 |
|-----|---------------------|----------|------|------|
| - | Extended protocol discriminator | M | 1 | 值为0x2E（5GS Session Management） |
| - | PDU Session ID | M | 1 | UE分配的会话标识（0-255），0预留给紧急服务 |
| - | PTI (Procedure Transaction Identity) | M | 1 | 事务标识，用于匹配Request/Accept |
| - | Message identity | M | 1 | 值为0xC1（PDU SESSION ESTABLISHMENT REQUEST） |
| - | Integrity protection maximum data rate | M | 2 | UE支持的用户面完整性保护最大速率（UL/DL） |
| 9- | PDU session type | O | 1 | IPv4/IPv6/IPv4v6/Ethernet/Unstructured |
| A- | SSC mode | O | 1 | SSC Mode 1/2/3，默认为订阅的SSC Mode |
| 28 | 5GSM capability | O | 3-15 | UE的SM能力（如反射QoS、多ARP支持等） |
| 55 | Maximum number of supported packet filters | O | 3 | UE支持的包过滤器最大数量 |
| B- | Always-on PDU session requested | O | 1 | 请求建立always-on PDU Session |
| 39 | SM PDU DN request container | O | 3-255 | 包含DN特定认证信息（如EAP消息） |
| 7B | Extended protocol configuration options | O | 4-65538 | ePCO，含DNS请求、P-CSCF地址请求等 |
| 66 | IP header compression configuration | O | 5-257 | ROHC参数 |
| 74 | Port management information container | O | 8-65538 | TSN/工业物联网端口管理 |
| 34 | PDU session pair ID | O | 3 | 冗余PDU Session对的标识 |
| 35 | RSN (Redundant Session Number) | O | 3 | 冗余会话编号 |
| 36 | URSP rule enforcement reports | O | 4-n | URSP规则执行报告 |

**设计意图**：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。

```mermaid
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
```

**关键参数说明**：

| 参数 | 来源 | 说明 |
|------|------|------|
| SUPI | AMF从注册流程获取 | 用户永久标识，SMF用于查询UDM |
| DNN | UE请求或默认 | 等同4G的APN，标识目标数据网络 |
| S-NSSAI | AMF确定 | 切片选择结果，决定UPF和SM策略 |
| N1 SM Container | Step 1的NAS消息 | 透传PDU Session Establishment Request |
| Access Type | AMF确定 | "3GPP access" 或 "non-3GPP access" |
| Request Type | UE请求 | "initial request" / "existing PDU session" / "emergency request" |
| satelliteBackhaulCat | AMF确定 | R18新增，卫星回传类别 |

**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订阅数据，包括：

| 订阅数据项 | 说明 |
|-----------|------|
| Allowed PDU Session Type(s) | 允许的会话类型列表 |
| Allowed SSC mode(s) | 允许的SSC模式 |
| Default 5QI and ARP | 默认QoS参数 |
| Subscribed Session-AMBR | 订阅的聚合最大比特率 |
| Allowed DNN list | 允许的DNN列表 |
| Allowed S-NSSAI list | 允许的切片列表 |

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的关键信息：

| 参数 | 说明 |
|------|------|
| SUPI | 用户标识 |
| DNN | 数据网络名称 |
| S-NSSAI | 切片标识 |
| UE Location | 用户位置（TAI） |
| Subscription data | 从UDM获取的订阅信息 |
| Requested PDU Session Type | UE请求的会话类型 |
| RAT Type | 接入技术类型 |

PCF返回的**PCC Rules**包含：

| PCC Rule要素 | 说明 |
|-------------|------|
| Rule ID | PCC规则标识 |
| QoS Flow Identifier | 对应的QFI（可由SMF决定） |
| Gate Status | open/close，控制流量通过 |
| QoS Parameters | 5QI, ARP, GFBR, MFBR等 |
| Charging Rules | 计费规则（在线/离线） |
| Traffic Filter | 业务流模板（SDF Filter） |
| Precedence | 优先级，用于冲突解决 |

#### 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）。

```mermaid
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四大规则体系**：

| 规则类型 | 缩写 | 功能 | 方向 |
|---------|------|------|------|
| **Packet Detection Rule** | PDR | 定义如何检测和匹配数据包（SDF Filter, UE IP, QFI等） | SMF→UPF |
| **Forwarding Action Rule** | FAR | 定义匹配包的转发行为（转发/丢弃/缓存） | SMF→UPF |
| **QoS Enforcement Rule** | QER | 执行QoS限速和标记（Gate Status, MBR, QFI） | SMF→UPF |
| **Usage Reporting Rule** | URR | 定义使用量报告的触发和内容 | SMF→UPF |

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），这是一个"双信封"消息：

| 信封 | 内容 | 目标 |
|------|------|------|
| **N1 SM Container** | PDU SESSION ESTABLISHMENT ACCEPT | 转发给UE |
| **N2 SM Information** | PDU Session Resource Setup Request Transfer | 转发给(R)AN |

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

| IE | 说明 |
|----|------|
| PDU Session ID | 会话标识 |
| QFI(s) | QoS Flow标识列表 |
| QoS Profile(s) | 每个QFI对应的QoS参数（5QI, ARP, GFBR, MFBR） |
| CN Tunnel Info | UPF侧的N3隧道信息（IP + TEID） |
| S-NSSAI | 切片标识 |
| Session-AMBR | 会话聚合最大比特率 |
| PDU Session Type | IPv4/IPv6/Ethernet等 |
| User Plane Security Enforcement | 用户面安全策略（完整性保护/加密） |

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

| IEI | Information Element | 必选/可选 | 说明 |
|-----|---------------------|----------|------|
| - | Selected PDU session type | M | 网络最终选择的会话类型 |
| - | Selected SSC mode | M | 网络最终选择的SSC模式 |
| - | Authorized QoS rules | M | **核心IE**，UE用于上行流量分类 |
| - | Session AMBR | M | 会话级速率限制（UL/DL） |
| 29 | PDU address | O | 分配给UE的IP地址/前缀 |
| 22 | S-NSSAI | O | 确认使用的切片 |
| 79 | Authorized QoS flow descriptions | O | QoS Flow级别的QoS参数 |
| 7B | Extended protocol configuration options | O | DNS服务器地址、P-CSCF地址等 |
| 25 | DNN | O | 确认使用的DNN |
| 56 | RQ timer value | O | 反射QoS定时器 |
| 77 | ATSSS container | O | MA PDU Session的ATSSS规则 |

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

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

```mermaid
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模型的几个关键操作同步完成：

```mermaid
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）：

| 要素 | 提供给 | 说明 |
|------|--------|------|
| **QoS Profile** | (R)AN（通过N2） | 包含5QI、ARP、GFBR、MFBR，控制无线侧QoS处理 |
| **QoS Rules** | UE（通过N1） | 包含Packet Filter Set和QFI，控制UE上行分类 |
| **PDR/FAR/QER** | UPF（通过N4） | 包含检测规则、转发规则、QoS执行规则 |

**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 | UPF选择策略 | 会话连续性 | IP地址保持 |
|----------|-----------|-----------|-----------|
| **SSC Mode 1** | 锚定同一UPF，UE移动时不变 | 永远连续 | 始终保持 |
| **SSC Mode 2** | 网络触发释放旧PDU Session，建立新会话 | 临时中断 | 不保持 |
| **SSC Mode 3** | UE触发先建新会话后释放旧会话 | 短暂重叠 | 不保持 |

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

## 六、NAS消息结构对比

### REQUEST vs ACCEPT消息结构

```mermaid
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 抓包关键检查点

| 检查点 | 协议层 | 过滤条件 | 正常值 |
|--------|--------|---------|--------|
| NAS PDU Session Establishment Request | NAS-5GS | `nas-5gs.message_type == 0xc1` | 包含PDU Session ID和DNN |
| Nsmf_PDUSession_CreateSMContext | HTTP/2 | `http2.uri contains "sm-contexts"` | 201 Created |
| N4 Session Establishment | PFCP | `pfcp.message_type == 50` | Cause = Success |
| NGAP PDU Session Resource Setup | NGAP | `ngap.procedureCode == 37` | 包含AN Tunnel Info |
| NAS PDU Session Establishment Accept | NAS-5GS | `nas-5gs.message_type == 0xc2` | 包含QoS Rules和PDU Address |
| N4 Session Modification | PFCP | `pfcp.message_type == 52` | Cause = Success |

### 7.2 常见故障点与排错

| 故障现象 | 可能原因 | 排错思路 |
|---------|---------|---------|
| PDU Session Reject #27 (Missing DNN) | UE请求的DNN不在订阅数据中 | 检查UDM中UE的Allowed DNN列表 |
| PDU Session Reject #28 (Unknown type) | 请求的会话类型不支持 | 检查UE能力与网络配置的匹配性 |
| SM Context创建成功但N4失败 | UPF不可达或资源不足 | 检查SMF-UPF连通性和UPF负载 |
| NGAP Response中QFI被拒绝 | gNB无线资源不足 | 检查gNB负载和QoS参数合理性 |
| N4建立成功但无数据传输 | N3隧道问题 | 检查gNB-UPF连通性和TEID正确性 |
| 获得IP地址但无法上网 | UPF N6接口或路由问题 | 检查UPF到DN的连通性 |
## 八、PDU Session状态转换图

```mermaid
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](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.3.2.2.1: UE-requested PDU Session Establishment (Non-roaming and LBO)
2. [3GPP TS 24.501 V18.10.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 8.3.1/8.3.2: NAS PDU Session Establishment Request/Accept消息定义
3. [3GPP TS 29.244 V18.9.0](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5.2/7.5.3: PFCP Session Establishment Request/Response
4. [3GPP TS 29.502 V18.10.0](https://www.3gpp.org/DynaReport/29502.htm) — Section 5.2.2.2: Nsmf_PDUSession_CreateSMContext服务操作
5. [3GPP TS 38.413 V18.5.0](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.2.1: PDU Session Resource Setup NGAP过程
6. [3GPP TS 23.501 V18.9.0](https://www.3gpp.org/DynaReport/23501.htm) — Section 5.7.1: QoS Flow模型与QFI定义
7. [ShareTechnote - 5G PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — 流程图解与步骤说明
8. [free5GC - PFCP Session Lifecycle](https://free5gc.org/blog/20260204/20260204/) — 开源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 等场景全覆盖。

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