5G核心网PDU Session Establishment流程详解：UE发起信令与抓包实战

1. 从一条空正文说起：为什么这个流程值得单独拆解

拿到这个标题的时候，项目正文是空的，关键词和摘要描述也都没给。这种情况其实挺常见——很多时候一个技术点本身就是标题，不需要额外解释。但“UE发起的PDU Session Establishment流程”这几个字，放在5G核心网的学习路径里，分量相当重。

先说清楚它是什么。PDU Session，全称Protocol Data Unit Session，是5G系统里UE（用户设备）和外部数据网络（DN）之间的一条逻辑通道。你可以把它理解成4G时代的PDN连接，但5G把它重新设计了，粒度更细、灵活性更高。UE要上网、要访问企业内网、要跑VoNR语音，第一步都得先建立一条PDU Session。没有这条会话，UE在5G网络里就是个“孤岛”，什么都干不了。

那“UE发起”又意味着什么？PDU Session Establishment有两种触发方式：一种是UE主动发起，比如你打开手机想刷视频，UE就向网络请求建立会话；另一种是网络侧发起，比如某些特定业务需要网络主动通知UE建立会话。这篇主要聊UE发起的场景，这也是日常优化和核心网调测中最常遇到的一类。

适合谁看？如果你刚开始接触5GC信令流程，或者做无线侧优化想搞明白空口背后发生了什么，又或者你是核心网工程师需要理清SMF、UPF、AMF之间的交互逻辑，这个流程都是绕不过去的基本功。我会尽量把每个网元在干什么、每条消息为什么这么设计、实际抓包时容易在哪里卡住，都掰开揉碎讲清楚。

注意：本文基于3GPP TS 23.502和TS 24.501的通用流程框架展开，结合的是行业里常见的实现方式。不同设备厂商在具体消息参数和定时器取值上可能有差异，实际调测时以现网设备文档为准。

2. 流程启动之前：UE侧需要具备哪些先决条件

2.1 注册流程已经完成，UE处于RM-REGISTERED状态

PDU Session Establishment不是孤立发生的。在它之前，UE必须已经完成了Registration流程，和网络之间建立了RM-REGISTERED状态。这个状态意味着UE在AMF里有了上下文，5G-GUTI分配好了，安全上下文也激活了。没有这一步，UE连“我是谁”都没告诉网络，更别提请求建立数据通道了。

我见过一些刚入行的朋友抓包时只盯着PDU Session Establishment Request看，结果发现前面根本没有Registration Complete，那后面的流程自然跑不通。所以排查任何PDU会话问题，第一件事就是确认注册流程是否干净地走完了。

2.2 UE需要知道它要建什么样的会话

UE发起PDU Session Establishment时，不是随便发一个“我要上网”就完事了。它得在请求消息里带上几个关键参数：

• PDU Session ID：UE自己分配的标识，用来区分不同的会话。比如你同时开了个人热点和企业内网接入，就是两条PDU Session，各有各的ID。
• Requested SSC mode：会话和服务连续性模式，决定了当UE移动时这条会话怎么保持。SSC Mode 1是锚点不变，Mode 2是先断后连，Mode 3是允许先建后断。日常上网场景Mode 1最常见。
• Requested PDU Session Type：IPv4、IPv6、IPv4v6或者Ethernet。现在大部分手机默认请求IPv4v6，但具体给什么还得看网络配置和签约数据。
• Requested QoS rules：UE可以建议一些QoS参数，但最终决定权在SMF手里。

这些参数不是随便填的，它们来自UE的本地配置和USIM卡里的签约信息。如果UE请求了一个签约里没有的PDU Session Type，比如签约只允许IPv4但UE非要IPv6，SMF会直接拒绝。

2.3 空口资源：RRC连接必须已经建立

PDU Session Establishment Request是通过NAS消息承载的，而NAS消息要能发出去，UE必须已经和gNB建立了RRC连接。也就是说，UE处于RRC_CONNECTED状态。如果UE在空闲态，它得先发起Service Request或者Registration流程把RRC连接建起来，才能发这条NAS消息。

这里有个容易混淆的点：RRC连接建立和PDU Session建立是两码事。RRC连接是UE和gNB之间的无线承载，PDU Session是UE和UPF之间的数据通道。前者是后者的传输管道，管道没通，NAS消息就送不出去。

实操心得：如果你在抓包时看到UE反复发PDU Session Establishment Request但没有响应，先别急着怀疑核心网。检查一下RRC连接是否稳定，有时候空口质量差导致RRC重建，NAS消息就丢了。

3. 消息从UE到SMF：一条NAS消息的完整旅程

3.1 UE到gNB：NAS消息的第一次封装

