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

# PDU会话建立信令流全链路拆解：从NAS SM到N4 PFCP规则下发

## 1 引言：为什么PDU会话建立是5GC最核心的信令流程

在5G核心网中，PDU Session Establishment（PDU会话建立）是用户获取数据服务的前提条件。它横跨UE、(R)AN、AMF、SMF、UPF、PCF、UDM六大网元，涉及NAS 5GSM、NGAP、SBI（HTTP/2）、PFCP四类协议栈，完整流程包含13个步骤、5个接口。相较于4G EPS的PDN Connection建立，5G PDU会话引入了**QoS Flow级精细控制**、**S-NSSAI切片感知**、**SSC模式选择**等全新机制，使其复杂度远超4G。

本文基于 **3GPP TS 23.502 V18.3.0 Section 4.3.2.2.1**（UE-requested PDU Session Establishment for non-roaming）、**TS 24.501 Section 6.3.1**（5GSM PDU Session Establishment）、**TS 29.244 Section 7.5.2**（PFCP Session Establishment）进行全链路拆解，覆盖NAS SM消息IE解析、N4 PFCP规则下发机制、QoS Flow建立过程，并给出抓包识别方法和故障排查决策树。

---

## 2 完整信令时序图

下图基于TS 23.502 Figure 4.3.2.2.1-1，展示了UE发起PDU会话建立的完整13步信令流程：


![图表1](images/telecom-3gpp-r3-1705-mermaid-0.png)

> *图表 1*


### 2.1 五阶段分解

整个流程可以分为5个阶段：

| 阶段 | 名称 | 涉及接口 | 核心动作 |
|------|------|----------|----------|
| Phase 1 | NAS请求与SM上下文创建 | Uu/N1/N11 | UE发送NAS SM请求，AMF选择SMF并创建SM上下文 |
| Phase 2 | 策略与订阅数据获取 | N8/N10/N7 | SMF从UDM获取签约数据，从PCF获取PCC规则 |
| Phase 3 | N4会话建立 | N4 | SMF通过PFCP向UPF下发PDR/FAR/QER规则 |
| Phase 4 | RAN资源建立 | N2/Uu | gNB建立DRB，UE获取IP地址和QoS规则 |
| Phase 5 | 隧道完成 | N4/N11 | SMF向UPF更新gNB侧隧道信息，数据通路激活 |

---

## 3 NAS 5GSM消息IE深度解析

### 3.1 PDU Session Establishment Request（TS 24.501 Section 6.3.1.3）

该消息嵌套在 **UL NAS TRANSPORT**（TS 24.501 Section 8.2.8）中发送。UL NAS TRANSPORT的外层IE：

| IE | 类型 | 说明 |
|----|------|------|
| Payload container type | 枚举 | 值为"N1 SM information"(=1) |
| Payload container | 容器 | 承载5GSM PDU Session Establishment Request |
| PDU Session ID | 整数(0-255) | 由UE分配的PDU会话标识 |
| Request type | 枚举 | "initial request"(=1)/"existing PDU session"(=2)/"emergency request"(=4) |
| DNN | 字符串 | 可选，指定目标数据网络（如"internet"） |
| S-NSSAI | 组合(SST+SD) | 可选，指定网络切片 |
| Old PDU Session ID | 整数 | EPS互操作时使用 |

内层5GSM消息的关键IE：

| IE | 编码位置 | 说明 |
|----|----------|------|
| **PTI** (Procedure Transaction Identity) | 必选 | 1字节，标识本次事务(0-254)，用于关联Request和Accept/Reject |
| **PDU Session ID** | 必选 | 与外层UL NAS TRANSPORT中的PDU Session ID相同 |
| **5GSM Capability** | 必选 | 指示UE支持的5GSM特性（如反射QoS、多路径ATSSS等） |
| **PDU Session Type** | 必选 | IPv4(=1)/IPv6(=2)/IPv4v6(=3)/Ethernet(=4)/Unstructured(=5) |
| **SSC Mode** | 可选 | SSC mode 1/2/3，缺省为SSC mode 1 |
| **Integrity Protection Max Data Rate** | 必选 | 上行/下行最大数据率，用于控制面完整性保护 |
| **PCO** (Protocol Configuration Options) | 可选 | 请求DNS地址、IP分配方式等 |

