<!-- title: 5G PDU会话建立N1/N4信令全链拆解 -->
<!-- domain: core-network -->

# 5G PDU会话建立N1/N2/N4信令全链拆解

## 一、机制概述与协议定位

PDU Session Establishment（PDU会话建立）是5G核心网中**最关键、最复杂的会话管理信令流程**。它横跨N1（NAS）、N2（NGAP）、N4（PFCP）、N7（SBI）、N10（SBI）五大参考点，涉及UE、(R)AN、AMF、SMF、UPF、PCF、UDM七大网络功能，是UE获取数据连通性的唯一入口。

该流程定义于 **TS 23.502 Section 4.3.2.2.1**（非漫游和LBO场景），Stage 3协议细节分别定义于：
- **TS 24.501** — NAS 5GSM协议（N1接口）
- **TS 38.413** — NGAP协议（N2接口）
- **TS 29.244** — PFCP协议（N4接口）
- **TS 29.502** — Nsmf_PDUSession服务（N11接口）

与4G EPS的PDN Connectivity流程相比，5G引入了SSC模式（Service and Session Continuity）、网络切片S-NSSAI约束、N4 PFCP规则化用户面控制等全新机制，使会话建立的灵活性和控制粒度大幅提升。

```mermaid
graph TB
    subgraph "PDU会话建立涉及的参考点"
        UE["UE"]
        RAN["(R)AN<br/>gNB"]
        AMF["AMF"]
        SMF["SMF"]
        UPF["UPF"]
        PCF["PCF"]
        UDM["UDM"]

        UE -->|"N1 (NAS 5GSM)"| RAN
        RAN -->|"N2 (NGAP)"| AMF
        AMF -->|"N11 (Nsmf_PDUSession)"| SMF
        SMF -->|"N4 (PFCP)"| UPF
        SMF -->|"N7 (Npcf_SMPolicyControl)"| PCF
        SMF -->|"N10 (Nudm_SDM)"| UDM
        AMF -->|"N8 (Nudm_UECM)"| UDM
        RAN -->|"N3 (GTP-U)"| UPF
    end
```

## 二、完整信令时序图

以下基于 **TS 23.502 Section 4.3.2.2.1 Figure 4.3.2.2.1-1**，展示非漫游场景下UE发起的PDU会话建立完整流程：

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

    Note over UE,UPF: Step 1: UE发起NAS消息
    UE->>RAN: NAS Message (N1 SM Container)<br/>PDU Session Establishment Request<br/>[PDU Session ID, DNN, S-NSSAI,<br/>PDU Session Type, SSC Mode, 5GSM Capability]
    RAN->>AMF: N2 Uplink NAS Transport<br/>+ User Location Info + Access Type

    Note over AMF: Step 2: AMF选择SMF
    Note over AMF: 根据S-NSSAI/DNN/UDM订阅信息<br/>执行SMF选择（TS 23.501 §6.3.2）

    Note over AMF,SMF: Step 3: 创建SM上下文
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request<br/>(SUPI, DNN, S-NSSAI, PDU Session ID,<br/>AMF ID, N1 SM Container, UE Location)

    Note over SMF,UDM: Step 4: 获取订阅数据
    SMF->>UDM: Nudm_SDM_Get (SUPI, SM Subscription Data)
    UDM-->>SMF: Allowed PDU Session Types, Allowed SSC modes,<br/>Default 5QI/ARP, Session-AMBR
    SMF->>UDM: Nudm_SDM_Subscribe (变更通知)

    Note over SMF: Step 5: 创建SM Context响应
    SMF-->>AMF: Nsmf_PDUSession_CreateSMContext Response<br/>(SM Context ID, Cause)

    Note over SMF,PCF: Step 7: 策略关联建立
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(PCC规则请求)
    PCF-->>SMF: Default PCC Rules, QoS参数,<br/>Charging规则

    Note over SMF,UPF: Step 8-10: UPF选择与N4会话建立
    Note over SMF: SMF选择SSC模式和UPF<br/>（TS 23.501 §6.3.3）<br/>分配IP地址/前缀
    SMF->>UPF: N4 Session Establishment Request<br/>(PDR, FAR, QER, URR规则)
    UPF-->>SMF: N4 Session Establishment Response<br/>(CN Tunnel Info / F-TEID)

    Note over SMF,AMF: Step 11: N1N2消息传递
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>N2 SM Info: QFI, QoS Profile, CN Tunnel Info<br/>N1 SM Container: PDU Session Establishment Accept<br/>(IP地址, QoS Rules, SSC Mode, Session-AMBR)

    Note over AMF,RAN: Step 12: N2 PDU Session请求
    AMF->>RAN: N2 PDU Session Resource Setup Request<br/>(N2 SM Info + NAS Message)

    Note over RAN,UE: Step 13: RRC重配 + NAS Accept
    RAN->>UE: RRC Reconfiguration<br/>(DRB建立 + NAS PDU Session Establishment Accept)
    UE-->>RAN: RRC Reconfiguration Complete

    Note over RAN,AMF: Step 14: N2响应
    RAN->>AMF: N2 PDU Session Resource Setup Response<br/>(AN Tunnel Info / AN F-TEID)

    Note over AMF,SMF: Step 15: 更新SM上下文
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext Request<br/>(AN Tunnel Info)

    Note over SMF,UPF: Step 16: N4会话修改
    SMF->>UPF: N4 Session Modification Request<br/>(提供AN Tunnel Info + 转发规则)
    UPF-->>SMF: N4 Session Modification Response

    Note over SMF: Step 16c: SMF注册到UDM
    SMF->>UDM: Nudm_UECM_Registration<br/>(SUPI, SMF ID, DNN, S-NSSAI, PDU Session ID)

    Note over SMF,AMF: Step 17: 完成
    SMF-->>AMF: Nsmf_PDUSession_UpdateSMContext Response
