在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建立过程，并给出抓包识别方法和故障排查决策树。
下图基于TS 23.502 Figure 4.3.2.2.1-1，展示了UE发起PDU会话建立的完整13步信令流程：
图表 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侧隧道信息，数据通路激活 |
该消息嵌套在 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）而不会混淆。
图表 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地址分配方式指示等） |
SMF在Phase 3向UPF发送的PFCP Session Establishment Request（TS 29.244 Section 7.5.2.2）中，一次性下发该PDU会话所需的全部规则：
图表 3
每个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封装）
| 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资源建立前就准备好转发规则框架。
| 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保障。
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会话释放而删除 | 可独立释放 |
图表 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的映射规则
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"）。
| 接口 | 过滤器 | 说明 |
|---|---|---|
| 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操作 |
| 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切片可用性 |
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池、会话容量）
从SMF的PDU会话状态机角度（TS 24.501 Section 6.1.3.2.1），PDU会话建立过程中的状态迁移：
图表 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资源完全清理
一次完整的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建立 | 降低用户面首包延迟 |
每个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池管理是关键瓶颈。
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认证。
本文由「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 等场景全覆盖。