UE构造好PDU Session Establishment Request之后，把它封装在RRC消息里发给gNB。具体来说，这条NAS消息是放在RRCSetupComplete或者ULInformationTransfer消息里带上去的。gNB收到之后，它不解析NAS内容——NAS消息对gNB来说是透明的，gNB只负责把它转发给AMF。

gNB怎么知道该转发给哪个AMF？靠的是UE在注册时AMF分配的5G-GUTI或者AMF的标识信息。如果gNB和AMF之间的NG接口是通的，这条消息就能顺利过去。

这里有个细节值得注意：gNB在转发NAS消息时，还会附带上一些无线侧的辅助信息，比如UE所在的小区ID、TAI（Tracking Area Identity）、RRC建立原因等。这些信息对AMF和SMF后续做策略决策很有用，比如SMF可以根据TAI判断UE是否在漫游，从而决定要不要走本地疏导。

3.2 AMF收到消息后的第一反应：它该找谁

AMF收到PDU Session Establishment Request后，第一件事是检查这条消息的合法性。它会看UE的注册状态、安全上下文是否有效、请求的PDU Session ID是否和已有会话冲突。确认没问题后，AMF需要决定把这个请求转发给哪个SMF。

选择SMF的逻辑在3GPP里叫SMF Selection。AMF会根据UE的签约数据（从UDM拿到的）、请求的DNN（Data Network Name）、S-NSSAI（网络切片标识）以及本地配置来选。简单说就是：UE要访问哪个数据网络、用哪个切片，AMF就找负责那个范围的SMF。

如果AMF发现UE请求的DNN和签约里的不匹配，或者请求的S-NSSAI当前没有可用的SMF，它会直接拒绝，回一个PDU Session Establishment Reject，带上原因值。常见的原因值有“Request rejected, unspecified”或者“Missing or unknown DNN”。

3.3 N11接口：AMF和SMF之间的第一次握手

AMF选好SMF之后，通过N11接口发送Nsmf_PDUSession_CreateSMContext Request消息。这条消息里包含了UE的SUPI、PDU Session ID、请求的DNN、S-NSSAI、PDU Session Type、SSC mode，以及AMF从gNB那里拿到的TAI和小区信息。

SMF收到后，如果它同意建立这个会话，会回一个Nsmf_PDUSession_CreateSMContext Response，里面带上SM Context ID。这个ID是SMF内部用来标识这条会话上下文的，后续所有和这条会话相关的操作都会引用它。

注意：N11接口基于HTTP/2的SBI（Service Based Interface）架构。如果你在抓包时看到的是HTTP/2的POST请求，别惊讶，这就是5G核心网的服务化接口。和4G时代的GTP-C完全不一样了。

4. SMF拿到请求之后：它要做的几件关键事

4.1 签约数据检查：UDM里的信息说了算

SMF拿到请求后，第一件事是去UDM查UE的签约数据。具体来说，它通过N10接口向UDM发送Nudm_SDM_Get请求，获取UE的SMF Selection Subscription Data和Session Management Subscription Data。

这些签约数据里包含了很多关键信息：允许的PDU Session Type、允许的SSC mode、QoS的上下限、计费方式、是否允许漫游等。SMF会拿这些数据和UE请求的参数做比对。如果UE请求的QoS超过了签约允许的范围，SMF会降级处理或者直接拒绝。

我遇到过一种情况：UE请求的5QI是1（语音），但签约里只允许5QI 9（默认上网）。SMF不会直接拒绝，而是会把QoS降级到9，然后在响应里告诉UE实际分配的QoS。这种“请求和实际分配不一致”的情况在现网里很常见，排查时要注意看SMF返回的Authorized QoS Rules。

4.2 UPF选择：用户面锚点定在哪里

签约检查通过后，SMF要选一个UPF来作为这条PDU Session的用户面锚点。选UPF的逻辑考虑几个因素：UE的位置（TAI）、请求的DNN、S-NSSAI、UPF的负载和容量、以及网络拓扑（比如要不要做本地分流）。

选好UPF后，SMF通过N4接口向UPF发送PFCP Session Establishment Request。这条消息里包含了PDR（Packet Detection Rule）、FAR（Forwarding Action Rule）、QER（QoS Enforcement Rule）和URR（Usage Reporting Rule）。简单说就是告诉UPF：什么样的包该转发、怎么转发、限速多少、怎么计费。

UPF配置好之后，回一个PFCP Session Establishment Response，里面带上UPF分配的F-SEID。这个F-SEID是后续N3和N4隧道建立的基石。

4.3 N1N2消息传递：SMF怎么把参数告诉UE和gNB

UPF准备好之后，SMF需要把两件事分别告诉UE和gNB。告诉UE的是PDU Session Establishment Accept，里面包含分配的IP地址、QoS规则、SSC mode等。告诉gNB的是N2 PDU Session Request，里面包含PDU Session ID、QoS Flow的配置、N3隧道信息等。