```

## 三、关键步骤逐步解析

### 3.1 Step 1：UE发起PDU Session Establishment Request

UE通过 **NAS UL TRANSPORT** 消息承载N1 SM Container（TS 24.501 Section 8.3.1），其中包含 **PDU Session Establishment Request**（TS 24.501 Section 8.3.2）。

**N1 SM Container核心IE解析**：

| IE名称 | 说明 | 必选/可选 | 来源 |
|--------|------|----------|------|
| **PDU Session ID** | UE本地分配的会话标识（0-255） | 必选 | TS 24.501 §9.10.1 |
| **Requested PDU Session Type** | IPv4 / IPv6 / IPv4v6 / Ethernet / Unstructured | 必选 | TS 24.501 §9.10.2 |
| **Requested SSC Mode** | SSC Mode 1/2/3 | 可选 | TS 24.501 §9.10.3 |
| **DNN** | Data Network Name（等同4G APN） | 可选 | TS 24.501 §9.10.4 |
| **S-NSSAI** | 网络切片选择辅助信息 | 可选 | TS 24.501 §9.10.5 |
| **5GSM Capability** | UE会话管理能力 | 必选 | TS 24.501 §9.10.6 |
| **PCO** | Protocol Configuration Options | 可选 | TS 24.501 §9.10.7 |
| **UE Integrity Protection Maximum Data Rate** | UP完整性保护最大速率 | 必选 | TS 24.501 §9.10.8 |
| **Number Of Packet Filters** | 支持的包过滤器数量 | 条件必选 | TS 24.501 §9.10.9 |
| **SM PDU DN Request Container** | DN认证信息 | 可选 | TS 23.502 §4.3.2.2.1 |

**设计意图**：UE在请求中携带的SSC Mode和PDU Session Type是"请求值"，最终由SMF根据订阅数据（Allowed SSC modes、Allowed PDU Session Types）和策略决定最终值。这种"UE请求→网络决定"的模式是5G的典型设计哲学。

### 3.2 Step 2-3：AMF选择SMF并创建SM上下文

AMF在收到PDU Session Establishment Request后执行两个关键操作：

**SMF选择逻辑**（TS 23.502 Section 4.3.2.2.3，TS 23.501 Section 6.3.2）：

```mermaid
flowchart TD
    A[AMF收到PDU Session请求] --> B{Request Type?}
    B -->|Initial Request| C[查询NRF发现SMF<br/>基于S-NSSAI + DNN]
    B -->|Existing PDU Session| D[从UDM获取已注册SMF ID]
    B -->|Emergency Request| E[选择紧急服务专用SMF<br/>TS 23.501 §5.16.4]

    C --> F[Nsmf_PDUSession_CreateSMContext]
    D --> G[Nsmf_PDUSession_UpdateSMContext]
    E --> F

    F --> H[SMF创建SM Context]
    G --> I[SMF更新已有SM Context]
