智能手机可能已经显示 5G 图标，但网页仍然无法加载。出现这种情况时，第一反应往往是检查注册流程：5G-AKA 是否完成？是否收到了 Registration Accept？T3512 是否超时？逐项检查之后，可能会发现 Registration 流程完全正常，但数据业务仍然不可用。
很多情况下，问题并不在 Registration，而在 PDU Session。Registration 回答的是“UE 能否注册到 5GS？”，PDU Session Establishment 回答的是下一个问题：“UE 是否真正能够访问数据网络？”本文从头到尾梳理 PDU Session Establishment 流程——UE 如何发起会话请求、AMF 如何选择 SMF、SMF 如何获取签约与策略信息、UPF 如何配置，以及 N3 隧道最终如何建立完成。
UE 完成 5GS Registration 后，AMF 已经保存了用户标识、移动性、安全以及相关签约上下文。然而，注册成功并不意味着用户面路径已经存在。UE 此时可能仍然没有到 Internet 或企业数据网络的有效路径。
PDU Session Establishment 使 UE 从“已注册”进入“能够承载应用流量”的状态。UE 发起会话请求，网络选择 SMF 与 UPF，获取与 DNN 和 S-NSSAI 相关的签约数据，取得会话策略，在 UPF 中安装 PFCP 规则，并与 gNB 协同建立 N3 隧道。流程结束时，UE 将获得 IP 地址、QoS 规则以及通往 Data Network 的用户面路径。
如果不把它理解成一条孤立的 NAS 消息，这个流程会更容易理解。实际上有三件事情在同时发生：会话管理、策略控制以及用户面资源配置，最终共同形成一个可用的 PDU Session。
PDU 会话与 5GS 注册之间的功能边界
在 5GC 中，Registration 与 PDU Session 的分工很清晰：前者建立网络注册关系，后者建立数据连接。
Registration 决定 UE 是否能够进入 5GS。AMF 验证 UE 身份、执行认证、建立 NAS 安全、获取与移动性相关的签约数据，并创建 RM（Registration Management）与 CM（Connection Management）所需的上下文。完成这些步骤后，UE 与核心网之间的管理关系即建立。
PDU Session 则与实际数据业务直接相关。如果 UE 需要访问 Internet、建立 IMS 连接或接入企业专网，仅完成 Registration 还不够。网络还需要确定使用哪个 DNN、采用哪个 S-NSSAI、由哪个 SMF 控制会话、由哪个 UPF 承载用户面，以及允许的 QoS 和带宽参数。
与 EPC 对比可以更容易记住这种区别。LTE 使用 PDN Connection 和 EPS Bearer 的概念；在 5GC 中，这一模型被 PDU Session + QoS Flow 取代。PDU Session 建立后，网络创建的是 QoS 规则和 QoS Flow 资源，而不是 LTE 形式的 Default EPS Bearer。
另一个重要点是，PDU Session 不一定必须与初始 Registration 同时建立。UE 可以先完成 Registration，在应用真正需要数据业务之前都不建立 PDU Session。例如，设备开机时完成注册，但可能直到半小时后用户打开视频应用时才创建 PDU Session。
这一区别对信令跟踪分析非常有用。如果 Registration 已成功完成，但 PDU Session Establishment 没有完成，反复检查 5G-AKA、Registration Accept 或 T3512 通常无法解决数据业务问题，因为排查方向已经落在了错误的流程上。
PDU 会话请求中的 DNN、S-NSSAI 与请求类型
PDU Session Establishment 由 UE 发送的一条 NAS 消息开始。PDU Session Establishment Request 不只是简单告诉核心网“我需要数据接入”。请求中携带的信息元素会影响后续的 NF 选择与会话配置。
一个典型的初始请求可能包含 PDU Session ID、Request Type、PDU Session Type、SSC Mode、DNN 和 S-NSSAI。
PDU Session ID 用于区分同一 UE 所属的多个会话。一个 UE 可以同时保持多个 PDU Session，例如一个用于 Internet 接入，另一个用于企业专网。SUPI 用于标识用户，但仅凭 SUPI 并不能确定当前正在处理的是哪一个具体的 PDU Session。
DNN 用于标识 UE 希望访问的 Data Network。运营商 Internet 接入、IMS 与企业网络可能使用不同的 DNN。DNN 还会参与后续流程中的 SMF 选择、UPF 选择以及策略决策。
S-NSSAI 将会话关联到特定的 Network Slice。AMF 与 SMF 需要确认所请求的切片是否与用户签约、所请求 DNN 以及已部署网络能力相匹配。
Request Type 用于标识本次请求的场景。除了新建 PDU Session，该流程还可能与现有会话、接入变化或紧急业务场景有关。因此在信令分析时，不能看到 PDU Session Establishment Request 就默认每次都是同一种场景。
最常见的是 Initial Request：UE 已完成 Registration，现在为指定 DNN 创建一个新的 PDU Session。SMF 选择、UDM 签约数据获取、PCF 策略控制以及 UPF 资源建立，都会围绕这一会话上下文展开。
AMF 的 SMF 选择与 SM Context 创建
UE 的 NAS 会话管理消息首先到达 gNB，随后通过 NGAP 连同 NR-CGI、TAI 等接入相关信息一起转发给 AMF。gNB 不负责做 PDU Session 控制决策，它的作用是把 NAS 信息传送到核心网。
AMF 收到请求后，需要找到能够为所请求 S-NSSAI 与 DNN 提供服务的 SMF。
在基于服务的 5GC 架构中，AMF 可以通过 NRF 进行 NF 发现。发现条件可能包括目标 NF 类型、所需的 Nsmf_PDUSession 服务、S-NSSAI、DNN 和服务 PLMN。NRF 返回候选 SMF 实例后，AMF 再根据网络策略选择实际提供服务的 SMF。
随后，AMF 调用 SMF 的 PDU Session 服务创建一个 SM Context。除了 SUPI、PDU Session ID、DNN 与 S-NSSAI，请求中还会以 N1 SM information 的形式携带 UE 原始的 PDU Session Establishment Request。
从这一点开始，会话控制的核心从 AMF 转移到 SMF。AMF 继续负责接入与移动性管理，也继续在 UE 和 SMF 之间转发 N1 SM 信令；但如何创建 PDU Session、选择哪个 UPF、应用哪些策略以及如何配置用户面规则，都由 SMF 负责决定。
排障时有一个实际问题很重要：商用网络中看到的 NRF 事务数量不一定与参考信令图完全一致。NF 发现结果可能被缓存，也可能采用静态配置，或者由 SCP 提供服务路由。更重要的问题不是跟踪中是否出现某一条特定 NRF 查询，而是最终选中的 SMF 是否真正支持所需 DNN、S-NSSAI 与服务能力。
UDM 签约数据与 PCF 会话策略处理
SMF 明确 UE 请求的会话类型后，仍不能立即创建用户面。它首先需要确定该用户实际被授权建立怎样的 PDU Session。
在典型流程中，SMF 找到合适的 UDM，将自身注册为为该 SUPI 和 PDU Session 提供服务的 SMF，并获取与所请求 S-NSSAI 与 DNN 相关的 Session Management Subscription Data。
签约数据可能包含允许的 PDU Session Type、SSC Mode、Session-AMBR 以及默认 QoS 相关设置。这些值定义该会话在用户签约层面的边界。例如，如果 UE 请求 IPv4 PDU Session，SMF 仍需确认该 DNN 是否允许这种 PDU Session Type，以及请求的 SSC Mode 是否被允许。
SMF 还可以订阅 SM 签约数据的变化。如果 UDM 中相关会话管理签约数据之后被修改，UDM 可以通过已注册的 Callback URI 通知当前服务 SMF。
如果部署采用动态 SM Policy Control，SMF 会选择 PCF 并建立 SM Policy Association。SMF 提供 SUPI、PDU Session ID、DNN、S-NSSAI、UE 位置以及签约 QoS 参数等上下文。随后 PCF 返回已授权的会话策略，其中可能包括 Session-AMBR、默认 QoS 以及其他适用策略规则。
这一阶段可以理解为会话参数的汇合过程：
UE 业务请求 → UDM 签约限制 → PCF 策略授权 → SMF 最终确定会话控制参数
后续安装到 UPF 中的 QoS 与转发规则，都以这些结果为依据。
N4 会话建立与 UPF 用户面规则下发
会话参数确定后，SMF 选择一个能够为所请求 DNN、S-NSSAI 和 UE 位置提供服务的 UPF，然后通过 N4 接口建立 PFCP Session。
PFCP Session Establishment Request 是 PDU Session Establishment 流程中最关键的节点之一。在此之前，网络处理的主要还是抽象的业务需求；到了 N4，这些需求会被转换成 UPF 可对实际用户数据包执行的规则。
SMF 可以在 UPF 中下发 PDR、FAR、QER 和 URR 规则：
PDR：告诉 UPF 如何识别属于该 PDU Session 或某一特定业务流的数据包；
FAR：定义匹配数据包应执行的动作，例如转发、丢弃、缓存或其他适用操作；
QER：在 UPF 中实施所需的 QoS 控制；
URR：定义用户面用量统计与上报要求。
这些规则不应被看成四个彼此无关的功能。它们共同定义 UPF 如何处理流量。PDR 负责识别数据包流，并引用相应的 FAR、QER 和 URR，使 UPF 知道数据包应该发往哪里、应用哪些 QoS 控制以及是否需要统计用量。
当 UPF 接受 PFCP Session Establishment 后，会返回自身的 F-SEID 以及已创建的用户面参数。其中最重要的结果之一，就是用于 N3 的 UPF 侧用户面地址和 TEID。
但此时下行路径可能仍未完整，因为 gNB 尚未完成其 N3 资源分配。因此，PDU Session Establishment 并不会在一次 PFCP 请求后就结束，流程还需要等待 RAN 完成其用户面侧的配置。
N1/N2 信令完成 N3 隧道与 QoS Flow 建立
UPF 侧资源准备完成后，SMF 需要通过 AMF 返回两类不同的信息。
第一类是 N1 SM information，最终发送给 UE。其中包含 PDU Session Establishment Accept，以及会话建立后 UE 所需的参数，例如 PDU Session Type、SSC Mode、DNN、S-NSSAI、UE IP 地址、Session-AMBR 和默认 QoS Rule。
第二类是 N2 SM information，目标是 gNB。它告诉 RAN 正在建立哪个 PDU Session、涉及哪些 QoS Flow，以及 N3 应使用哪个 UPF IP 地址与 TEID。
AMF 通过 NGAP 向 gNB 发送 PDU Session Resource Setup Request。gNB 分配所需的无线与 N3 资源，并把 PDU Session Establishment Accept 转发给 UE。
资源建立完成后，gNB 返回 PDU Session Resource Setup Response，其中携带自身的 N3 用户面地址和 TEID，以及成功建立的 QoS Flow 信息。
这里有一个关键的时序细节。SMF 最初建立 PFCP Session 时，已经知道 UPF 侧 N3 信息，但可能还不知道最终的 gNB 侧隧道信息。gNB 返回其 N3 地址与 TEID 后，AMF 将这些信息转发给 SMF。随后 SMF 使用 PFCP Session Modification 更新 UPF 中相关 FAR，使下行数据包能够封装到正确的、指向 gNB 的 GTP-U 隧道中。
到这一步，上行与下行用户面路径才真正完整：
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
因此，仅收到 PDU Session Establishment Accept 并不能证明所有用户面要素都正确。还需要结合实际数据包转发，验证 N3 隧道参数、PFCP Session Modification 以及最终的 UPF 规则。
PDU 会话建立的信令排障
PDU Session Establishment 涉及多个网络功能。如果从第一个数据包开始逐条对比全部消息，排障很快会变得混乱。更高效的方法是把流程划分为几个检查点，逐步缩小故障域。
确认会话请求正确到达 AMF
首先确认 UE 已完成所需的 5GS Registration。随后检查 PDU Session Establishment Request，确认 PDU Session ID、Request Type、DNN、S-NSSAI、PDU Session Type 和 SSC Mode 是否合理。如果请求在入口处就携带了无效参数，即使 SMF 与 UPF 状态正常，也无法建立预期会话。
确认 SMF 创建有效的 SM Context
接下来确认 AMF 选择了合适的 SMF，并且 Create SM Context 成功。目标不只是在线路跟踪中找到一条 NRF 消息，而是确认所选 SMF 支持所需的 DNN、S-NSSAI 和服务能力。
然后确认 UDM 返回的 SM 签约数据允许所请求的 PDU Session，并且 PCF 策略与预期 QoS 配置一致。
确认 UPF 与 N3 资源完整
如果控制面已经返回 PDU Session Establishment Accept，但 UE 仍然无法传输数据，排查重点应下沉到 N4 与 N3。
按以下顺序检查：
PFCP Session Establishment 是否成功，以及 UPF 是否创建了对应会话；
PDR、FAR、QER 等规则是否与预期流量方向一致；
gNB 是否成功返回其 N3 用户面 IP 地址与 TEID；
SMF 是否通过 PFCP Session Modification 将 gNB 隧道信息更新到 UPF；
N3 上是否实际出现了使用预期 TEID 的 GTP-U 数据包；
UPF 是否能够通过 N6 成功向目标 Data Network 发送和接收流量。
按照这一顺序排查，可以把问题逐步缩小到 NAS、SBI、N4、N3 或 UPF 数据包转发，而不是把整个 5GC 当作一个无法区分的故障域。
常见问题
为什么 UE 已完成 5G 注册仍然无法访问 Internet？
Registration 建立 UE 与 5GC 之间的接入、身份、安全和移动性上下文，但不会自动创建用户数据路径。在 UE 能够访问 Internet 或其他 Data Network 之前，仍需要建立 PDU Session，使 SMF 能够配置会话参数、UPF 资源以及 N3 用户面。
UE 开机时一定会建立 PDU Session 吗？
不一定。PDU Session 可以在 Registration 前后建立，也可以等到 UE 真正需要数据业务时再发起。5GS 允许 UE 在没有活动 PDU Session 的情况下保持已注册状态，因此不能把 Registration 完成与 PDU Session Establishment 当成同一个事件。
PDU Session Establishment 成功是否意味着 UE 一定能访问 Internet？
不一定。仅在 NAS 层收到 PDU Session Establishment Accept，并不足以证明数据连接已经成功。实际用户流量还依赖 gNB 与 UPF 之间的 N3 隧道、UPF 内的 PDR/FAR/QER 规则、N6 连接以及目标 Data Network。即使 UE 已获得 IP 地址，用户面转发仍然可能存在错误。
为什么 PFCP Session Establishment 之后还会发生 PFCP Session Modification？
在 UPF 中首次创建 PFCP Session 时，gNB 可能尚未完成 N3 资源分配，因此 SMF 可能还不知道最终的 gNB 用户面 IP 地址与 TEID。gNB 在 PDU Session Resource Setup Response 中返回这些值后，SMF 通过 PFCP Session Modification 更新 UPF 中相应规则，使下行流量能够经正确的 N3 GTP-U 隧道发送。
PDU Session 中的 QFI 与 N4 接口上的 QER 是同一个概念吗？
不是。QFI 用于标识 5GS 中的 QoS Flow，而 QER 是 SMF 通过 N4 配置到 UPF 的 QoS Enforcement Rule。QER 参与 QoS 执行，并可在适用场景下与 QFI 关联，但 QFI 本身不是 QER，两者不能互换理解。