这两条消息是通过AMF中转的。SMF通过N11接口发送Nsmf_PDUSession_UpdateSMContext Request给AMF，里面同时包含了给UE的NAS消息和给gNB的N2 SM信息。AMF收到后，把NAS消息透传给UE，把N2 SM信息通过NG接口发给gNB。

这里有个关键点：SMF发给AMF的NAS消息是加密的，AMF解不开也不该解开。AMF只负责转发，这保证了NAS层的端到端安全。

5. gNB和UE收到响应后各自做了什么

5.1 gNB侧：N3隧道建立和RRC重配置

gNB收到N2 PDU Session Request后，第一件事是解析里面的QoS Flow配置。每个QoS Flow对应一个5QI，gNB需要根据5QI决定怎么在空口上调度这些流量。比如5QI 1是语音，需要GBR（保证比特率），gNB就得预留资源；5QI 9是默认上网，Non-GBR，尽力而为就行。

然后gNB要建立和UPF之间的N3隧道。N3隧道基于GTP-U，gNB用SMF提供的UPF侧TEID和IP地址作为隧道对端。隧道建好后，gNB回一个N2 PDU Session Response给AMF，里面带上gNB侧的N3 TEID和IP地址。AMF再把这个信息通过N11接口转给SMF，SMF再通过N4接口更新UPF，这样上下行隧道就都通了。

同时，gNB还要给UE发RRCReconfiguration消息，把DRB（Data Radio Bearer）配置好。DRB是空口上承载PDU Session数据的无线承载，每个PDU Session至少对应一个DRB。RRCReconfiguration里会包含DRB的PDCP、RLC、MAC层参数，UE收到后按配置建立DRB。

5.2 UE侧：收到Accept之后要做的配置

UE收到PDU Session Establishment Accept后，首先看里面分配的IP地址。如果是IPv4，UE就配置到自己的协议栈上；如果是IPv6，UE可能还需要做DAD（Duplicate Address Detection）。然后UE根据QoS Rules建立本地的QoS映射，把上层的应用流量映射到对应的QoS Flow上。

UE还会检查网络分配的SSC mode和它请求的是否一致。如果不一致，UE可以选择接受或者拒绝。大部分情况下UE会接受，因为网络侧的决定是基于签约和策略的。

DRB配置完成后，UE就可以在这条PDU Session上发数据了。第一条上行数据包会经过DRB、N3隧道、UPF，最终到达DN。整个流程从UE发出Request到能发数据，理想情况下在几百毫秒内完成。

实操心得：在现网测试时，我习惯用“PDU Session Establishment Accept里的IP地址是否可ping通”作为流程成功的标志。有时候信令上看流程走完了，但用户面不通，问题往往出在N3隧道或者UPF的PDR配置上。

6. 抓包实战：怎么在信令流程里定位问题

6.1 抓包点选择：在哪里抓能看到什么

排查PDU Session Establishment问题，抓包点的选择很关键。常见的位置有：

如果你只有UE侧的log，那只能看到“UE发了什么、收了什么”，中间网元发生了什么完全不知道。所以实际排查时，最好能同时在多个点抓包，做关联分析。

6.2 常见失败原因和排查路径

场景一：UE发了Request但没收到任何响应

先看gNB有没有把NAS消息转发给AMF。如果gNB侧抓包看到NGAP消息发出去了，但AMF侧没收到，那可能是NG接口有问题。如果AMF收到了但没回，检查AMF的日志看是不是SMF Selection失败了。

场景二：收到Reject，原因值是“DNN not supported”

这说明UE请求的DNN和签约里的不匹配。检查UDM里的签约数据，确认UE的DNN配置是否正确。有时候是UE本地配置错了DNN，有时候是签约数据没同步。

场景三：信令流程走完了但用户面不通

先检查N3隧道是否建立成功。在gNB侧看GTP-U的TEID是否和UPF侧一致。然后检查UPF的PDR配置，看是否匹配UE的IP地址和QoS Flow。常见问题是UPF的PDR里源IP配错了，导致上行包被丢弃。

场景四：UE收到Accept但IP地址是0.0.0.0

这通常是SMF没有从UPF拿到有效的IP地址，或者IP地址池耗尽了。检查SMF的IP地址池配置和UPF的地址分配日志。

6.3 一个真实的排查案例

之前遇到过一个问题：UE发起PDU Session Establishment后，信令流程显示成功，但UE就是上不了网。抓包发现UE发出的上行数据包在UPF侧被丢弃了。进一步查UPF的PDR，发现SMF下发的PDR里匹配的是UE的IPv4地址，但UE实际配置的是IPv6地址。原因是UE请求的是IPv4v6，SMF分配了IPv6，但UPF的PDR只配了IPv4的匹配规则。

