首页 › core-network › 5G PDU会话建立信令流深度解读

TS 23.502 clause 4.3.2 深度解读:UE请求的PDU会话建立全流程

一、为什么PDU会话建立是5GC最核心的流程

在5G核心网(5GC)中,UE要访问任何数据业务(上网、IMS语音、切片专用网络、边缘计算),都必须先建立一个PDU会话(PDU Session)。它对应4G时代的PDN连接,但在架构上发生了根本变化:4G里承载管理由MME/SGW/PGW一条GTP-C信令链串起来,而5G把会话管理拆成了服务化接口(SBI)+ N4(PFCP)+ N2(NGAP)+ N1(NAS)四个平面协作。

整个流程由 3GPP TS 23.502《Procedures for the 5G System》clause 4.3.2 定义(Stage 2),NAS层消息格式定义在 TS 24.501,SBI API定义在 TS 29.502,N4的PFCP消息定义在 TS 29.244。其中clause 4.3.2.2.1定义了非漫游和本地疏导(LBO)漫游场景下UE请求的PDU会话建立,clause 4.3.2.2.2定义归属地路由(Home-Routed, HR)漫游场景,clause 4.3.2.2.3定义SMF选择机制。

理解这个流程的意义在于:

下面按规范逐条拆解。

二、总体信令时序(非漫游/LBO场景)

先给出完整的21步信令时序图,对应TS 23.502 V18.11.0图4.3.2.2.1-1(实际含21步以上交互,下图为关键路径简化版):

sequenceDiagram
    autonumber
    participant UE
    participant AN as (R)AN
    participant AMF
    participant SMF
    participant UDM
    participant PCF
    participant UPF
    UE->>AMF: NAS: PDU Session Establishment Request<br/>(N1 SM container)
    AMF->>AMF: 校验S-NSSAI/DNN + SMF选择<br/>(NSSF/NRF)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
    SMF->>UDM: Nudm_SDM_Get + Nudm_SDM_Subscribe<br/>(会话管理签约数据)
    SMF-->>AMF: CreateSMContext Response (SM Context ID)
    Note over SMF: 可选:DN-AAA二次鉴权(clause 4.3.2.3)
    SMF->>PCF: Npcf_SMPolicyControl_Create<br/>(SM Policy Association)
    SMF->>UPF: N4 Session Establishment Request (PFCP)
    UPF-->>SMF: N4 Session Establishment Response<br/>(CN Tunnel Info / UE IP)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 SM info + N1 SM container)
    AMF->>AN: N2 PDU Session Request
    AN->>UE: RRC Reconfiguration +<br/>PDU Session Establishment Accept
    AN-->>AMF: N2 PDU Session Response (AN Tunnel Info)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext
    SMF->>UPF: N4 Session Modification<br/>(下发AN Tunnel Info)
    SMF->>UDM: Nudm_UECM_Registration (SMF注册)
    UPF->>UE: IPv6 Router Advertisement (RA)
    Note over UE,UPF: 用户面N3隧道打通,首包上下行可传输

设计意图:为什么要分两个N4阶段

注意上图中出现了两次N4交互(步骤10和步骤16)。这是很多初学者的疑惑点。规范的设计逻辑是:

  1. 第一次N4(Session Establishment)发生在RAN侧隧道信息未知时——SMF先让UPF分配CN侧隧道端点(CN Tunnel Info)和UE IP地址,这样才能通过N2把“UE该往哪发上行数据”的信息带给RAN;
  2. 第二次N4(Session Modification)发生在RAN返回AN Tunnel Info之后——SMF把RAN的N3隧道端点下发给UPF,下行通路才真正打通。

这体现了一个通用原则:控制面先行,用户面闭环靠“请求-响应”两段式完成,避免UPF在不知道对端地址的情况下安装无效转发规则。

三、逐段解析关键信令与信息元素(IE)

3.1 步骤1:UE发起的NAS请求(N1 SM Container)

UE通过AN透传NAS消息给AMF,其中包含两个层次的信息:

IE 说明 设计意图
PDU Session ID UE本地生成的会话标识 保证UE与网络状态同步,EPS互操作时保持一致
Requested PDU Session Type IPv4/IPv6/IPv4v6/Ethernet/Unstructured UE声明能力,SMF按签约数据校验
Requested SSC mode 1/2/3 决定锚点迁移时IP是否保持
5GSM Capability / PCO UE能力与协议配置选项 承载P-CSCF发现请求、MTU等
UE Integrity Protection Maximum Data Rate UE支持的UP完整性保护最大速率 SMF据此决定是否接受"Required"级保护
Always-on PDU Session Requested 请求常开会话 区别于4G的always-on PDN
RSN / PDU Session Pair ID 冗余传输指示 URLLC双隧道场景(clause 5.33.2.1)