```

AMF通过 **Nsmf_PDUSession_CreateSMContext Request** 调用（TS 29.502 Section 5.1.2.2）向SMF传递完整的会话建立上下文，包括SUPI、DNN、S-NSSAI、UE位置信息、Access Type、RAT Type等关键参数。SM Context ID由SMF分配并返回给AMF，作为后续所有Nsmf_PDUSession服务操作的标识。

### 3.3 Step 4：SMF获取订阅数据

SMF通过 **Nudm_SDM_Get**（TS 29.503 Section 5.3.2）从UDM获取Session Management Subscription Data：

| 订阅数据字段 | 作用 | 影响 |
|-------------|------|------|
| **Allowed PDU Session Types** | 限制可用的会话类型 | SMF验证UE请求的PDU Session Type |
| **Allowed SSC Modes** | 限制可用的SSC模式 | SMF验证UE请求的SSC Mode |
| **Default SSC Mode** | 默认SSC模式 | UE未指定时使用 |
| **Default 5QI and ARP** | 默认QoS参数 | 默认QoS Flow的5QI和ARP |
| **Subscribed Session-AMBR** | 订阅的聚合最大比特率 | 限制PDU Session总带宽 |
| **Static IP Address/Prefix** | 静态IP地址 | 如存在则SSC Mode必须为1 |

**设计意图**：SMF在步骤4获取订阅数据后执行"有效性检查"（TS 23.502 §4.3.2.2.1 Step 4），验证UE请求是否与订阅数据一致。若不一致，SMF可以直接拒绝（返回PDU Session Reject），而非等到后续步骤才发现问题，这是一种"fail-fast"设计。

### 3.4 Step 8：SSC模式选择与UPF选择

这是整个流程中**最核心的决策步骤**，SMF需要同时决定SSC模式和UPF（PDU Session Anchor）。

**SSC模式选择逻辑**（TS 23.501 Section 5.6.9.3）：

```
if UE提供了SSC Mode:
    if 请求的SSC Mode在Allowed SSC Modes中:
        选择UE请求的SSC Mode
    else:
        拒绝并返回允许的SSC Mode列表
else:
    使用Default SSC Mode
    
特殊规则：静态IP地址/前缀 → 必须SSC Mode 1
紧急服务 → 必须SSC Mode 1
```

**UPF选择标准**（TS 23.501 Section 6.3.3）：

| 选择因子 | 优先级 | 说明 |
|----------|--------|------|
| **DNN + S-NSSAI** | 最高 | UPF必须支持请求的DNN和网络切片 |
| **UE位置信息** | 高 | 选择距离UE最近的UPF，减少N3隧道时延 |
| **UPF负载** | 中 | 均衡多个UPF的负载 |
| **UPF能力** | 中 | 是否支持特定功能（如UL CL、Ethernet、TSN） |
| **DNAI** | 条件 | 当需要边缘计算时，按DNAI选择本地UPF |

### 3.5 Step 10：N4 PFCP会话建立——用户面规则的灵魂

N4 Session Establishment（TS 29.244 Section 7.5.2）是SMF向UPF下发**数据面处理规则**的核心步骤。PFCP采用**规则化的包处理模型**，通过五类规则完全定义UPF对数据包的行为：

```mermaid
graph LR
    subgraph "N4 PFCP规则体系 (TS 29.244)"
        PDR["PDR<br/>包检测规则<br/>§7.5.2.2"]
        FAR["FAR<br/>转发动作规则<br/>§7.5.2.3"]
        QER["QER<br/>QoS执行规则<br/>§7.5.2.5"]
        URR["URR<br/>使用量报告规则<br/>§7.5.2.4"]
        BAR["BAR<br/>缓存动作规则<br/>§7.5.2.6"]
    end

    PDR -->|"检测到数据包后"| FAR
    PDR -->|"关联QoS"| QER
    PDR -->|"关联计费"| URR
    FAR -->|"需要缓存时"| BAR

    style PDR fill:#e1f5fe
    style FAR fill:#e8f5e9
    style QER fill:#fff3e0
    style URR fill:#fce4ec
    style BAR fill:#f3e5f5
