# 5G PDU会话建立信令流全链拆解：从NAS到N4的16步完整推演 ## 一、机制定位与设计意图 PDU Session Establishment（PDU会话建立）是5G核心网最基础、最高频的会话管理流程，定义于 **TS 23.502 Section 4.3.2**。该流程完成UE到DN（数据网络）之间端到端数据通道的建立，涉及**7个网络功能**（UE、RAN、AMF、SMF、UPF、UDM、PCF）的协同交互，跨越**6个关键接口**（N1/N2/N3/N4/N7/N10）。 **设计意图解析：** - **控制面与用户面分离（CUPS继承）**：SMF负责控制面决策（QoS、计费、路由），UPF仅负责用户面转发，两者通过N4/PFCP接口交互 - **会话管理与移动性管理解耦**：AMF只做NAS消息的透传代理（N11接口），不解析5GSM信令内容，实现网元职责清晰 - **策略驱动**：PCF通过N7接口下发PCC规则，SMF据此生成QoS流和PFCP规则，实现业务差异化处理 - **SMF选择动态化**：AMF通过NRF发现或本地配置选择SMF，支持基于切片、DNN、DNAI的灵活路由 --- ## 二、完整信令时序图（TS 23.502 Figure 4.3.2.2-1） 以下时序图基于 **TS 23.502 Section 4.3.2.2.1** 的UE发起场景（非漫游），展示从UE发出NAS请求到用户面数据通道就绪的完整16步流程： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN participant AMF participant SMF participant UDM participant PCF participant UPF Note over UE,UPF: Phase 1: NAS请求与SMF选择 (Step 1-3) UE->>RAN: 1. UL NAS Transport
PDU Session Establishment Request
(NAS 5GSM Message) RAN->>AMF: 2. N2 UL NAS Transport
(含RAN UE NGAP ID, NAS PDU) AMF->>AMF: 3. SMF Selection
(NRF Discovery / Local Config) Note over UE,UPF: Phase 2: SM Context创建与策略获取 (Step 4-8) AMF->>SMF: 4. Nsmf_PDUSession_CreateSMContext Request
(SUPI, DNN, S-NSSAI, PDU Session ID, AMF ID) SMF->>UDM: 5. Nudm_SDM_Get
(Subscription Data for DNN/S-NSSAI) UDM-->>SMF: 6. Subscription Data
(Default 5QI, Session-AMBR, SSDM) SMF-->>AMF: 7. Nsmf_PDUSession_CreateSMContext Response
(SM Context ID, Cause) SMF->>PCF: 8. Npcf_SMPolicyControl_Create
(SUPI, DNN, S-NSSAI, IPv4/IPv6) Note over UE,UPF: Phase 3: UPF选择与N4会话建立 (Step 9-11) SMF->>SMF: 9. UPF Selection
(NRF / DNAI / Topology) SMF->>UPF: 10. N4 PFCP Session Establishment Request
(Create FAR, Create PDR, Create QER) UPF-->>SMF: 11. N4 PFCP Session Establishment Response
(F-SEID, UPF TEID) Note over UE,UPF: Phase 4: NAS响应与N2资源分配 (Step 12-16) SMF->>AMF: 12. Namf_Communication_N1N2MessageTransfer
(N1 SM Container + N2 SM Info) AMF->>RAN: 13. N2 PDU Session Resource Setup Request
(NAS PDU + N2 SM Info) RAN->>UE: 14. DL NAS Transport
PDU Session Establishment Accept UE-->>RAN: 15. RRC Reconfiguration Complete
(空口资源就绪) RAN-->>AMF: 16. N2 PDU Session Resource Setup Response
(RAN TEID, RAN IP) AMF->>SMF: 17. Nsmf_PDUSession_UpdateSMContext
(RAN N3 Info) SMF->>UPF: 18. N4 PFCP Session Modification
(Update FAR with RAN F-TEID) Note over UE,UPF: ✅ 用户面数据通道 UE → RAN(N3) → UPF(N6) → DN 就绪 ``` --- ## 三、逐步IE参数深度解析 ### Phase 1：NAS请求与SMF选择（Step 1-3） #### Step 1：UL NAS Transport（TS 24.501 Section 8.2.7） UE通过 `UL NAS TRANSPORT` 消息携带 `PDU SESSION ESTABLISHMENT REQUEST`（TS 24.501 Section 8.3.9），核心IE如下： | IE名称 | 来源规范 | 长度 | 说明 | |--------|---------|------|------| | PDU Session ID | TS 24.501 §9.10 | 1字节 | UE分配的会话标识（范围1-255） | | PTI (Procedure Transaction Identity) | TS 24.501 §9.11 | 1字节 | 事务标识，用于匹配请求和响应 | | DNN (Data Network Name) | TS 24.501 §9.11 | 可变 | 等同于4G APN，如"internet" | | S-NSSAI | TS 24.501 §9.11 | 2-8字节 | 切片标识（SST+可选SD） | | PDU Session Type | TS 24.501 §9.11 | 4bit | IPv4/IPv6/IPv4v6/Ethernet/Unstructured | | SSC Mode | TS 24.501 §9.11 | 4bit | SSC模式1/2/3（决定会话连续性） | | 5GSM Capability | TS 24.501 §9.11 | 可变 | UE支持的5GSM能力（如Reflective QoS） | | PCO (Protocol Configuration Options) | TS 24.501 §9.11 | 可变 | DNS地址请求、MTU协商等 | **DNN与S-NSSAI的联合选择逻辑**（TS 23.501 Section 5.15.3）： UE根据URSP（UE Route Selection Policy）规则，将应用流量匹配到特定的DNN+S-NSSAI组合。如果URSP未提供匹配规则，UE使用默认DNN（HPLMN配置或Default DNN）。 #### Step 2-3：AMF的SMF选择（TS 23.502 Section 4.3.2.2.1 Step 3a/3b） AMF收到NAS消息后，执行SMF选择。选择依据的优先级： 1. **已有SM Context**：如果PDU Session ID对应的SM Context存在，直接路由到原SMF 2. **NRF Discovery**：基于S-NSSAI + DNN查询NRF，获取候选SMF列表（TS 29.510 Nnrf_NFDiscovery） 3. **本地配置**：使用AMF上配置的SMF静态路由表 **SMF选择的关键输入参数**（TS 23.501 Section 6.3.2）： | 输入参数 | 来源 | 选择权重 | |---------|------|---------| | S-NSSAI | NAS消息/UDM订阅 | 必须（精确匹配切片） | | DNN | NAS消息/UDM默认DNN | 必须（精确匹配网络名） | | PLMN ID | SUPI/UDM | 漫游场景区分H-SMF/V-SMF | | UE Location (TAI) | AMF | 拓扑就近选择 | | DNAI | UDM/PCF策略 | 边缘计算场景 | --- ### Phase 2：SM Context创建与策略获取（Step 4-8） #### Step 4：CreateSMContext（TS 29.502 Section 5.1.1） AMF通过 `Nsmf_PDUSession_CreateSMContext` 服务操作向SMF发送创建请求： ``` POST /nsmf-pdusession/v1/sm-contexts ``` **请求体关键字段**（TS 29.502 Section 6.1.6.2.4）： | 字段 | 类型 | 说明 | |------|------|------| | supi | Supi | 用户永久标识 | | dnn | Dnn | 数据网络名 | | snssai | Snssai | 切片信息 | | pduSessionId | integer | PDU会话标识 | | servingNfId | NfInstanceId | AMF实例ID | | guami | Guami | AMF的GUAMI | | anType | AccessType | 3GPP/NON-3GPP接入 | | n1SmMsg | RefToBinaryData | NAS PDU（PDU Session Establishment Request） | | smContextStatusUri | Uri | SMF状态通知回调URI | SMF收到后创建SM Context（会话管理上下文），分配全局唯一的 `smContextRef`（SM Context ID），后续所有该会话的操作都通过此ID引用。 #### Step 5-6：UDM订阅数据获取（TS 29.503 Section 5.2.2） SMF调用 `Nudm_SDM_Get` 获取用户的会话管理签约数据： | 签约数据项 | 说明 | 对PDU会话的影响 | |-----------|------|----------------| | Default 5QI | 默认QoS特征标识 | 决定默认QoS Flow的5QI值 | | Default ARP | 默认分配和保持优先级 | 决定默认QoS Flow的抢占优先级 | | Session-AMBR | 会话聚合最大比特率 | 限制该PDU会话所有Non-GBR Flow的总速率 | | Allowed SSC Mode | 允许的SSC模式 | 与UE请求的SSC Mode取交集 | | Allowed PDU Session Type | 允许的会话类型 | 与UE请求的PDU Session Type取交集 | | Allowed DNN | 允许的DNN列表 | 验证请求的DNN是否签约 | **SSC Mode协商逻辑**（TS 23.501 Section 5.6.4）： ```mermaid flowchart TD A[UE请求SSC Mode] --> B{Allowed SSC Mode包含
UE请求的Mode?} B -->|Yes| C[使用UE请求的SSC Mode] B -->|No| D{Allowed SSC Mode
仅包含一个Mode?} D -->|Yes| E[使用该唯一允许的Mode] D -->|No| F[使用Allowed SSC Mode中
最高优先级的Mode] C --> G[SSC Mode确定] E --> G F --> G ``` #### Step 8：PCF策略获取（TS 29.512 Section 4.2.2） SMF通过 `Npcf_SMPolicyControl_Create` 向PCF获取PCC规则： **SMF发送给PCF的关键参数**： - SUPI + DNN + S-NSSAI（会话标识三元组） - IPv4地址/IPv6前缀（如已分配） - UE Location（TAI + Cell ID） - Access Type（3GPP access） - Subscription信息（来自UDM的默认5QI/ARP/Session-AMBR） **PCF返回的PCC规则**（TS 29.512 Section 6.1.6.2.2）： | PCC规则元素 | 说明 | 下游影响 | |------------|------|---------| | 5QI + ARP | QoS参数 | 映射到QoS Flow的QoS参数 | | Session-AMBR | 会话速率限制 | 下发到UPF的QER（QoS Enforcement Rule） | | GBR/MBR | 保证/最大比特率 | 对GBR QoS Flow生效 | | Charging Key | 计费标识 | 用于SMF向CHF报告计费 | | Precedence | 规则优先级 | 用于SDF模板匹配优先级 | --- ### Phase 3：UPF选择与N4会话建立（Step 9-11） #### Step 9：UPF选择（TS 23.501 Section 6.3.3） SMF根据以下因素选择UPF： 1. **DNN + S-NSSAI**：过滤支持该DNN和切片的UPF 2. **DNAI（DN Access Identifier）**：边缘计算场景中，选择靠近应用部署位置的UPF 3. **UE Location**：选择拓扑距离UE最近的UPF（减少N3隧道延迟） 4. **UPF负载**：NRF上报的UPF负载信息 5. **N4能力**：UPF支持的PFCP特性（如Multi-Access、UL CL能力） #### Step 10-11：N4 PFCP Session Establishment（TS 29.244 Section 7.5.2） SMF通过PFCP协议向UPF建立N4会话，下发三类核心规则： | 规则类型 | 全称 | 功能 | 关键IE | |---------|------|------|--------| | **PDR** | Packet Detection Rule | 定义如何识别数据包 | PDI（Source Interface, F-TEID, SDF Filter） | | **FAR** | Forwarding Action Rule | 定义如何转发数据包 | Action（FORWARD/DROP/BUFFER）, Outer Header Creation | | **QER** | QoS Enforcement Rule | 定义QoS限速 | Gate Status, MBR, GBR, QFI | **PFCP Session Establishment Request消息结构**（TS 29.244 Section 7.5.2.2）： ``` PFCP Session Establishment Request ├── Node ID (SMF标识) ├── F-SEID (SMF侧的PFCP会话端点) ├── Create PDR #1 (上行: UPF → DN, N6接口) │ ├── PDI: │ │ ├── Source Interface = CORE (上行) │ │ ├── F-TEID (SMF分配, 用于GTP-U匹配) │ │ └── SDF Filter (Service Data Flow模板) │ ├── Outer Header Removal = GTP-U/IPv4 │ ├── FAR ID → FAR #1 │ └── QER ID → QER #1 ├── Create FAR #1 (上行转发规则) │ ├── Apply Action = FORW (Forward) │ └── Forwarding Parameters: │ ├── Destination Interface = CORE (N6) │ └── Network Instance = DNN值 ├── Create PDR #2 (下行: DN → UPF → RAN, N3接口) │ ├── PDI: │ │ ├── Source Interface = CORE (下行) │ │ └── UE IP Address │ ├── FAR ID → FAR #2 │ └── QER ID → QER #1 ├── Create FAR #2 (下行转发规则, 此时目标RAN未知) │ └── Apply Action = BUFF (缓存, 等待RAN信息) └── Create QER #1 (默认QoS Flow的限速规则) ├── QFI = 默认5QI对应的QFI ├── Gate Status = OPEN └── MBR = Session-AMBR ``` **UPF的响应**（TS 29.244 Section 7.5.2.3）： - 返回UPF侧的F-SEID（PFCP会话端点标识） - 返回UPF为N3接口分配的F-TEID（GTP-U隧道端点）——这个TEID将在后续下发给RAN，作为N3上行数据的目的TEID --- ### Phase 4：NAS响应与N2资源分配（Step 12-18） #### Step 12-13：N1N2MessageTransfer（TS 29.518 Section 5.2.2.3） SMF通过 `Namf_Communication_N1N2MessageTransfer` 将**两条信息**打包发送给AMF： - **N1 SM Container**：`PDU SESSION ESTABLISHMENT ACCEPT`（给UE的NAS响应） - **N2 SM Info**：`PDU Session Resource Setup Request`（给RAN的N2容器） AMF拆包后： - N1 NAS消息封装在 `DL NAS TRANSPORT` 中发给UE - N2 SM Info封装在 `NGAP PDU Session Resource Setup Request` 中发给RAN #### PDU Session Establishment Accept关键IE（TS 24.501 Section 8.3.10） | IE名称 | 说明 | |--------|------| | PDU Session ID | 确认建立的会话标识 | | PDU Session Type | 协商后的类型（IPv4/IPv6/IPv4v6） | | SSC Mode | 协商后的SSC模式 | | QoS Rules | 默认QoS规则（QFI + Packet Filter） | | Session-AMBR | 会话聚合最大比特率 | | PDU Address | 分配的IP地址（IPv4/IPv6前缀） | | 5GSM Cause | 建立结果（26表示成功） | | DNN | 确认使用的DNN | #### N2 PDU Session Resource Setup（TS 38.413 Section 8.4.1） RAN通过NGAP消息获取建立N3隧道所需的全部参数： | NGAP IE | 说明 | 来源 | |---------|------|------| | PDU Session Resource Setup List | 会话列表 | AMF组装 | | PDU Session ID | 会话标识 | SMF | | QoS Flow Setup Request List | QoS流建立请求 | SMF根据PCC规则生成 | | QFI + 5QI + ARP | QoS参数 | PCF → SMF映射 | | UL NG-U UP TNL Information | 上行N3隧道终点（UPF IP+TEID） | UPF通过N4分配 | | Network Instance | DNN标识 | SMF | **RAN的处理**： 1. 根据QoS参数（5QI/ARP）建立DRB（Data Radio Bearer） 2. 通过RRC Reconfiguration配置UE的空口资源 3. 分配自己的N3隧道终点（RAN IP + RAN TEID） #### Step 17-18：N3隧道最终打通 RAN在 `N2 PDU Session Resource Setup Response` 中返回RAN侧的N3隧道信息（RAN F-TEID）。AMF通过 `Nsmf_PDUSession_UpdateSMContext` 转发给SMF，SMF再通过 **N4 PFCP Session Modification** 更新UPF的下行FAR规则——将下行数据的转发目标从"缓存"改为"转发到RAN的N3隧道"。 **此时完整的用户面数据路径形成**： ``` UE ←→ (Uu空口) ←→ RAN ←→ (N3 GTP-U) ←→ UPF ←→ (N6) ←→ DN ``` --- ## 四、SMF状态机转换（TS 23.502 Section 4.3.2） ```mermaid stateDiagram-v2 [*] --> No_Session: UE未建立PDU会话 No_Session --> SM_Context_Created: CreateSMContext Request
(Step 4) note right of SM_Context_Created: SM Context存在
但N4/N3未建立 SM_Context_Created --> Policy_Obtained: PCF Policy Create
(Step 8) note right of Policy_Obtained: PCC规则已获取
QoS参数确定 Policy_Obtained --> N4_Established: PFCP Session Est.
(Step 10-11) note right of N4_Established: UPF资源预留
UL CL/PDR/FAR已下发 N4_Established --> N1N2_Transferred: N1N2Msg Transfer
(Step 12) note right of N1N2_Transferred: NAS Accept已发送
等待RAN响应 N1N2_Transferred --> Active: N2 Resource Setup Response
(Step 16-17) note right of Active: 用户面数据通道就绪
N3隧道已打通 Active --> [*]: PDU Session Release ``` --- ## 五、QoS Flow与DRB映射机制 PDU会话建立过程中，SMF根据PCF下发的PCC规则创建QoS Flow。每个PDU会话至少包含一个**默认QoS Flow**（使用签约的Default 5QI），其特征： | 属性 | 默认QoS Flow | 专属QoS Flow | |------|-------------|-------------| | 5QI | 来自UDM签约数据 | 来自PCF PCC规则 | | ARP | 来自UDM签约数据 | 来自PCF PCC规则 | | 创建时机 | PDU会话建立时自动创建 | PCF动态下发时创建 | | 生命周期 | 与PDU会话相同 | 可独立删除 | | 类型 | 总是Non-GBR | 可为GBR或Non-GBR | | Packet Filter | 允许所有流量（"permit all"） | 绑定特定SDF Filter | **5QI到DRB的映射**（RAN本地策略）： - RAN将相同或相似QoS需求的QoS Flow映射到同一个DRB - 3GPP标准不强制规定映射算法，各厂商实现不同 - 典型策略：Non-GBR Flow共享一个DRB，每个GBR Flow独占一个DRB --- ## 六、IPv4/IPv6地址分配机制（TS 23.501 Section 5.8.2） PDU会话建立过程中，IP地址分配有三种方式： | 分配方式 | 执行者 | 协议 | 适用场景 | |---------|--------|------|---------| | **SMF本地分配** | SMF | 内部地址池管理 | IPv4为主，小型网络 | | **DHCPv4/v6** | SMF作为DHCP Client | RFC 2131/8415 | 需要集中地址管理 | | **Router Advertisement** | UPF | ICMPv6 RA | IPv6 Stateless Address | | **External DN分配** | DN/AAA | RADIUS/Diameter | 企业专线、APN专网 | **IPv6地址分配的完整流程**： 1. SMF为UE分配Interface Identifier（接口标识） 2. SMF通过PDU Session Establishment Accept下发IPv6 Prefix（/64） 3. UE通过IPv6 Stateless Address Autoconfiguration生成完整IPv6地址 4. 可选：SMF通过NDP Proxy或DHCPv6 PD提供额外前缀 --- ## 七、抓包识别与排错实战 ### 7.1 Wireshark抓包识别要点 | 接口 | 协议 | 关键Filter | 识别特征 | |------|------|-----------|---------| | N1（空口） | NAS 5GSM | `nas-5gs.protocol_discriminator == 0x0e` | PDU Session ID + PTI匹配 | | N2（NGAP） | NGAP | `ngap.procedureCode == 34` | PDU Session Resource Setup | | N4（PFCP） | PFCP | `pfcp.message_type == 50` | PFCP Session Est. Request | | N11（SBI） | HTTP/2 | `http2.headers.path contains "sm-contexts"` | POST /sm-contexts | | N7（SBI） | HTTP/2 | `http2.headers.path contains "sm-policies"` | POST /sm-policies | ### 7.2 常见故障点与排错 | 故障现象 | 可能原因 | 排查命令/方法 | |---------|---------|--------------| | UE收到24（5GSM: Insufficient Resources） | UPF资源不足或N4建立失败 | 检查SMF日志中N4 Response的Cause | | UE收到27（Missing or unknown DNN） | DNN未签约或SMF不支持 | 检查UDM订阅数据中Allowed DNN列表 | | UE收到28（Unknown PDU Session Type） | 请求的PDU类型不在签约数据中 | 核对UDM的allowedPduSessionTypes | | SM Context创建失败（HTTP 403/404） | SMF选择错误或SMF不可达 | 检查NRF Discovery结果和SMF健康状态 | | RAN N2 Setup超时 | NGAP消息丢失或RAN资源不足 | 抓取N2接口NGAP消息，检查Timer T | | 用户面不通（控制面成功） | N3隧道FAR未更新/TEID错误 | 抓取N3 GTP-U包，比对TEID和IP | | DNS解析失败 | PCO中DNS地址未下发 | 检查SMF的PCO构造和DNS配置 | ## 八、与非漫游场景的关键差异对比 | 维度 | 非漫游 | LBO漫游 | HR漫游 | |------|--------|---------|--------| | SMF位置 | HPLMN | VPLMN（V-SMF） | VPLMN（V-SMF）+ HPLMN（H-SMF） | | UPF位置 | HPLMN | VPLMN | VPLMN（UPF）+ HPLMN（UPF） | | PCF交互 | SMF→H-PCF | V-SMF→V-PCF | V-SMF→V-PCF, H-SMF→H-PCF | | UDM交互 | SMF→UDM | V-SMF→UDM（经由N32） | H-SMF→UDM | | N16a接口 | 不涉及 | 不涉及 | V-SMF↔H-SMF（N16a） | | 计费点 | HPLMN CHF | VPLMN CHF | 双方各自CHF | | IP地址分配 | HPLMN SMF | VPLMN V-SMF | HPLMN H-SMF（经V-SMF中继） | --- ## 九、PDU会话建立与4G PDN连接建立的对比 | 对比维度 | 5G PDU Session Est. | 4G PDN Connectivity | |---------|---------------------|---------------------| | 规范 | TS 23.502 §4.3.2 | TS 23.401 §5.10 | | NAS消息 | UL NAS TRANSPORT | ESM PDN CONNECTIVITY REQUEST | | 会话管理网元 | SMF（独立） | MME内嵌SM功能 | | 用户面网元 | UPF（独立） | SGW + PGW | | 控制面协议 | SBI（HTTP/2） | Diameter/GTP-C | | 用户面协议 | PFCP（N4） | GTP-C（S5/S8） | | QoS粒度 | QoS Flow（细粒度） | EPS Bearer（粗粒度） | | 策略接口 | N7（SBI） | Gx（Diameter） | | 会话连续性 | SSC Mode 1/2/3 | 无等效机制 | | 非IP支持 | Unstructured/Ethernet | 仅通过SCEF | | 地址分配 | IPv4/IPv6/Ethernet | IPv4/IPv6/Non-IP | --- ## 常见问题 **Q1: PDU Session Establishment中SMF为什么需要先查询UDM再查询PCF？** A: 这是设计上的必然顺序。SMF首先需要从UDM获取**签约数据**（Default 5QI、Session-AMBR、Allowed DNN等），这些数据决定了PDU会话的基本参数框架。然后SMF携带签约数据和会话信息向PCF请求**策略决策**，PCF在签约数据的约束范围内下发具体的PCC规则（包括动态QoS、计费策略、门控策略等）。如果PCF认为签约数据不允许该会话建立，会返回错误。因此UDM→PCF的顺序不能颠倒。 **Q2: N4 PFCP Session建立时下行FAR为什么是BUFF（缓存）而不是FORW（转发）？** A: 因为在N4建立阶段（Step 10），RAN尚未分配N3隧道终点（RAN F-TEID），UPF不知道下行数据应该发往哪里。因此SMF只能先让UPF对下行数据做缓存（BUFF Action）。等到Step 16-17收到RAN返回的N3隧道信息后，SMF再通过N4 Session Modification将下行FAR从BUFF更新为FORW，填入RAN的IP和TEID。这是控制面先于用户面完成的经典设计——"先建规则，后填参数"。 **Q3: 如果UE同时请求IPv4和IPv6（IPv4v6），地址分配过程是怎样的？** A: 当PDU Session Type为IPv4v6时（TS 23.501 Section 5.8.2），SMF可以同时分配IPv4地址和IPv6前缀。IPv4地址通过PDU Session Establishment Accept的PDU Address IE直接下发给UE；IPv6前缀也通过同一IE下发Interface Identifier，UE通过Stateless Address Autoconfiguration（RFC 4862）自行构造完整IPv6地址。某些场景下SMF可能只分配一种地址类型，此时5GSM Cause会指示"DNN congestion"或"PDU session type IPv4 only allowed"。 **Q4: AMF在PDU会话建立过程中能看到NAS消息内容吗？** A: AMF可以看到NAS消息的**外层封装**（如UL NAS TRANSPORT的Payload Container Type和PDU Session ID），但**不解析5GSM消息内容**。AMF的角色是"透传代理"——根据PDU Session ID确定目标SMF，然后将整个NAS PDU原封不动地转发给SMF。这是5G架构设计的核心原则：移动性管理（AMF）和会话管理（SMF）严格解耦，AMF不关心QoS、IP地址分配等会话级细节。 **Q5: PDU会话建立失败时，SMF如何清理已分配的资源？** A: SMF维护了完整的资源分配状态机。如果流程在某个步骤失败，SMF按反向顺序清理：若N4已建立则发起PFCP Session Deletion释放UPF资源；若PCF策略已创建则发起Npcf_SMPolicyControl_Delete释放策略资源；若UDM订阅已注册则发起Nudm_UECM_Deregistration。SM Context在资源清理后被标记为释放状态。整个清理过程遵循**"谁创建谁释放"**的原则。 --- ## 参考来源 1. [3GPP TS 23.502 V18.x.x](https://www.3gpp.org/DynaReport/23502.htm) — Section 4.3.2 PDU Session Establishment, Section 4.3.2.2.1 UE-initiated 2. [3GPP TS 24.501 V18.x.x](https://www.3gpp.org/DynaReport/24501.htm) — Section 8.3.9/8.3.10 PDU SESSION ESTABLISHMENT REQUEST/ACCEPT NAS消息定义 3. [3GPP TS 29.502 V18.x.x](https://www.3gpp.org/DynaReport/29502.htm) — Section 5.1.1 Nsmf_PDUSession Service, Section 6.1.6 SM Context数据结构 4. [3GPP TS 29.244 V18.x.x](https://www.3gpp.org/DynaReport/29244.htm) — Section 7.5 PFCP Session Management, Section 7.5.2 PFCP Session Establishment 5. [3GPP TS 38.413 V18.x.x](https://www.3gpp.org/DynaReport/38413.htm) — Section 8.4.1 PDU Session Resource Setup NGAP消息 6. [3GPP TS 29.512 V18.x.x](https://www.3gpp.org/DynaReport/29512.htm) — Section 4.2 Npcf_SMPolicyControl Service操作 --- > 本文由「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)