这种问题就是典型的“信令成功但用户面失败”。排查时不能只看信令，一定要结合用户面抓包。后来我们在SMF的配置里加了一条规则：如果UE请求IPv4v6，SMF必须确保UPF的PDR同时支持IPv4和IPv6匹配。

7. 几个容易混淆的概念和边界条件

7.1 PDU Session Establishment和Service Request的区别

很多人会把这两个流程搞混。Service Request是UE从空闲态回到连接态时发的，目的是恢复已有的PDU Session的用户面连接。而PDU Session Establishment是新建一条会话。简单说：Service Request是“唤醒”已有的会话，PDU Session Establishment是“创建”新的会话。

如果UE在空闲态想新建一条PDU Session，它需要先发Service Request把RRC连接建起来，然后再发PDU Session Establishment Request。这两个流程是串行的，不是二选一。

7.2 初始PDU Session和额外PDU Session

UE在注册时可以请求建立初始PDU Session，这时候PDU Session Establishment Request是放在Registration Request里一起发的。如果注册时没建，或者后续想再建一条，就是额外的PDU Session Establishment。两者的信令流程基本一样，区别在于初始PDU Session是和注册流程耦合的，AMF在处理注册的同时就处理了会话建立。

7.3 漫游场景下的特殊处理

如果UE在漫游，PDU Session Establishment流程会多几个步骤。SMF可能分为V-SMF（拜访地SMF）和H-SMF（归属地SMF），AMF先选V-SMF，V-SMF再选H-SMF。用户面数据可能走本地疏导（LBO）或者归属地路由（HR）。这些差异会影响UPF的选择和N3隧道的建立方式。排查漫游问题时，要特别注意V-SMF和H-SMF之间的N16接口是否正常。

8. 从信令流程到参数配置：几个值得关注的细节

8.1 QoS Flow和DRB的映射关系

一个PDU Session里可以有多条QoS Flow，但空口上的DRB数量是有限的。gNB会根据QoS Flow的5QI和ARP（Allocation and Retention Priority）决定怎么映射到DRB。通常默认QoS Flow（5QI 9）会映射到默认DRB，GBR Flow（比如5QI 1）会映射到专用DRB。

如果映射配置错了，比如把语音Flow映射到了默认DRB，语音质量就会受影响。排查时可以在gNB侧看QoS Flow到DRB的映射表，确认每个5QI都有对应的DRB配置。

8.2 定时器的影响

PDU Session Establishment流程里涉及多个定时器。比如UE侧的T3580，如果UE发了Request后在T3580超时前没收到Accept或Reject，UE会重发Request。AMF侧也有定时器控制SMF的响应时间。如果某个网元处理慢，定时器超时会导致流程失败。

在现网优化时，如果发现流程成功率低但信令上看不出明显错误，可以查一下各网元的定时器配置。有时候是SMF查UDM签约数据太慢，导致AMF等不及超时了。

8.3 安全模式的影响

PDU Session Establishment Request是NAS消息，受到NAS安全保护。如果UE和AMF之间的安全上下文有问题，比如密钥不一致，AMF可能解不开这条消息，直接丢弃。这种情况下UE会看到Request发出去了但没有任何响应。排查时要确认Registration流程里的安全模式命令是否成功完成。

9. 写在最后：一些个人体会

这个流程我前前后后抓过不下几百次包，每次遇到新问题都会有新的理解。刚开始的时候总觉得信令流程就是“A发B、B发C”，背下来就行。后来才发现，真正难的是理解每个网元为什么这么设计、参数为什么这么填、出了问题该从哪里入手。

如果你刚开始学这块，我的建议是：先找一个干净的测试环境，从UE发起Request开始，一步一步抓包，把每条消息的每个字段都搞清楚。不要怕慢，这个过程走一遍，比看十遍文档都管用。然后找一些失败场景，比如故意配错DNN、故意把UPF的PDR配错，看信令上会有什么表现。这种“破坏性测试”对理解流程的帮助特别大。

还有一点：5G核心网的服务化架构让信令流程变得更灵活，但也更复杂。N11、N4、N10这些接口都是基于HTTP/2或者PFCP的，和4G时代的GTP-C、Diameter完全不一样。如果你有4G的基础，学5G的时候要注意“忘掉”一些4G的思维定式，比如“信令都是二进制TLV”这种。5G的SBI接口是JSON/HTTP2的，抓包工具看到的可能是HTTP请求，别觉得奇怪。

最后，PDU Session Establishment只是5G会话管理的起点。后面还有PDU Session Modification、PDU Session Release、以及切换时的会话连续性处理。把这个流程吃透了，后面的东西都是在这个基础上做加减法。