# 5G PDU会话SMF选择与N4信令拆解 在5G核心网（5GC）中，PDU会话是UE与数据网络（DN）之间建立用户面连通的基本单位。与4G EPS的默认承载"一锅烩"不同，5G把会话管理控制面（SMF）和用户面（UPF）彻底解耦，使得"为这个PDU会话选一个SMF"和"SMF再为这个会话选一个UPF并下发N4规则"成为两条独立却紧密咬合的信令链。本文依据 **TS 23.502 Clause 4.3.2.2.1（UE-initiated PDU Session Establishment，非漫游）**、**TS 23.501 Clause 6.3.2（SMF selection）** 和 **TS 29.244（N4/PFCP）**，逐步拆解这两条链路上的关键信令、Information Element 与设计意图，并给出抓包识别与排错视角。 --- ## 一、整体信令时序：从NAS到N4的全链 下图是UE发起、非漫游场景下PDU会话建立的完整信令流（对应TS 23.502图4.3.2.2.1-1）。把它画成时序图的最大价值，是看清**"控制面隧道"和"用户面隧道"在哪里分叉、又在哪里汇合**。 ```mermaid sequenceDiagram autonumber participant UE participant gNB as (R)AN/gNB participant AMF participant SMF participant UDM participant PCF participant NRF participant UPF UE->>gNB: NAS Transport(PDU Session Establishment Request)
PDU Session ID, DNN, S-NSSAI, SSC mode, PDU Session Type gNB->>AMF: N2 (Initial UE Msg) 转发N1 SM容器 Note over AMF: Request type=initial request
无关联SMF → 执行SMF Selection AMF->>UDM: Nudm_SDM_Get(SmfSelectionSubscriptionData) UDM-->>AMF: 默认DNN / (S-NSSAI, DNN)允许列表 AMF->>NRF: Nnrf_NFDiscovery(target-nf-type=SMF, snssai, dnn) NRF-->>AMF: 候选SMF实例(FQDN/容量/负载) AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
(PduSessionId, SUPI, DNN, N1 SM容器, UserLocationInfo, RatType) SMF->>UDM: Nudm_SDM_Get(SessionMngSubscriptionData) UDM-->>SMF: Session-AMBR, 5QI, SSC, DNN签约 SMF->>UDM: Nudm_SDM_Subscribe(数据变更通知) Note over SMF: PCF Selection → 建立SM Policy Association SMF->>PCF: Npcf_SMPolicyControl_Create(SM Policy) PCF-->>SMF: PCC规则, QoS决策, Session-AMBR Note over SMF: UPF Selection(TS 23.501 6.3.3.3) SMF->>UPF: N4 Session Establishment Request(PFCP)
Create PDR/FAR/QER/URR, UE IP, F-TEID(CHOOSE) UPF-->>SMF: N4 Session Establishment Response
N3 DL F-TEID(由UPF分配) SMF->>AMF: Namf_Communication_N1N2MessageTransfer
N1=PDU Session Establishment Accept
N2=PDU Session Resource Setup(QFI, N3 DL F-TEID, QoS Profile) AMF->>gNB: N2 PDU Session Resource Setup Request(+NAS) gNB->>UE: RRC Reconfiguration(建立DRB) UE-->>gNB: RRC Reconfiguration Complete gNB-->>AMF: N2 PDU Session Resource Setup Response(N3 UL F-TEID) AMF->>SMF: Nsmf_PDUSession_UpdateSMContext(N2 SM info) SMF->>UPF: N4 Session Modification Request(下发gNB N3 UL F-TEID) UPF-->>SMF: N4 Session Modification Response SMF-->>AMF: UpdateSMContext Response ``` 时序中有两处是新手最容易看漏的关键点：**第一处是步骤②③的SMF选择发生在CreateSMContext之前**，AMF必须先"锁定"一个SMF才能发出SBI请求；**第二处是N4被拆成了两次**——建立时只下发下行（DL）F-TEID给gNB，上行（UL）F-TEID要等gNB建好DRB后回填，这是5G用户面"延迟锚定"的核心设计。 --- ## 二、SMF选择机制（TS 23.501 Clause 6.3.2） ### 2.1 选择的输入与触发条件 AMF在以下情况触发SMF选择：当收到的PDU Session Establishment Request中`Request type = "initial request"`，且当前AMF上下文里没有为该PDU Session ID关联的SMF。选择的输入是三元组 **(SUPI, S-NSSAI, DNN)**，加上PLMN ID、SMF服务区（Service Area）约束。 关键在于：**UE在NAS里上报的DNN是可选的**。当UE不提供DNN时，AMF必须向UDM取签约里的"默认DNN"。这正是UDM通过 `Nudm_SDM_Get(SmfSelectionSubscriptionData)`（TS 29.503）提供的核心数据——它为每个S-NSSAI列出允许的DNN列表以及一个default DNN。 ### 2.2 三条SMF发现路径 标准并没有规定AMF"必须"用哪一种方式发现SMF，而是给出了三种可组合的路径。理解它们的差异，是看懂不同厂商配置的关键： | 发现路径 | 关键消息/数据源 | 适用场景 | 选择决策方 | |---------|----------------|---------|-----------| | **UDM签约驱动** | `Nudm_SDM_Get(SmfSelectionSubscriptionData)`；返回每个(S-NSSAI)→[DNN列表, default DNN] | 运营商按用户/切片静态映射SMF池 | AMF | | **NRF NF发现** | `Nnrf_NFDiscovery`：参数`target-nf-type=SMF`、`snssai`、`dnn`、`smf-serving-area`；返回候选SMF及容量/负载 | 动态、多SMF实例、需要负载均衡 | AMF（按负载/容量挑选） | | **SMF Set + SCP委托** | AMF只解析到SMF Set的FQDN，由SCP做最终实例级路由（委托发现，TS 23.502 Clause e.2） | 大规模组网、SMF池化弹性、控制面CUPS化 | SCP（按Set内实例健康度） | 下面用流程图刻画AMF的SMF选择决策逻辑（融合上述三条路径）： ```mermaid flowchart TD A[AMF收到PDU Session Establishment Request
Request type=initial] --> B{UE是否提供DNN?} B -- 否 --> C[Nudm_SDM_Get SmfSelectionSubscriptionData
取default DNN] B -- 是 --> D{该 DNN+S-NSSAI 是否在签约允许列表?} C --> E[得到 S-NSSAI, DNN] D -- 否 --> X[拒绝#58 Missing or Unknown DNN] D -- 是 --> E E --> F{是否配置SMF Set/SCP委托?} F -- 是 --> G[解析到SMF Set FQDN
SCP按实例健康度路由] F -- 否 --> H[Nnrf_NFDiscovery snssai+dnn+service-area] H --> I[NRF返回候选SMF+容量/负载] I --> J[按负载/容量/拓扑亲和选择实例] G --> K[锁定SMF实例] J --> K K --> L[Nsmf_PDUSession_CreateSMContext Request] ``` ### 2.3 设计意图：为什么把SMF选择交给AMF而不是UE 把SMF选择放在AMF而非UE，是5G相对4G的一个结构性变化（4G的MME直接做PGW/S-GW选择）。这样设计有三层意图： 1. **切片感知**：AMF持有Allowed NSSAI，能保证选出的SMF与切片严格对齐，避免UE越权跨切片。 2. **拓扑解耦**：SMF可在Service Area内/外迁移（I-SMF插入/移除，TS 23.502 Clause 4.23.2），AMF集中感知UE位置变化，比把选择逻辑下沉到UE更高效。 3. **可扩展**：SMF Set + SCP委托发现使SMF可像UPF一样池化，AMF无需知道实例级地址，天然支持SMF弹性伸缩与故障转移（SMF Set级无状态化，TS 23.502 Clause 4.26）。 --- ## 三、CreateSMContext与N1 SM：控制面元数据装配 锁定SMF后，AMF发出 `Nsmf_PDUSession_CreateSMContext Request`（TS 29.502），把UE的N1 SM容器连同AMF侧上下文"打包"交给SMF。这一步是**NAS（N1）与SBI（N11）的翻译边界**。关键IE如下表： | IE名称 | 携带方 | 作用 | 抓包定位 | |-------|-------|------|---------| | `PduSessionId` | UE/AMF | 0–255范围内UE本地唯一标识，区分同一UE多个会话 | N1 SM Header | | `DNN` / `S-NSSAI` | UE(可选)/AMF | 决定UPF锚点与切片路由 | CreateSMContext.body | | `N1SmContainer` | UE→AMF→SMF | 透传 PDU Session Establishment Request（含SSC mode、5GSM capability、Requested PDU Session Type） | N1 SM container | | `UserLocationInfo` | AMF | NR-CGI/TAI，供PCF策略与计费地域判定 | UE位置相关PCC | | `RatType` | AMF | NR / EUTRA-NR / 非3GPP，影响QoS映射 | N2/N11 | | `RequestType` | AMF | initial/existing/modified；`initial`触发SMF选择 | 决定是否走选择流程 | | `OldPduSessionId` | UE(可选) | 与MA-PDU、SSC模式3重锚定相关 | 会话重锚场景 | SMF收到后，会做一次"数据下沉"：调用 `Nudm_SDM_Get(SessionManagementSubscriptionData)` 取会话级签约（Session-AMBR、默认5QI、允许的SSC mode、DNN签约），并通过 `Nudm_SDM_Subscribe` 订阅签约数据变更——这是后续PCF下发动态策略、UDM改签约时SMF能实时感知的基础。 随后SMF执行 **PCF Selection** 并发起 `Npcf_SMPolicyControl_Create`，建立SM Policy Association。PCF据此回送PCC规则、QoS决策（5QI、GBR/Session-AMBR）。只有策略就绪后，SMF才会去选UPF、下发N4——**顺序上策略先于用户面**，这是计费/限速不漏单的保证。 --- ## 四、N4（PFCP）会话建立：用户面规则的"编译" N4接口即PFCP（Packet Forwarding Control Plane，TS 29.244）。SMF在 `PFCP Session Establishment Request`（消息类型见TS 29.244 Clause 7.5.2）中，把PCF的策略"编译"成UPF可执行的转发规则。这一步是整个流程最硬核的部分。 ### 4.1 N4会话建立请求的IE结构 PFCP消息是二进制TLV编码，核心业务IE是若干个 `Create XXX` 容器，彼此用ID引用关联： | IE类别 | 关键字段 | 作用 | |-------|---------|------| | **Create PDR**（Packet Detection Rule，TS 29.244 7.5.2.2） | PDR ID、Precedence、PDI（Source Interface、F-TEID 或 UE IP Address、SDF Filter、QFI）、Outer Header Removal | 流量分类入口：决定"什么样的包进这条规则" | | **Create FAR**（Forwarding Action Rule，7.5.2.3） | FAR ID、Apply Action（FORW/DROP/BUFF/NOC）、Forwarding Parameters（Destination Interface、F-TEID=对端隧道、Network Instance） | 决定"匹配到的包去哪/怎么处理" | | **Create QER**（QoS Enforcement Rule，7.5.2.4） | QER ID、QFI、Gate Status、MBR(UL/DL)、QER Correlation Index | QoS限速、门控、QFI标记 | | **Create URR**（Usage Reporting Rule，7.5.2.5） | URR ID、Measurement Method、Reporting Triggers、Volume/Time Quota、Measurement Period | 用量测量与配额上报 | | **顶层IE** | Node ID、UE IP Address、PDN Type、FQ-CSID、User Plane Inactivity Timer | 会话级元数据 | PDR→FAR→QER→URR通过ID引用构成一张"规则网"。下图刻画PDU会话两条典型PDR（上行/下行）与FAR、QER、URR的引用关系： ```mermaid flowchart LR subgraph UL[上行 PDR#1] P1[PDR#1
SrcIface=Access
F-TEID=N3-UL-TEID
Outer Header Removal=GTP-U/UDP/IPv4] end subgraph DL[下行 PDR#2] P2[PDR#2
SrcIface=Core
UE IP Address匹配
Precedence] end P1 -->|ApplyAction=FORW| FA1[FAR#1
DstIface=Core
Network Instance=DNN] P2 -->|ApplyAction=FORW| FA2[FAR#2
DstIface=Access
F-TEID=N3-DL-TEID
由UPF分配] P1 -.-> Q1[QER#1
QFI, MBR-UL, Gate] P2 -.-> Q2[QER#2
QFI, MBR-DL, Gate] P1 -.-> U1[URR#1
Volume/Time 测量] P2 -.-> U1 ``` ### 4.2 F-TEID的"谁分配"问题 N3/N9隧道两端各有一个F-TEID（Fully Qualified TEID = TEID + IPv4/v6地址，TS 29.244 Clause 8.2.91）。这里有两条实现路线： - **UPF分配（标准默认）**：SMF在Create PDR的F-TEID IE中置 `CHOOSE` 标志位，UPF自行分配N3下行F-TEID并在 `PFCP Session Establishment Response` 中带回。 - **SMF预分配（实现优化）**：SMF直接生成F-TEID填入请求（free5GC等开源实现采用）。好处是减少一次往返，代价是SMF需维护地址池。 无论哪种，流程都是：建立阶段下发**下行F-TEID**给gNB（经N2 SM），等gNB建好DRB回送**上行F-TEID**后，SMF再用 `N4 Session Modification Request` 把上行F-TEID更新到UPF的Create FAR里。这就是为什么N4天然要分"建立+修改"两次。 ### 4.3 设计意图：为什么用PFCP规则网而不是"端到端承载" 4G用一条E-RAB/承载贯穿eNB↔S-GW↔P-GW，规则散落各处。5G改用PFCP规则网（PDR/FAR/QER/URR），意图有三：**（1）解耦分类与动作**——PDR管"识别"、FAR管"转发"、QER管"QoS"、URR管"计量"，正交可组合；**（2）UPF无状态规则化**——UPF只认规则不认会话语义，可任意池化、替换（SMF Set + UPF Pool灵活换锚，支撑SSC mode 2/3）；**（3）原生支持多锚点**——一个PDU会话可挂多个Traffic Endpoint（I-UPF/PSA1/PSA2），同一套IE模型支撑上行分类器（UL CL）与多归属，无需为MEC本地分流另造协议。 --- ## 五、实战连接：抓包识别与排错 ### 5.1 抓包如何识别这条流程 在NG接口（N2）与HTTP/2（SBI）混合抓包里，可按"锚点消息"定位： - **N1 SM锚点**：NAS消息中 `Message type = PDU session establishment request/accept`（TS 24.501 message type值见规范）。Wireless抓包里看 `Protocol: 5GS Session Management`。 - **SBI锚点**：HTTP/2 POST `/namf-comm/v1/ue-contexts/{supi}/n1-n2-messages`（N1N2MessageTransfer）是整个流程的"心脏"——它同时承载N1（给UE的Accept）和N2（给gNB的资源建立请求）。 - **N4锚点**：GTP-U over UDP 2152 之外的 PFCP（UDP，缺省端口由实现定，常配在2152之外的端口），消息类型 `PFCP Session Establishment Request (0x32)` / `Response (0x33)`，用Wireshark的PFCP dissector可直接展开各IE。 ### 5.2 常见故障点 1. **SMF选不出来**：UE上报的DNN不在UDM `SmfSelectionSubscriptionData` 允许列表 → N1回 `5GSM cause #58 (Missing or unknown DNN)`。排查UDM签约与AMF本地DNN配置是否一致。 2. **NRF返回空**：SMF未注册或注册时未声明该`snssai+dnn`能力 → `Nnrf_NFDiscovery` 候选为空。检查SMF的 `Nnrf_NFRegister` 中 `sNssaiSmfInfoList` 是否覆盖目标切片。 3. **N4失败**：UPF容量满、F-TEID地址池耗尽，或UE IP地址池（DNN对应）耗尽 → PFCP Response带 `Cause = No established PFCP sessions available` 或 `Rule creation/modification failure`。 4. **上下行隧道错位**：gNB回送N3 UL F-TEID后，SMF未及时 `N4 Session Modification`，导致UL包到UPF后无PDR匹配（F-TEID对不上）而被丢弃，表现为"上行不通、下行正常"。 5. **QER限速过严**：Session-AMBR或MBR配错，UE IP可达但速率极低，查N4 Create QER的MBR字段与PCF策略。 ## 常见问题 **Q1：PDU Session Establishment 和 Registration 的关系是什么？** A：Registration是UE在AMF建立移动性上下文（5GMM层），PDU Session Establishment是UE在已有注册基础上建立会话（5GSM层）。前者必须先完成，AMF拿到SUPI、Allowed NSSAI后才能为后者做SMF选择。两者通过SUPI与PDU Session ID关联，但信令面完全独立。 **Q2：SSC mode 如何影响这条流程？** A：SSC mode 1下会话锚点PSA固定（移动时不变，只换I-UPF/PSA间的路径）；SSC mode 2断开重建（换SMF/UPF，UE IP可能变）；SSC mode 3"先建后断"重锚（TS 23.502 Clause 4.3.4）。这三种模式都复用本文的PDU Session Establishment信令，差异体现在触发条件、OldPduSessionId使用和锚点是否迁移上。 **Q3：为什么N4要用PFCP而不用SBI（HTTP/2）？** A：N4是控制面↔用户面接口，UPF承担Tbps级转发，协议必须轻量、低开销、可硬件加速。PFCP是二进制TLV，远比JSON over HTTP/2紧凑、解析快，适合UPF线卡；而SMF与其他NF（AMF/PCF/UDM）走SBI是因为它们都是控制面网元，强调互操作与可发现性。这是5G"控制面SBI、用户面PFCP"分层架构的体现。 **Q4：SMF Set和UPF Pool有什么区别？** A：SMF Set是**控制面**网元池化（同Set内SMF共享UDM中的context，可无状态替换，TS 23.502 Clause 4.26）；UPF Pool是**用户面**网元池化（SMF按容量/拓扑选一个UPF下发N4）。两者正交：一个SMF可管理多个UPF，一个UPF Pool也可被多SMF共享。Set解决控制面弹性，Pool解决用户面就近与分流。 --- ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — Clause 4.3.2.2.1 PDU Session Establishment (UE-initiated)](https://www.3gpp.org/dynareport/23502.htm) — UE发起PDU会话建立的完整信令流程图 2. [3GPP TS 23.501 V18.10.0 — Clause 6.3.2 SMF selection / 6.3.3.3 UPF selection](https://www.3gpp.org/dynareport/23501.htm) — SMF/UPF选择功能与判据 3. [3GPP TS 29.244 — Clause 7.5.2 PFCP Session Establishment Request](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111) — N4接口PFCP消息与PDR/FAR/QER/URR IE定义 4. [3GPP TS 29.502 Nsmf_PDUSession Service / TS 29.503 Nudm_SDM](https://www.3gpp.org/dynareport/29502.htm) — CreateSMContext接口与会话签约数据（SmfSelectionSubscriptionData） 5. [PFCP Session Lifecycle in free5GC (2026-02)](https://free5gc.org/blog/20260204/20260204/) — F-TEID分配与N4会话生命周期的开源实现解读 6. [ShareTechnote — 5G SMF / PDU Session](https://www.sharetechnote.com/html/5G/5G_Core_SMF.html) — 信令流程中文图解与步骤说明 --- > 本文由「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 等场景全覆盖。