```

**N4 Session Establishment Request核心IE详解**：

| IE | 方向 | 关键参数 | 作用 |
|----|------|----------|------|
| **Create PDR** | UL/DL | PDI（包检测信息）、Precedence、Outer Header Removal | 定义如何识别属于该PDU Session的数据包 |
| **Create FAR** | UL/DL | Action（Forward/Drop/Buffer/Notify）、Forwarding Parameters | 定义检测到数据包后的处理动作 |
| **Create QER** | UL/DL | Gate Status、MFBR/UFBR、QFI、RQI | 执行QoS速率控制和门控 |
| **Create URR** | UL/DL | Measurement Method、Volume Threshold | 计费和使用量监控 |
| **Create BAR** | DL | Buffering Action、Downlink Data Notification | 缓存控制面下行数据通知 |

**PDR（Packet Detection Rule）** 的包检测信息（PDI）结构：

| PDI子IE | 说明 | 示例 |
|---------|------|------|
| Source Interface | UL/DL/Core | Access / Core / SGi-LAN |
| F-TEID | N3/N9隧道端点标识 | UPF分配的GTP-U TEID |
| Network Instance | DNN | "internet" |
| UE IP Address | 分配给UE的IP | 10.1.2.3 |
| SDF Filter | 业务流过滤器 | permit out ip from any to assigned |
| QFI | QoS Flow Identifier | 5QI=9（默认承载） |

**设计意图**：PFCP的规则化设计使得SMF可以精细控制UPF的每一个数据面行为，而不需要UPF理解业务语义。这种"控制面编排+用户面执行"的分离是5GC用户面架构的核心优势。

### 3.6 Step 11：N1N2 Message Transfer——双通道并行下发

SMF通过 **Namf_Communication_N1N2MessageTransfer**（TS 29.518 Section 5.2.2.3）同时向AMF发送两条信息：

| 通道 | 内容 | 目标 |
|------|------|------|
| **N1 SM Container** | PDU Session Establishment Accept | 转发给UE |
| **N2 SM Information** | QoS Profile, CN Tunnel Info, QFI | 转发给(R)AN |

**PDU Session Establishment Accept核心IE**：

| IE | 说明 | 值域 |
|----|------|------|
| **Selected SSC Mode** | SMF最终选择的SSC模式 | 1/2/3 |
| **Selected PDU Session Type** | 最终PDU Session类型 | IPv4/IPv6/IPv4v6/Ethernet/Unstructured |
| **PDU Address** | 分配的IP地址/前缀 | IPv4地址或IPv6前缀 |
| **QoS Rules** | QoS规则列表（含默认QoS Rule） | 每条Rule含QFI、Packet Filter |
| **Session-AMBR** | PDU Session聚合最大比特率 | UL/DL各一个速率值 |
| **S-NSSAI** | 最终的S-NSSAI | 来自Allowed NSSAI |
| **DNN** | 最终选择的DNN | SMF确定 |
| **Reflective QoS Timer** | 反射QoS定时器 | 可选 |
| **P-CSCF Address** | IMS P-CSCF地址 | 仅IMS场景 |

### 3.7 Step 12-16：RAN资源建立与N3隧道打通

AMF向(R)AN发送 **N2 PDU Session Resource Setup Request**（TS 38.413 Section 8.4.1），(R)AN执行以下操作：

1. **建立DRB**（Data Radio Bearer）—— RRC Reconfiguration
2. **分配AN Tunnel Info**（AN侧N3 GTP-U F-TEID）
3. **返回N2 PDU Session Resource Setup Response**，携带AN Tunnel Info

SMF收到AN Tunnel Info后，通过 **N4 Session Modification** 将其下发给UPF，UPF据此建立完整的 **N3下行隧道**。至此，UE ↔ (R)AN ↔ UPF ↔ DN 的完整数据通路建立。

**N3隧道建立时序**：

```mermaid
sequenceDiagram
    participant SMF
    participant UPF
    participant RAN
    
    Note over SMF,RAN: 阶段1: SMF→UPF获取CN Tunnel Info
    SMF->>UPF: N4 Session Establishment Request<br/>(请求分配UL F-TEID)
    UPF-->>SMF: N4 Session Establishment Response<br/>(CN Tunnel Info = UPF DL F-TEID)
    
    Note over SMF,RAN: 阶段2: SMF→RAN携带CN Tunnel Info
    Note over SMF: CN Tunnel Info通过N2下发给RAN
    
    Note over SMF,RAN: 阶段3: RAN→SMF返回AN Tunnel Info
    Note over RAN: RAN分配AN UL F-TEID
    
    Note over SMF,RAN: 阶段4: SMF→UPF更新AN Tunnel Info
    SMF->>UPF: N4 Session Modification Request<br/>(提供AN Tunnel Info)
    UPF-->>SMF: N4 Session Modification Response
    
    Note over UPF,RAN: N3双向隧道打通！<br/>UL: RAN→UPF (AN F-TEID→UPF F-TEID)<br/>DL: UPF→RAN (UPF F-TEID→AN F-TEID)