**设计意图**：PTI与PDU Session ID双标识机制——PTI用于短期事务跟踪（请求-响应对），PDU Session ID用于长期会话生命周期管理。这种分离设计允许同一个PDU Session ID上发起多次事务（如后续的PDU Session Modification）而不会混淆。

### 3.2 PDU Session Establishment Accept（TS 24.501 Section 6.3.1.2）


![图表2](images/telecom-3gpp-r3-1705-mermaid-1.png)

> *图表 2*


| IE | 说明 |
|----|------|
| **QoS Rules** | 核心IE，定义UE侧数据包到QoS Flow的映射规则。默认QoS Rule的Packet Filter为通配符（匹配所有流量），关联默认QFI |
| **Session-AMBR** | 授权的上行/下行聚合最大比特率，限制整个PDU会话的总速率 |
| **PDU Address** | SMF分配的IP地址（IPv4地址/IPv6前缀），由UPF/DHCP/AAA服务器提供 |
| **QoS Flow Descriptions** | 每个QFI对应的QoS参数（5QI、GBR/MBR），用于UE正确标记上行数据的QFI |
| **PCO** | 网络侧返回的配置参数（DNS服务器地址、MTU、IP地址分配方式指示等） |

---

## 4 N4 PFCP规则下发机制深度拆解（TS 29.244）

### 4.1 PFCP Session Establishment Request中的规则体系

SMF在Phase 3向UPF发送的PFCP Session Establishment Request（TS 29.244 Section 7.5.2.2）中，一次性下发该PDU会话所需的全部规则：


![图表3](images/telecom-3gpp-r3-1705-mermaid-2.png)

> *图表 3*


### 4.2 PDR（Packet Detection Rule）IE结构

每个Create PDR IE包含以下关键字段（TS 29.244 Section 7.5.2.2）：

| IE | 长度 | 说明 |
|----|------|------|
| **PDR ID** | 2字节 | 规则唯一标识，SMF分配 |
| **Precedence** | 4字节 | 优先级，数值越小优先级越高。默认PDR通常设为较高值（低优先级） |
| **PDI (Packet Detection Information)** | 复合 | 核心匹配条件容器 |
| → Source Interface | 枚举 | ACCESS(=0, 上行)/CORE(=1, 下行) |
| → F-TEID | 复合 | GTP-U隧道端点标识（UPF分配，在Response中返回） |
| → UE IP Address | 16/32字节 | 分配给UE的IP地址 |
| → SDF Filter | 变长 | 业务数据流过滤器（5元组），可选 |
| → QFI | 1字节 | QoS Flow Identifier |
| **Outer Header Removal** | 枚举 | 是否去除GTP-U/UDP/IP外层头 |
| **Associated FAR ID** | 4字节 | 关联的转发规则ID |
| **Associated QER ID** | 4字节 | 关联的QoS执行规则ID |
| **Associated URR ID** | 4字节 | 关联的使用量上报规则ID |

**上行PDR示例**：
- Source Interface = ACCESS
- F-TEID = UPF侧N3隧道TEID（UPF在Response中分配）
- UE IP Address = 10.1.1.100
- QFI = 1（默认QoS Flow）
- Outer Header Removal = GTP-U/UDP/IP（去除外层隧道头后转发到DN）

**下行PDR示例**：
- Source Interface = CORE
- UE IP Address = 10.1.1.100（目的IP匹配）
- QFI = 1
- 无Outer Header Removal（需要加GTP-U封装）

### 4.3 FAR（Forwarding Action Rule）IE结构

| IE | 说明 |
|----|------|
| **FAR ID** | 规则唯一标识 |
| **Apply Action** | FORWARD(=1)/DROP(=2)/BUFFER(=3)/NOTIFY(=4)，可组合 |
| **Forwarding Parameters** | 仅当Apply Action包含FORWARD时存在 |
| → Destination Interface | ACCESS(=0, 朝向UE)/CORE(=1, 朝向DN)/SGi-LAN |
| → Network Instance | DNN对应的网络实例 |
| → Outer Header Creation | GTP-U封装参数：TEID + IP地址 |
| → Transport Level Marking | DSCP标记 |