规范细节:若Request Type为"initial request"且携带Old PDU Session ID,说明这是SSC mode 3的“先建后删”迁移;若为"Emergency Request",AMF不期望UE携带S-NSSAI和DNN,改用本地配置值,且HR模式禁止用于紧急会话。

3.2 步骤2:AMF的会话参数确定与SMF选择

AMF收到请求后做三件事:

  1. 校验S-NSSAI:NAS消息无S-NSSAI时,AMF从当前Allowed NSSAI中确定;无DNN时,按该S-NSSAI的默认DNN(签约信息中存在)或本地配置DNN处理;
  2. DNN替换:若UE请求的DNN不在Subscribed DNN List中,AMF可依据PCF下发的运营策略请求PCF执行DNN替换(clause 4.16.2.1.1),否则直接拒绝;
  3. SMF选择:按clause 4.3.2.2.3执行,规范定义了标准发现链路:
sequenceDiagram
    autonumber
    participant AMF
    participant NSSF
    participant NRF
    AMF->>NSSF: Nnssf_NSSelection_Get<br/>(S-NSSAI, PLMN ID, TAI)
    NSSF-->>AMF: 返回该切片实例适用的NRF<br/>(可选NSI ID)
    AMF->>NRF: Nnrf_NFDiscovery_Request<br/>(S-NSSAI, DNN, SUPI的PLMN)
    NRF-->>AMF: 返回候选SMF实例地址/FQDN
    Note over AMF: HR漫游时AMF同时选择V-SMF与H-SMF

若AMF已通过配置或注册时获得的NSSF信息知道合适的NRF,可跳过第一步只做NRF发现——这是非漫游与HR漫游都适用的两条部署分支。

3.3 步骤3–5:AMF与SMF建立SM上下文关联

AMF调用Nsmf_PDUSession_CreateSMContext,关键参数包括SUPI、选定的DNN、S-NSSAI(LBO时还带HPLMN映射值)、PDU Session ID、GUAMI(AMF标识)、User Location Information、Access Type、RAT Type、PEI、GPSI以及完整的N1 SM container。规范特别要求:当S-NSSAI配置了NS-AoS(切片服务区域限制)或位于Partially Allowed NSSAI中时,AMF必须向SMF传递Slice Area Restriction指示。

SMF侧在步骤4通过Nudm_SDM_Get获取(SUPI, DNN, S-NSSAI)对应的Session Management Subscription data——其中包含Allowed PDU Session Type(s)、Allowed SSC mode(s)、默认5QI与ARP、签约Session-AMBR,并订阅Nudm_SDM_Subscribe监听签约变更。SMF同时检查LADN有效性:若DNN对应LADN且UE在服务区外,将拒绝建立。

3.4 步骤6–9:策略、鉴权与锚点选择

这一段是流程中分支最多的部分:

3.5 步骤11–14:N2 SM information与RAN资源建立

SMF把结果打包成两份,经Namf_Communication_N1N2MessageTransfer交给AMF:

RAN收到N2 PDU Session Request后执行AN特定信令(如RRC Connection Reconfiguration),分配AN Tunnel Info并透传N1消息给UE;然后以N2 PDU Session Response回报,其中可携带被拒绝的QFI列表——SMF负责据此更新UE侧QoS规则。规范明确:RAN无法满足"Required"级UP安全强制时必须拒绝整个会话的用户面资源,只能降级"Preferred"级。

3.6 步骤15–19:用户面闭环与收尾

AMF把RAN返回的AN Tunnel Info经Nsmf_PDUSession_UpdateSMContext转给SMF;SMF执行第二次N4交互把AN Tunnel Info注入UPF转发规则(PDR/FAR),此后UPF可向UE下发缓冲的下行数据。随后:

四、HR漫游场景的关键差异(clause 4.3.2.2.2)

Home-Routed漫游下,流程在V-SMF与H-SMF之间纵向切分,规范定义了严格的可见性规则:

V-SMF/H-SMF通过N16上的Nsmf_PDUSession_Create/Update交互,V-SMF可依据与HPLMN的SLA或本地QoS策略部分接受H-SMF的QoS流,并在后续通知H-SMF被拒的QFI。规范还定义了V-SMF向H-SMF传递VPLMN QoS约束的机制,用于H-SMF在策略决策时参考,避免V-SMF在步骤13整单拒绝会话。HR场景下若AF需要影响HR会话在VPLMN的流量路由(HR-SBO),规范在clause 4.3.6.5单独定义了经NEF→UDR→V-SMF的通知链路。