```

## 四、SSC三大模式深度对比

### 4.1 三种SSC模式机制对比

SSC（Service and Session Continuity）模式定义于 **TS 23.501 Section 5.6.9**，决定了PDU Session在移动性场景下的连续性行为：

```mermaid
stateDiagram-v2
    [*] --> SSC1: 静态IP/紧急服务/默认
    [*] --> SSC2: 运营商策略触发
    [*] --> SSC3: UE请求+订阅允许
    
    state SSC1 {
        [*] --> PSA_Fixed
        PSA_Fixed: UPF PSA锚点固定不变<br/>IP地址保持不变<br/>移动性由中间UPF/I-SMF处理
    }
    
    state SSC2 {
        [*] --> Session_Release
        Session_Release: 网络触发释放旧PDU Session<br/>UE立即重建新PDU Session
        Session_Release --> New_PSA: 新UPF PSA
        New_PSA: 新IP地址<br/>先断后建(Break-before-Make)
    }
    
    state SSC3 {
        [*] --> Make_Before_Break
        Make_Before_Break: 建新PSA+保持旧PSA<br/>IP地址改变但有过渡期
        Make_Before_Break --> Old_Release: 旧PSA超时释放
        Old_Release: 旧IP地址/前缀释放<br/>仅适用于IP类型
    }