**关键设计**：在Phase 3的初始N4 Session Establishment中，下行FAR（FAR #2）的Outer Header Creation中**不包含gNB的F-TEID**——因为此时gNB尚未分配N3隧道端点。SMF在Phase 5收到gNB的F-TEID后，通过 **PFCP Session Modification** 更新下行FAR，补全隧道信息。这种两阶段设计使得UPF可以在RAN资源建立前就准备好转发规则框架。

### 4.4 QER（QoS Enforcement Rule）IE结构

| IE | 说明 |
|----|------|
| **QER ID** | 规则唯一标识 |
| **QFI** | 关联的QoS Flow Identifier |
| **Gate Status** | OPEN(=0)/CLOSED(=1)，控制是否允许数据通过 |
| **UL/DL Maximum Bitrate** | 上行/下行最大比特率（MBR） |
| **UL/DL Guaranteed Bitrate** | 上行/下行保障比特率（GBR，仅GBR QoS Flow） |
| **Packet Rate** | 上行/下行包速率限制 |

对于默认QoS Flow（通常5QI=9, Non-GBR），QER主要执行 **Session-AMBR** 级别的速率限制。对于专用QoS Flow（如5QI=1的VoNR），QER执行GBR/MBR级别的严格QoS保障。

---

## 5 QoS Flow建立机制

### 5.1 默认QoS Flow与专用QoS Flow

PDU会话建立时至少创建一个**默认QoS Flow**。默认QoS Flow的特征：

| 属性 | 默认QoS Flow | 专用QoS Flow |
|------|-------------|-------------|
| 建立时机 | PDU会话建立时自动创建 | 通过PDU Session Modification添加 |
| 5QI | 通常为9（Non-GBR） | 按业务需求（如1/2/3/4/67/71等） |
| Packet Filter | 通配符（匹配所有未匹配的流量） | 精确5元组过滤器 |
| ARP | 继承PCF授权的默认ARP | 按PCC规则指定 |
| GBR | 不适用 | GBR/MBR由PCF授权 |
| 释放 | 随PDU会话释放而删除 | 可独立释放 |

### 5.2 QoS Flow参数传递链


![图表4](images/telecom-3gpp-r3-1705-mermaid-3.png)

> *图表 4*


QoS参数的完整传递路径：
1. **UDM → SMF**：签约数据中的默认5QI/ARP和Session-AMBR
2. **PCF → SMF**：策略授权的PCC Rules（含动态QoS参数、业务过滤器、门控状态）
3. **SMF → UPF**：通过N4 Create QER下发QoS执行规则（速率限制、QFI映射）
4. **SMF → gNB**：通过N2 QoS Profile下发无线侧QoS参数（5QI、ARP、GBR/MBR）
5. **SMF → UE**：通过N1 QoS Rules下发上行数据包到QFI的映射规则

---

## 6 SSC模式选择机制（TS 23.501 Section 5.6.3）

PDU会话的SSC（Session and Service Continuity）模式决定了移动场景下的会话行为：

| SSC Mode | 锚点行为 | IP地址 | 触发者 | 典型场景 |
|----------|----------|--------|--------|----------|
| **SSC Mode 1** | UPF锚点不变，无论UE移动到哪里 | IP地址保持不变 | N/A | IMS语音、VPN隧道 |
| **SSC Mode 2** | 网络判定需要更换锚点时，先释放旧会话再建新会话 | IP地址改变 | 网络 | 物联网低移动性终端 |
| **SSC Mode 3** | 网络判定需要更换锚点时，先建新会话再释放旧会话 | 新旧IP暂时并存 | 网络+UE | 大流量视频、无缝切换 |

SSC Mode的选择由 **SMF** 根据UDM签约数据和PCF策略决定，UE在Request中只能表达"期望"的SSC Mode。若UE请求的SSC Mode与签约不一致，SMF在Accept中返回授权的SSC Mode，或直接Reject（Cause #31 "Request rejected, SSC mode not available"）。

---

## 7 实战连接：抓包识别与故障排查

### 7.1 关键接口Wireshark过滤条件

