该UE属于哪个签约用户？
是否允许该UE接入当前网络？
是否存在仍可复用的历史移动性上下文？
该UE签约了哪些网络切片和接入能力，应由哪个AMF为其提供服务？
5G设备开机后，在建立用户数据业务之前，核心网必须先回答这些基本问题。这些工作在5G初始注册过程中完成。从信令跟踪角度看，该过程远不只是简单的“发送注册请求，然后注册成功”。从UE发送Registration Request到最终返回Registration Complete之间，网络可能要执行身份处理、旧AMF上下文获取、5G-AKA鉴权、NAS安全建立、UDM注册、签约数据获取以及接入策略处理等步骤。
学习这一流程时，一个常见误区是试图按顺序死记每一条消息。更实用的方法是分析AMF在每个阶段要解决什么问题。完整信令路径可以理解为：识别发起请求的UE，建立可信身份，补全所需的用户上下文，最后才完成注册。
初始注册确立UE接入网络的资格
5GS中的注册并不是单一流程。根据触发原因，UE可能执行Initial Registration、Mobility Registration Update、Periodic Registration Update或Emergency Registration。UE通过Registration Request中的5GS registration type字段指明当前适用的注册流程。
Initial Registration通常发生在UE开机并进入5GS时。为了便于理解，它经常与LTE/EPC的Attach流程进行对比，但两者不能视为完全相同。在5G核心网的服务化架构中，移动性管理、鉴权、签约数据和策略控制分布在AMF、AUSF、UDM、PCF等不同网络功能中。因此，一次注册流程可能包含多个网络功能之间的服务化交互。
更重要的是，Initial Registration主要建立接入与移动性管理状态，而不是建立用户数据会话。网络必须识别UE、建立移动性上下文、确定允许的NSSAI及适用的区域限制，并建立后续信令所需的安全关系。只有这些条件具备后，UE才具备发起PDU Session请求的基础。
因此，收到Registration Accept并不自动意味着用户已经能够访问互联网。注册与PDU Session建立是5G核心网中的两个独立阶段。
Registration Request将UE带入5G核心网注册流程
核心网注册流程从NAS Registration Request开始。UE首先通过无线接口向gNB发送NAS消息，随后gNB通过NGAP Initial UE Message将NAS-PDU送往AMF。对于核心网工程师而言，这条消息就是整个注册流程进入核心网的入口。
除了携带Registration Request外，Initial UE Message还向AMF提供NR-CGI、TAI等接入位置信息。NAS消息本身还可能包含5GS registration type、5GS mobile identity、UE Security Capability和Requested NSSAI等参数。
这些参数并不只是简单的UE能力列表。AMF会利用它们判断注册应如何继续。Registration Type用于确认UE执行的是Initial Registration还是其他注册更新；移动身份用于判断能否将已有用户上下文与该UE关联；Requested NSSAI表示UE请求使用的网络切片；UE Security Capability则为后续NAS安全算法选择提供依据。
有一个细节很容易被误解：执行Initial Registration的UE并不一定完全没有历史5G信息。如果UE仍保存之前分配的5G-GUTI，它可以在新的Initial Registration Request中携带该身份。网络能否复用与该身份关联的信息，会直接影响后续流程。
新AMF解析身份并获取历史UE上下文
假设某UE此前已在广州的5GS完成注册，随后关机并移动到北京，再通过北京的gNB重新开机接入。此时UE由新的AMF服务，但仍可能保留之前由广州AMF分配的5G-GUTI。
5G-GUTI中的GUAMI可以提供有助于识别旧AMF的信息。如果新AMF判断旧网络功能仍可能保存有用的UE上下文，它可以通过AMF间通信发起UE Context Transfer，并获取SUPI、GPSI、PEI以及部分移动性管理上下文等信息。
这说明一个重要问题：“Initial”描述的是当前这一次注册流程的类型，并不表示该用户第一次进入5G网络。UE仍可能保存此前分配的5G身份，新AMF也可能复用旧AMF中的上下文。
并非每次Initial Registration都需要与旧AMF交互。如果新AMF已经具备所需的身份信息，或者没有可用的历史UE上下文，信令路径就可能不同。如果AMF仍需要UE的SUCI，可以发送Identity Request，由UE通过Identity Response返回所请求的身份。
因此，在抓包中没有看到Identity Request或UE Context Transfer，并不能单独作为注册失败的依据。首先应确认AMF当前已经掌握了哪些身份和上下文信息。
5G-AKA将申报身份验证为可信用户身份
仅知道UE声称自己是谁，还不足以让网络信任该身份。因此，流程会进入最重要的安全阶段之一：鉴权。
AMF必须找到能够对该用户执行鉴权的AUSF。在服务化5G核心网中，这通常涉及通过NRF进行网络功能发现。AMF根据所需服务和用户相关信息选择合适的AUSF实例，并发送鉴权请求。
随后AUSF与归属网UDM相关的鉴权功能协同工作。使用SUCI时，归属网可以恢复对应的SUPI，并准备5G-AKA所需的鉴权数据。之后AMF通过NAS Authentication Request向UE下发RAND、AUTN等参数。UE使用USIM中保存的凭据执行鉴权计算，并通过Authentication Response返回包含RES*的结果。
鉴权并不是由某一个网络功能完成一次简单比对。服务网络侧和归属网侧分别进行相应校验。AMF根据UE返回的响应计算HRES*并与HXRES*比较，AUSF则将返回的RES*与预期XRES*进行验证。只有所需验证全部成功后，网络才会将该用户身份视为已经通过鉴权。
鉴权完成后，网络通常会建立或更新NAS Security Context。AMF依据UE Security Capability等信息选择合适的完整性保护和加密算法，并通过Security Mode流程保护后续关键NAS信令。
从工程角度看，这一阶段形成了一条清晰的安全边界：鉴权之前，网络处理的是一台正在请求接入的设备；鉴权和NAS安全成功建立后，AMF拥有了可信且受保护的UE控制面上下文。
签约数据与策略数据补全UE上下文
鉴权成功回答了“用户身份是否真实”这一问题，但AMF还必须知道该用户在当前网络中究竟被允许做什么。下一阶段就是把已经通过鉴权的身份进一步补全为可用于接入和移动性管理的上下文。
AMF选择合适的UDM，并通过3GPP接入将自己登记为当前为该SUPI提供服务的AMF。这一步很重要，因为UDM需要知道后续与该用户有关的移动性通知、注销事件或签约数据变化应发送给哪个AMF。
随后AMF获取Access and Mobility Subscription Data。根据用户签约配置，其中可能包括Subscribed NSSAI、UE-AMBR、周期性注册参数、RAT限制和区域限制。鉴权确认的是身份有效性，而签约数据回答的是另一个问题：这个已经确认有效的用户，在当前网络中被允许做什么？
AMF还可能获取后续用于SMF选择的签约数据，包括与S-NSSAI、DNN以及默认DNN相关的信息。阅读信令跟踪时，这一点经常引起困惑：如果注册阶段已经出现SMF Selection Subscription Data，是否说明SMF已经参与当前流程？
不一定。此时AMF只是获取未来选择SMF时可能需要的信息。Initial Registration并不要求同时建立PDU Session，因此AMF可以在不创建SM Context、也不启动实际SMF会话管理流程的情况下获取这些签约数据。
在接入策略方面，AMF还可以选择PCF并建立AM Policy Association。PCF返回的策略可能影响特定区域的接入限制等事项。到这一阶段，AMF中保存的UE上下文已经从基本身份信息扩展为身份、安全、签约、切片、位置和策略信息的组合。
Registration Accept将注册结果应用到UE和gNB
前面的多数处理都发生在核心网内部，但最终结果仍必须下发到接入网和UE。当所需条件全部满足后，AMF向gNB发送Initial Context Setup Request，携带建立UE上下文所需的信息，并将NAS Registration Accept传递给UE。
Registration Accept可以包含新分配的5G-GUTI、Allowed NSSAI、周期性注册定时器T3512以及适用的Tracking Area列表等信息。这些参数决定UE如何保持在5GS中的注册状态、当前可以使用哪些切片，以及之后何时需要执行Periodic Registration Update。
与此同时，gNB通过Initial Context Setup流程建立相应的UE上下文。完成处理后，gNB返回Initial Context Setup Response。随后UE通过向AMF发送NAS Registration Complete确认注册结果。
因此，Registration Accept和Registration Complete并不只是简单的成功通知。它们把核心网内部形成的注册结果真正应用到UE和RAN，使网络、gNB与终端进入一致的5GS注册状态。
注册与PDU Session建立属于不同的信令路径
分析完整信令序列时，必须明确这一区别。5GS Initial Registration完成后，AMF已经知道用户是谁、UE位于哪里、允许使用哪些接入区域和切片，以及适用的安全与移动性上下文。但这些步骤都不会自动建立用户面数据路径。
UE若要访问互联网或企业数据网络，仍需执行PDU Session Establishment。此时SMF负责会话管理，选择或控制UPF，并通过N4下发PDR、FAR、QER、URR等用户面规则。gNB与UPF之间的N3资源也会在会话建立过程中准备。
在实际故障排查中，这会形成两类完全不同的问题：
注册失败：重点检查UE身份、鉴权、NAS安全、UDM签约数据、NSSAI、区域限制以及AMF策略处理。
注册成功但数据业务不可用：应把排查方向转向PDU Session建立、SMF、UPF、N3/N4信令和用户面转发，而不是反复检查Registration Request与Registration Accept。
明确这条边界可以显著缩短5GC故障定位时间。设备显示5G标识，只能说明无线接入和注册已达到某个状态；实际数据连接是否建立，仍取决于会话管理和用户面流程。
把抓包当作状态迁移来读，而不是消息清单
标准信令流程图通常设计得很完整，因为需要覆盖不同运营商、漫游场景、接入类型以及可选网络功能。但真实网络抓包并不一定包含参考流程中的每一步：可能没有旧AMF交互，可能不需要Identity Request，也可能没有使用EIR；正常的NR接入流程也不会包含只适用于其他接入类型的网络功能。
排查Initial Registration时，更有效的方法是跟踪UE状态如何逐步变化：
Registration Request到达AMF
→ 解析UE身份和历史上下文
→ 建立鉴权和NAS安全
→ 从UDM获取签约数据
→ 从PCF获取适用的接入策略
→ AMF完成注册上下文
→ 下发Registration Accept
→ UE返回Registration Complete
如果Registration Request已经到达AMF但鉴权始终没有开始，应优先检查身份处理和网络功能选择。如果鉴权成功但没有返回Registration Accept，则继续检查UDM数据、NSSAI、接入限制和策略处理。如果Registration Accept已经完成，而问题是用户数据不可用，则应迅速把排查方向转向PDU Session信令路径。
因此，理解5G Initial Registration的重点并不是背下几十条消息，而是跟踪AMF中的UE上下文如何一步步变完整：从收到接入请求，到知道用户是谁，再到证明该身份可信，最后明确该用户以什么条件被允许保持在5GS注册状态。
常见问题
Registration Accept中的T3512有什么作用？
T3512控制UE注册后的周期性注册更新行为。UE不会在没有周期性移动性管理交互的情况下无限期保持注册。网络可以通过该定时器规定UE何时执行Periodic Registration Update。
为什么一些商用5G注册抓包中看不到EIR？
设备身份检查是可选功能。是否部署EIR，以及在什么条件下触发设备身份检查，取决于运营商的架构和运维策略。因此，在其他步骤均正常的Initial Registration流程中没有EIR信令，并不足以说明存在故障。
为什么标准5G NR注册流程中通常没有N3IWF？
N3IWF主要用于不可信的non-3GPP接入，例如某些通过Wi-Fi接入5G核心网的场景。当UE通过标准3GPP NR接入直接连接gNB时，接入路径由NG-RAN提供，因此N3IWF通常不会出现在注册信令中。
为什么不同厂商抓包中的NRF网络功能发现次数可能不同？
实际5G核心网实现会因NF发现缓存、静态配置、SCP部署模式以及厂商特定的服务路由行为而不同。因此，不必在每一次服务操作之前都看到完整的NRF网络功能发现交互。分析抓包时，应把已选择的NF实例与后续服务请求进行关联，而不能只根据NRF消息数量判断流程是否正确。