```

| 维度 | SSC Mode 1 | SSC Mode 2 | SSC Mode 3 |
|------|-----------|-----------|-----------|
| **锚点行为** | PSA固定不变 | 释放旧PSA，选新PSA | 先建新PSA，后释放旧PSA |
| **IP地址** | 保持不变 | 释放旧IP，分配新IP | 旧IP保持过渡期后释放 |
| **切换策略** | Make-before-Break | Break-before-Make | Make-before-Break |
| **适用PDU类型** | 所有类型 | 所有类型 | 仅IP类型（IPv4/IPv6/IPv4v6） |
| **UE支持要求** | 必选 | 可选 | 可选 |
| **典型场景** | IMS语音、静态IP、VPN | 背景数据、非连续应用 | 低时延高可靠应用 |
| **定义章节** | TS 23.501 §5.6.9.2.1 | TS 23.501 §5.6.9.2.2 | TS 23.501 §5.6.9.2.3 |
| **移动性处理** | 插入I-SMF/UL CL | 网络触发会话重建 | IPv6多宿主或新建会话 |

### 4.2 SSC模式3的Make-before-Break机制

SSC Mode 3的核心是"**先建后拆**"——在新PSA建立连接后再释放旧PSA，确保UE不会断网。具体实现有两种路径：

**路径A：IPv6多宿主（同一PDU Session内）**
```
1. 网络在现有PDU Session中分配新的IPv6前缀（新PSA）
2. UE同时拥有旧前缀和新前缀
3. 旧前缀通过Router Advertisement的Preferred Lifetime=0标记为deprecated
4. UE平滑迁移到新前缀
5. 旧PSA在计时器超时后释放
```

**路径B：新建PDU Session**
```
1. UE收到SSC Mode 3触发（NAS Session Management消息）
2. UE发起新PDU Session建立（携带Old PDU Session ID）
3. 新PDU Session分配新IP地址
4. 旧PDU Session在NAS指示的超时时间后释放
```

## 五、N4 PFCP规则处理流程

### 5.1 UPF数据包处理管线

UPF收到数据包后的处理逻辑（TS 29.244 Section 5.2）遵循严格的规则匹配管线：

```mermaid
flowchart TD
    A[UPF收到数据包] --> B{入口方向?}
    B -->|N3 UL| C[匹配UL PDR]
    B -->|N6 DL / N9 DL| D[匹配DL PDR]

    C --> E{PDR匹配成功?}
    D --> E

    E -->|Yes| F[提取QFI、应用QER]
    F --> G{QER Gate Status?}

    G -->|Open| H[执行FAR动作]
    G -->|Closed| I[丢弃数据包]

    H --> J{FAR Action?}
    J -->|FORWARD| K[添加Outer Header<br/>N3/N9 GTP-U封装]
    J -->|DROP| L[静默丢弃]
    J -->|BUFFER| M[缓存 + 触发DDN通知]
    J -->|NOTIFY| N[通知SMF]

    K --> O[更新URR使用量计数器]
    O --> P[转发数据包]