flowchart LR
    subgraph VPLMN["访问地网络 VPLMN"]
        AMF[V-AMF] --> VSMF[V-SMF] --> VUPF[V-UPF]
    end
    subgraph HPLMN["归属地网络 HPLMN"]
        HSMF[H-SMF] --> HUPF[H-UPF]
    end
    VSMF -- N16: Nsmf_PDUSession_Create/Update --> HSMF
    VUPF -- N9隧道 x2 --> HUPF
    HSMF -. Npcf: SM Policy --> PCF[H-PCF]
    HSMF -. Nudm --> UDM[UDM]

HR场景最大的结构特征是:UE与H-SMF之间隔着两个“翻译层”——V-SMF负责接入侧资源(N2/N4),H-SMF负责策略与DN侧锚定,N9隧道成对建立。

五、会话管理的状态机视角

从状态机角度看,一次成功的建立意味着SMF内SM上下文从“无”进入INACTIVE-ACTIVE,且NAS层SM状态同步为PDU SESSION ACTIVE:

stateDiagram-v2
    [*] --> INACTIVE_NO_CONTEXT: UE发送PDU Session Establishment Request
    INACTIVE_NO_CONTEXT --> PENDING_SM_CONTEXT: AMF CreateSMContext + SMF签约校验通过
    PENDING_SM_CONTEXT --> FAILED: 签约拒绝 / NSAC超限 / UP安全无法满足
    PENDING_SM_CONTEXT --> ACTIVE_PENDING_UP: N4 Establish完成 + N1N2下发
    ACTIVE_PENDING_UP --> ACTIVE: RAN返回AN Tunnel Info + N4 Modification
    FAILED --> [*]: SMContextStatusNotify(Release)
    ACTIVE --> INACTIVE_NO_CONTEXT: PDU Session Release
    ACTIVE --> ACTIVE_PENDING_UP: 去激活(AN Release)
    ACTIVE_PENDING_UP --> ACTIVE: Service Request重激活

六、实战:抓包识别与常见故障排查

6.1 抓包识别要点

在N2/N11/N4/N7各接口分别抓包时,关注以下“锚点特征”:

接口 识别特征 常见问题信号
N1(经NAS透传) PDU Session Establishment Request/Accept/Reject 5GSM cause value(如#28未知DNN、#43切片不可用)
N11 (AMF↔SMF) POST /nsmf-pdusession/v1/sm-contexts HTTP 4xx/5xx、n1SmMsg为空
N7 (SMF↔PCF) POST /npcf-smpolicycontrol/v1/policies PCF返回错误导致SMF终止流程
N4 (SMF↔UPF) PFCP Session Establishment/Modification Request UPF响应中Cause≠"Request accepted"
N2 (RAN↔AMF) NGAP PDUSessionResourceSetupRequest/Response Response中拒绝的QFI列表、Cause

PCAP实操建议:PDU Session ID贯穿N1/N2/N11/N4/N7五个接口,是跨接口关联消息的第一主键;SUPI(或PEI)用于关联UE级信令。在Wireshark中过滤PFCP(UDP 8805)时可用pfcp.seid或pfcp.fo_node_id锁定SMF-UPF会话对。

6.2 高频故障模式与排查思路

  1. DNN/S-NSSAI不匹配:UE请求的DNN不在签约列表且无通配DNN,AMF侧(而非SMF)就会拒绝。排查顺序:先查AMF是否按签约做了DNN替换,再看SMF是否收到正确的映射S-NSSAI(LBO场景须同时携带VPLMN与HPLMN两个值)。
  2. N4会话建立失败但SM上下文已建:典型于UPF容量不足或PDR规则冲突。规范明确SMF此时应通过Nsmf_PDUSession_CreateSMContext Response携带拒绝原因,AMF据此向UE回PDU Session Establishment Reject。
  3. RAN拒绝部分QFI:常见于UE-Slice-MBR超限(clause 5.7.1.10)或UP完整性保护无法满足。表现为N2 PDU Session Response携带rejected QFI列表,SMF后续须触发单独的PDU Session Modification流程同步UE侧QoS规则——这是很多实现容易遗漏的后续动作。
  4. HR漫游中V-SMF整单拒绝:V-SMF依据SLA评估H-SMF的QoS参数,若全部拒绝则触发HR模式的PDU会话释放流程(clause 4.3.4.3步骤1b–3b),UE侧表现为会话反复建立失败。排查重点是两网之间的漫游QoS协商配置。
  5. 紧急会话特例:AMF对"Emergency Request"不期望S-NSSAI/DNN,SMF也不做DN-AAA二次鉴权;若在紧急会话流程中看到对UDM的注册,需检查是否符合规范中的豁免条款(仅在特定运营配置下才允许)。

七、设计哲学总结

回顾clause 4.3.2,可以提炼出5GC会话管理的三条设计主线:

  1. 关注点分离:AMF只做路由与透传(不解析N1 SM container),SMF独占会话决策,UPF纯数据面——这让切片管理、边缘计算、策略控制都能以SMF为枢纽独立演进;
  2. 签约与策略双校验:会话合法性由UDM签约数据(静态)和PCF PCC规则(动态)双重把关,且SMF全程订阅签约变更通知,实现“边用边改”;
  3. 控制面与用户面解耦的两段式建立:CUPS架构下N4分两次交互完成隧道闭环,天然支持UPF弹性扩缩容与会话锚点迁移(SSC mode 2/3的迁移流程即复用同一套N4/N2原语)。

对于从事5GC研发与运维的工程师,把clause 4.3.2的每一个IE和每一条分支吃透,等于掌握了打开5GC其余所有会话类流程(修改、释放、切换、HR-SBO、MA-PDU)的钥匙——因为它们全部构建在这同一套N1/N2/N4/N7/SBI原语之上。

常见问题

Q: PDU Session Establishment和PDN Connection(4G)在信令架构上的本质区别是什么? A: 4G中PDN连接建立走MME→SGW→PGW的GTP-C链式信令(Create Session Request/Response),控制面消息逐跳转发;5G中AMF通过SBI(N11)直接调用SMF服务,SMF再通过N4(PFCP)直控UPF,PCF/UDM按需介入,控制面呈星型服务化拓扑,且N1 SM container对AMF透明,会话逻辑完全内聚在SMF。

Q: 步骤1中UE为什么不直接指定UPF或锚点位置? A: UPF选择是网络运营决策(受切片、DNAI、时延策略、漫游协议约束),UE只表达业务意图(S-NSSAI、DNN)。即便SSC mode 3迁移时UE携带Old PDU Session ID,新锚点仍由网络侧选择,UE无法干预。

Q: PDU Session ID在UE侧和网络侧如何保证一致? A: 规范要求由UE生成并在请求中携带,SMF以该ID为索引创建SM上下文;在EPS/5GS互操作中,若会话迁移自EPC,则沿用4G侧SMF+PGW-C为PDN连接分配的ID(EPS场景下由网络分配),从而实现跨系统状态同步。

Q: Always-on PDU Session和普通会话有什么实际差异? A: Always-on会话在UE进入CM-IDLE后,网络保留会话上下文且UPF持续缓冲/处理下行触发(如Data Notification),重激活时延更低;普通会话可能被SMF在空闲后选择性释放。SMF可在UE未请求的情况下主动授予Always-on(Establishment Accept中的"Always-on PDU Session Granted"指示)。

Q: 如何快速判断一次会话建立失败发生在哪个环节? A: 抓N11(Nsmf_PDUSession_CreateSMContext)的响应:若AMF侧即拒绝(HTTP错误或N1 Reject cause),问题在DNN/S-NSSAI校验或SMF选择;若CreateSMContext成功但后续N1 SM container为PDU Session Establishment Reject,结合5GSM cause value定位到签约/NSAC/DN-AAA/N4环节;若Accept已下发但业务不通,则重点查N4 Modification是否成功及RAN侧N2 Response中的QFI拒绝情况。

参考来源

  1. 3GPP TS 23.502 V18.11.0 (Release 18) — clause 4.3.2(PDU会话建立)、clause 4.3.2.3(DN-AAA二次鉴权)、clause 4.3.2.2.3(SMF选择)、clause 4.16.4(SM Policy关联建立)
  2. ETSI TS 23.502 版本目录页 — 各Release(15–18)官方PDF下载入口,本文引用的V18.11.0发布于2025年9月
  3. 3GPP TS 24.501(NAS协议,Stage 3) — PDU Session Establishment Request/Accept/Reject的NAS层IE编码定义(配套阅读)
  4. 3GPP TS 29.244(PFCP,Stage 3) — N4会话建立/修改报文与PDR/FAR/QER/URR规则结构定义(配套阅读)

本文由「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学通信知识星球海报-扫码加入