| 接口 | 过滤器 | 说明 |
|------|--------|------|
| **N1 (NAS SM)** | `nas-5gs.sm.message_type == 0xc1` | PDU Session Establishment Request |
| **N1 (NAS SM)** | `nas-5gs.sm.message_type == 0xc2` | PDU Session Establishment Accept |
| **N1 (NAS SM)** | `nas-5gs.sm.message_type == 0xc3` | PDU Session Establishment Reject |
| **N2 (NGAP)** | `ngap.procedureCode == 58` | PDU Session Resource Setup |
| **N4 (PFCP)** | `pfcp.message_type == 50` | PFCP Session Establishment Request |
| **N4 (PFCP)** | `pfcp.message_type == 51` | PFCP Session Establishment Response |
| **N11 (SBI)** | `http2.headers.value contains "nsmf-pdusession"` | AMF↔SMF PDU Session操作 |

### 7.2 常见5GSM Reject Cause（TS 24.501 Section 9.5.7）

| Cause值 | 名称 | 典型原因 | 排查方向 |
|---------|------|----------|----------|
| **#27** | Missing or unknown DNN | UE请求的DNN未配置或不被签约允许 | 检查UE配置和UDM签约数据 |
| **#28** | Unknown PDU Session Type | 请求的PDU类型（如Ethernet）不被网络支持 | 检查SMF/UPF能力集 |
| **#31** | SSC mode not available | 请求的SSC Mode不被签约数据允许 | 检查UDM中SSC Mode签约 |
| **#33** | Missing or unknown DNN in a slice | S-NSSAI+DNN组合在切片中不可用 | 检查NSSF切片配置和SMF切片-DNN映射 |
| **#38** | Network failure | SMF/UPF内部故障 | 检查SMF/UPF日志、N4连接状态 |
| **#62** | No resources available for slicing | 切片资源不足 | 检查UPF容量、RAN切片配额 |
| **#73** | S-NSSAI not available | 请求的切片不可用或未签约 | 检查AMF/NSSF切片可用性 |

### 7.3 故障排查决策树

```
PDU Session Establishment Failure
│
├─ NAS层收到Reject?
│  ├─ Cause #27 → 检查UE DNN配置 + UDM签约DNN列表
│  ├─ Cause #33 → 检查S-NSSAI+DNN在NSSF/SMF中的映射
│  ├─ Cause #73 → 检查AMF允许的S-NSSAI列表 vs UE请求
│  └─ Cause #38 → 检查SMF/UPF运行状态、N4连接
│
├─ NAS层无Reject但无Accept?（超时）
│  ├─ 检查AMF→SMF SBI调用(N11)是否到达SMF
│  ├─ 检查SMF→UDM(N10)订阅数据查询是否超时
│  └─ 检查SMF→PCF(N7)策略请求是否被PCF阻塞
│
├─ NGAP失败?
│  ├─ gNB返回PDUSessionResourceSetupUnsuccessfulTransfer
│  ├─ 检查gNB资源（PRB/DRB可用性）
│  └─ 检查gNB与UPF之间N3隧道可达性
│
└─ PFCP失败?
   ├─ UPF返回Cause != Success
   ├─ 检查PFCP Association是否已建立
   └─ 检查UPF资源（F-TEID池、会话容量）
```
## 8 状态转换视角

从SMF的PDU会话状态机角度（TS 24.501 Section 6.1.3.2.1），PDU会话建立过程中的状态迁移：


![图表5](images/telecom-3gpp-r3-1705-mermaid-4.png)

> *图表 5*


SMF侧的状态管理关键点：
- **INACTIVE → ACTIVE**：只有当Phase 5（N4 Modification完成AN Tunnel Info更新）成功后才迁移到ACTIVE状态
- 若RAN资源建立失败但N4会话已创建，SMF需要发起N4 Session Deletion释放UPF资源
- **PDU Session ID复用**：PDU会话释放后，PDU Session ID可被UE复用，但SMF需确保前一会话的N4资源完全清理

---

## 9 成本与工程实践考量

### 9.1 信令开销分析

一次完整的PDU会话建立涉及约**13-15条信令消息**，横跨5个接口。在大规模IoT场景下（如NB-IoT RedCap终端批量上线），PDU会话建立的信令风暴风险显著。优化策略包括：