```

### 5.2 默认QoS Flow的N4规则示例

以一个典型的IPv4 PDU Session（默认5QI=9，Session-AMBR=100Mbps/50Mbps）为例：

**UL PDR（上行包检测规则）**：
| 参数 | 值 | 说明 |
|------|-----|------|
| PDR ID | 1 | 规则标识 |
| Precedence | 255 | 最低优先级（默认规则） |
| Source Interface | Access | 来自(R)AN方向 |
| F-TEID | UPF分配的TEID | N3上行隧道端点 |
| UE IP Address | 10.1.2.3/32 | 分配给UE的IP |
| Associated FAR ID | 1 | 关联FAR |
| Associated QER ID | 1 | 关联QER |

**DL PDR（下行包检测规则）**：
| 参数 | 值 | 说明 |
|------|-----|------|
| PDR ID | 2 | 规则标识 |
| Precedence | 255 | 最低优先级 |
| Source Interface | Core | 来自DN方向 |
| UE IP Address | 10.1.2.3/32 | 目的IP为UE |
| Associated FAR ID | 2 | 关联FAR |
| Associated QER ID | 2 | 关联QER |

## 六、抓包识别与故障排查

### 6.1 抓包识别要点

在Wireshark中识别PDU Session Establishment流程，需要关注以下协议层和过滤器：

| 接口 | Wireshark过滤器 | 关键识别字段 |
|------|-----------------|-------------|
| **N1 (NAS)** | `nas-5gs.message_type == 0xc1` (Establishment Request)<br/>`nas-5gs.message_type == 0xc2` (Establishment Accept) | PDU Session ID, DNN, SSC Mode |
| **N2 (NGAP)** | `ngap.procedureCode == 37` (PDU Session Resource Setup) | PDU Session ID, QFI, CN Tunnel Info |
| **N4 (PFCP)** | `pfcp.message_type == 50` (Session Est. Request)<br/>`pfcp.message_type == 51` (Session Est. Response) | SEID, F-TEID, Create PDR/FAR/QER |
| **N11 (SBI)** | `http.uri contains "nsmf-pdusession/v1/sm-contexts"` | HTTP POST, SM Context创建 |

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

| 故障阶段 | 症状 | 可能原因 | 排查方法 |
|----------|------|----------|----------|
| **Step 3失败** | AMF返回NAS Reject (Cause 27) | DNN不支持或S-NSSAI不在Allowed NSSAI | 检查UDM订阅数据中的Allowed DNN列表 |
| **Step 4失败** | SMF返回PDU Session Reject | 订阅数据校验失败 | 检查SMF日志中的subscription validation |
| **Step 7失败** | QoS Flow被RAN拒绝 | RAN资源不足或5QI不匹配 | 检查N2 Response中的Rejected QFI列表 |
| **Step 10失败** | N4 Session Establishment超时 | UPF不可达或资源耗尽 | 检查PFCP Heartbeat、UPF负载 |
| **Step 14失败** | AN Tunnel Info为空 | RAN无法建立DRB | 检查RRC Reconfiguration是否成功 |
| **IP地址分配失败** | PDU Session Reject (Cause 29) | IP地址池耗尽 | 检查UPF/SMF的IP地址池配置 |
## 常见问题

**Q1: PDU Session Establishment和PDN Connectivity Procedure（4G）的核心区别是什么？**

A: 主要有三大区别：(1) 5G引入了SSC模式机制，支持三种不同的会话连续性策略（4G只有"锚点不变"一种模式）；(2) 5G使用N4 PFCP规则（PDR/FAR/QER/URR）取代了4G的GTP-C bearer管理，用户面控制更灵活；(3) 5G引入了S-NSSAI（网络切片）约束，PDU Session必须绑定到特定切片。

**Q2: SSC Mode 1如何在UE移动时保持PSA不变？**

A: SSC Mode 1通过引入I-SMF（Intermediate SMF）和中间UPF来解决。当UE移动到远离PSA的区域时，网络在PSA和新RAN之间插入中间UPF（I-UPF），通过N9隧道串联，PSA和IP地址保持不变。代价是增加了数据路径长度和时延。参见TS 23.501 Section 5.34。

**Q3: N4 Session Establishment和N4 Session Modification分别在下发什么规则？**

A: N4 Session Establishment（Step 10）下发**全量初始规则**：UL/DL PDR（含CN Tunnel Info）、UL/DL FAR、UL/DL QER（含QFI和Session-AMBR）、URR。N4 Session Modification（Step 16）仅**增量更新**AN Tunnel Info到DL FAR的Forwarding Parameters中，使UPF知道如何将下行数据转发到(R)AN。

**Q4: 为什么N4需要两次交互（Establishment + Modification）才能完成？**

A: 因为N3隧道的两个端点信息在不同时刻才可获得：(1) Step 10时只有UPF侧的CN Tunnel Info（DL F-TEID），需要先告知RAN；(2) Step 14后RAN才分配AN Tunnel Info（UL F-TEID），需要再告知UPF。这种"先建后半"的设计是典型的分布式隧道建立模式。

**Q5: UE请求的SSC Mode与SMF最终选择的SSC Mode不一致时如何处理？**

A: 根据TS 23.501 Section 5.6.9.3，如果UE请求的SSC Mode不在订阅的Allowed SSC Modes中，SMF在PDU Session Establishment Reject中返回Cause值并携带**允许的SSC Mode列表**，UE可以据此重新发起请求。如果UE未指定SSC Mode，SMF直接使用Default SSC Mode。

## 参考来源

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 PDU Session Establishment
2. [3GPP TS 23.501 V18.10.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/18.10.00_60/ts_123501v181000p.pdf) — Section 5.6.9 SSC Mode, Section 6.3.2 SMF Selection, Section 6.3.3 UPF Selection
3. [3GPP TS 29.244 V18.7.0](https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/18.07.00_60/ts_129244v180700p.pdf) — Section 7.5 PFCP Session Establishment Messages
4. [5G PDU Session Establishment Procedure - 3glteinfo](https://www.3glteinfo.com/call-flows/5g-pdu-session-establishment/) — 完整信令流程图解
5. [5G PDU Session Establishment and Wireshark Trace - Medium](https://derekcheung.medium.com/5g-core-part-2-pdu-session-establishment-and-call-flow-3a1e65cc8015) — 抓包分析实战

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