| 策略 | 机制 | 效果 |
|------|------|------|
| Always-on PDU Session | UE在Request中指示"Always-on PDU Session Requested" | SMF可在Registration后自动建立，减少后续建立延迟 |
| Edge Relay/5G LAN | 使用Group-level PDU Session | 多个UE共享N4会话，减少SMF/UPF负载 |
| PDU Session预建立 | AMF在Registration Accept后立即触发PDU Session建立 | 降低用户面首包延迟 |

### 9.2 N4 Session资源消耗

每个PDU会话在UPF上至少占用：
- 2个PDR（上行+下行）
- 2个FAR
- 1个QER（默认QoS Flow）
- 1个F-TEID（N3隧道端点）

对于支持专用QoS Flow的会话（如VoNR），额外需要1组PDR/FAR/QER per dedicated QoS Flow。在百万级并发场景下，UPF的PFCP Session容量和F-TEID池管理是关键瓶颈。

---

## 10 常见问题

**Q1: PDU Session Establishment和Registration的关系是什么？**

A: Registration是PDU Session Establishment的前置条件。UE必须先完成Registration（CM-CONNECTED状态），AMF才能转发PDU Session Establishment Request到SMF。但二者是独立的NAS过程——5GMM（Registration）和5GSM（PDU Session）通过N1 NAS信号复用，但PTI和PDU Session ID空间相互独立。

**Q2: N4 Session Establishment中为什么下行FAR的gNB TEID要分两步下发？**

A: 因为SMF向UPF发送N4 Session Establishment（Phase 3）时，gNB尚未分配N3隧道的F-TEID——gNB的F-TEID在Phase 4的N2 PDU Session Resource Setup Response中才返回给SMF。这种"先建框架、后补隧道"的设计确保了UPF可以提前准备规则，避免等gNB分配完成后才开始N4交互，从而降低总体建立时延。

**Q3: 一个PDU会话可以建立多少个QoS Flow？**

A: TS 23.501规定一个PDU会话最多支持**64个QoS Flow**（QFI范围0-63，其中QFI=0保留）。实际部署中，大多数PDU会话只有1个默认QoS Flow（5QI=9），专用QoS Flow在业务需要时通过PDU Session Modification动态添加。

**Q4: free5GC和Open5GS在PDU会话建立实现上有何关键差异？**

A: free5GC（Go语言）的SMF在PFCP Session Establishment中一次性构建所有PDR/FAR/QER规则，UPF通过Go channel接收规则并安装到数据面；Open5GS（C语言）使用PFCP状态机（`SMF_PFCP_STATE_CREATE`），支持更灵活的分阶段规则下发。两者的核心差异在于F-TEID分配策略——free5GC默认UPF分配，Open5GS可配置SMF或UPF分配。

**Q5: 如何区分PDU Session Establishment的"initial request"和"existing PDU session"？**

A: Request Type IE区分：**"initial request"**（值=1）表示新建PDU会话，UE分配新的PDU Session ID；**"existing PDU session"**（值=2）表示在已有PDU Session上恢复（如EPS to 5GS切换后恢复4G PDN Connection映射的PDU会话）。此外还有 **"emergency request"**（值=4）用于紧急会话建立，不要求SIM认证。

---

## 参考来源

1. [3GPP TS 23.502 V18.3.0](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.3.2.2.1: UE-requested PDU Session Establishment for non-roaming
2. [3GPP TS 24.501 V18.4.0](https://www.3gpp.org/DynaReport/24501.htm) — Section 6.3.1: 5GSM PDU Session Establishment procedures, Section 9.5.7: 5GSM cause codes
3. [3GPP TS 29.244 V18.3.0](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5.2: PFCP Session Establishment, PDR/FAR/QER IE definitions
4. [ShareTechnote — PDU Session Establishment](https://www.sharetechnote.com/html/5G/5G_PDUSessionEstablishment.html) — 信令流程图解与消息解析
5. [free5GC SMF PFCP Design](https://free5gc.org/doc/Smf/design/) — 开源5GC中PFCP会话管理的工程实现
6. [3glteinfo — PDU Session Establishment Failure Troubleshooting](https://www.3glteinfo.com/troubleshooting/5g/pdu-session-and-connectivity-failures/pdu-session-establishment-failure/) — 故障排查步骤与Cause分析
7. [Medium — 5G Core PDU Session Establishment and Wireshark trace](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)