# 5G初始注册（Initial Registration）全信令流拆解：从InitialUEMessage到Registration Accept的32步精解 ## 一、为什么初始注册是5G协议栈的"零号流程" 5G系统（5GS）中，用户设备（UE）要获得任何服务，必须先完成**注册（Registration）**。与4G EPS的Attach相比，5G注册流程在协议层面有一个根本性的升级：它不再是"接入+鉴权"两条线的简单拼接，而是把**网络切片选择（NSSAI协商）**、**订阅数据获取（UDM/SBI）**、**AMF重选（AMF Re-allocation）**、**AM策略关联（PCF）**和**初始上下文建立（NGAP InitialContextSetup）**全部串进同一条控制路径里。 初始注册对应 **3GPP TS 23.502 Section 4.2.2.2.2（General Registration procedure）**，是protocols子域最复杂、信令消息最多的一条流程——规范中它有 **32个左右的标号步骤**，涉及NAS（TS 24.501）、NGAP（TS 38.413）、SBI服务接口（TS 29.518/29.503/29.507）三个协议域的协同。 本文聚焦这条完整信令链，重点拆解三个协议开发中最容易踩坑的机制： 1. **NGAP InitialUEMessage 如何承载NAS Registration Request**，以及RAN如何选AMF； 2. **AMF Re-allocation（Reroute NAS Request）的触发条件与切片重选逻辑**； 3. **Registration Accept 中 5G-GUTI / Allowed NSSAI / TAI List / Configured NSSAI 四件套的下发**。 --- ## 二、整体信令时序：32步全链路 下图是初始注册的完整消息序列，严格对应 TS 23.502 4.2.2.2.2 的步骤编号： ```mermaid sequenceDiagram participant UE participant RAN as (R)AN/gNB participant AMF as Initial AMF participant OldAMF as Old AMF participant AUSF participant UDM participant PCF participant EIR Note over UE,RAN: 步骤1: RRC连接建立 UE->>RAN: RRC SetupComplete (携带NAS Reg Request) Note over UE,RAN: 步骤2: NGAP InitialUEMessage RAN->>AMF: N2 InitialUEMessage(N1 Reg Request, SUPI/SUCI, Requested NSSAI) Note over AMF,OldAMF: 步骤3-4: 旧上下文获取(若有5G-GUTI) AMF->>OldAMF: Namf_Communication_UEContextTransfer(5G-GUTI, Access Type) OldAMF-->>AMF: Response(SUPI, UE上下文, 安全上下文) Note over AMF,UDM: 步骤6: SUCI去隐藏(SIDF驻留UDM) AMF->>UDM: Nudm_UEAuthentication_Get(SUCI) / Nudm_SDM_Get UDM-->>AMF: SUPI Note over AMF,AUSF: 步骤9-13: 主认证5G AKA/EAP-AKA' AMF->>AUSF: Nausf_UEAuthentication Authenticate(SUPI/SUCI, SNN) AUSF->>UDM: Nudm_UEAuthentication_Get UDM-->>AUSF: Authentication Vector AUSF-->>AMF: 5G AKA AV AMF->>UE: Authentication Request(RAND, AUTN) UE-->>AMF: Authentication Response(RES*) AMF->>AUSF: Nausf_UEAuthentication Confirm(RES*) AUSF-->>AMF: Success + Kseaf Note over UE,AMF: 步骤13a: NAS安全模式控制SMC AMF->>UE: Security Mode Command UE-->>AMF: Security Mode Complete Note over AMF,UDM: 步骤14-20: 注册服务AMF+订阅数据 AMF->>UDM: Nudm_UECM_Registration(SUPI, GUAMI, Access Type) UDM-->>AMF: Response UDM->>OldAMF: Nudm_UECM_DeregistrationNotification AMF->>UDM: Nudm_SDM_Get(SUPI) UDM-->>AMF: Access&Mobility/SM/SMF选择订阅数据 AMF->>UDM: Nudm_SDM_Subscribe(订阅数据变更通知) Note over UE,AMF: 步骤21-22: PEI获取与设备检查 AMF->>UE: Identity Request(SUCI to PEI) UE-->>AMF: Identity Response(PEI) AMF->>EIR: N5g-eir_EquipmentIdentityCheck(PEI) Note over AMF,PCF: 步骤27: AM策略关联 AMF->>PCF: Npcf_AMPolicyControl_Create(SUPI, SUPI Range, UE位置) PCF-->>AMF: AM策略(服务区限制, RFSP, NRF ID) Note over AMF,UE: 步骤31-32: 接受注册 AMF->>RAN: N2 InitialContextSetup(N1 Reg Accept, 5G-GUTI, Allowed NSSAI, TAI List, N3 config) RAN->>UE: RRC Reconfiguration + NAS Registration Accept UE-->>RAN: RRC Reconfiguration Complete RAN-->>AMF: N2 InitialContextSetupResponse UE->>AMF: Registration Complete(NAS) ``` --- ## 三、第一阶段：NAS Registration Request 的IE解剖 Registration Request 是 UE 发出的**第一条NAS（5GMM）消息**，定义在 **TS 24.501 Section 8.2.7**。它最大的特点是**未受安全保护**——因为此时安全上下文尚未建立，所以凡是敏感字段（如完整SUPI）一律不在该消息里明文携带。 ### 关键IE清单 | IE名称 | 是否必选 | 含义 | 设计意图 | |--------|---------|------|---------| | Extended protocol discriminator | M | 固定值 `7E`(5GS Mobility Management) | 区分5GMM/5GSM/会话管理 | | Security header type | M | `0000`(明文) | 此时无安全上下文，必须明文 | | 5GS Registration type | M | initial/mobility/periodic/emergency | 决定AMF走哪条子流程 | | Mobile identity | M | 5G-GUTI 或 SUCI（优先GUTI） | 优先用临时身份隐藏永久身份 | | NgKSI | M | 密钥集标识（来自旧安全上下文） | 用于派生新安全上下文 | | 5GS tracking area identity | M | 上次注册的TAI | 网络判断是否跨注册区移动 | | Requested NSSAI | O | UE想用的切片 | 触发切片选择 | | UE security capability | O | 支持的NAS算法 | SMC前协商算法 | | UE usage setting | O | `0`=非ARP优先、`1`=优先语音/数据 | 影响AMF对Voice-centric的处理 | | S1 UE network capability | O | EPS能力回退信息 | 支持EPS Fallback | | Update type | C | 用于初始注册附加信息 | 携带SMS over NAS协商 | ```mermaid flowchart TB A[Registration Request NAS消息] --> B1[明文头部
EPD + Security Header=0000] A --> B2[5GS Registration Type
决定流程分支] A --> B3[Mobile Identity] B3 --> C1{有有效5G-GUTI?} C1 -->|是| D1[带5G-GUTI
可被Old AMF识别] C1 -->|否| D2[带SUCI
SUPI经公钥加密] A --> B4[NgKSI
旧安全上下文标识] A --> B5[Requested NSSAI
触发切片选择] A --> B6[UE Security Capability
SMC算法协商] style D2 fill:#ffe4e1 style C1 fill:#e6f3ff ``` **设计意图深度解读**：Mobile Identity 字段的优先级是协议安全的精髓。UE**优先**使用5G-GUTI（临时身份），只有当没有有效GUTI时才用SUCI（SUPI经运营商公钥加密后的隐藏身份）。这条优先规则配合SUCI机制，把"明文SUPI空口暴露"这个2G/3G/4G时代的老问题彻底关上——这正是"5G AKA认证"和"SUCI隐私保护"两大机制的衔接点。 --- ## 四、第二阶段：NGAP InitialUEMessage 与 RAN选AMF RRC建立完成后，gNB通过 **N2接口（NG-AP）** 把NAS消息转发给核心网，这条消息叫 **InitialUEMessage**，定义在 **TS 38.413 Section 8.3.1**。 gNB不能随便选一个AMF，选AMF的依据在 **TS 23.501 Section 6.3.6（AMF selection）**： 1. **优先按5G-GUTI中的GUAMI** 找到上次服务该UE的AMF Set； 2. 若没有GUTI，则按 **SUPI/SUCI中的Routing Indicator**（路由指示符，IMSI里的字段）路由； 3. 同时要匹配UE请求的 **S-NSSAI（切片）** 和 **PLMN ID**。 InitialUEMessage的关键NGAP IE： | NGAP IE | 作用 | |---------|------| | RAN UE NGAP ID | gNB本地标识，后续N2信令都用它 | | NAS-PDU | 透明承载上层的NAS Registration Request | | User Location Information | NR-CGI/TAI，AMF需知UE在哪 | | RRC Establishment Cause | `mo-Signalling` 等，用于过载优先级 | | UE Context Request | UE是否请求建立上下文（"initial"标志）| | Allowed NSSAI | 当AMF Set内多个AMF时辅助RAN重路由 | **注意**：InitialUEMessage中的 `UE Context Request` IE是个关键开关。初始注册时它通常置"present"，指示网络后续要走InitialContextSetup；若UE只做周期性更新且无数据，可置absent，AMF则跳过上下文建立直接回Registration Accept——这是协议优化空口开销的一个细节。 --- ## 五、第三阶段：AMF Re-allocation —— 切片驱动的重路由 这是初始注册里**最容易出问题、也是协议设计最精巧**的环节。当RAN选的Initial AMF发现自己**无法服务UE请求的切片**（比如该AMF所在的AMF Set不支持UE的Requested NSSAI中的某个S-NSSAI），就要触发AMF重选。对应 **TS 23.502 4.2.2.2.3（AMF Re-allocation）** 和 NGAP的 **RerouteNASRequest**（TS 38.413 Section 8.28）。 AMF重选有两条路径，触发条件与流程不同： ### 路径A：经RAN重路由（Reroute NAS Request） ```mermaid sequenceDiagram participant RAN participant IAMF as Initial AMF
(不能服务切片) participant NRF participant TAMF as Target AMF RAN->>IAMF: InitialUEMessage(NAS Reg, Requested NSSAI) Note over IAMF: 查询发现不支持Requested NSSAI IAMF->>NRF: Nnrf_NFDiscovery(查询支持该S-NSSAI的AMF Set) NRF-->>IAMF: Target AMF Set信息 IAMF->>RAN: RerouteNASRequest(原始NAS-PDU,
Allowed NSSAI/GUAMI, AMF Set ID) Note over RAN: 根据Allowed NSSAI重新路由 RAN->>TAMF: InitialUEMessage(同一NAS-PDU, 新Routing) Note over TAMF: Target AMF接管注册流程 ``` ### 路径B：直接经N14转发（Initial AMF已完成部分处理） 如果Initial AMF已经做了部分处理（如已调用UDM去隐藏SUCI拿到SUPI），它会通过 **Namf_Communication_RegistrationCompleteTransfer 或 N14接口的 Namf_Communication_UEContextTransfer** 直接把UE上下文转发给Target AMF，不走RAN。 **设计意图**：协议允许两条路径，是为了在"切片灵活性"和"信令效率"间取平衡。Reroute路径（A）由RAN做最终路由决策，符合NG-RAN无状态转发原则；N14路径（B）则避免了NAS消息在空口再走一次RRC——这对减少空口开销和UE不可见的中断很重要。 **实战排错**：如果抓包看到同一条Registration Request被两个AMF先后收到，且中间夹了RerouteNASRequest——这是正常的AMF重选，不是信令风暴。真正的故障点是：为什么RAN一开始选错了AMF？通常是 **gNB上的AMF Set切片映射表（TS 23.501 5.15）配置错误**，或UE的Requested NSSAI与签约不匹配。 --- ## 六、第四阶段：UDM订阅数据获取（SBI服务三连） 认证和NAS安全激活完成后，AMF正式把自己注册为该UE的"服务AMF"，并拉取订阅数据。这一段是5G相对4G的又一升级——HSS的单一接口被拆成UDM的多个SBI微服务。对应 **TS 29.503（Nudm服务）**。 AMF在注册阶段对UDM的三个关键调用： | SBI操作 | TS 29.503章节 | 作用 | 幂等性 | |---------|--------------|------|--------| | `Nudm_UECM_Registration` | 5.3.2 | 把"我（AMF）正在服务这个UE"写进UDM | 幂等，重复注册会更新GUAMI | | `Nudm_SDM_Get` | 5.2.2 | 拉取Access&Mobility、SM、SMF选择三类订阅数据 | 读取，幂等 | | `Nudm_SDM_Subscribe` | 5.2.3 | 订阅数据变更通知（如套餐变更、切片调整） | 建立长连接通知 | `Nudm_SDM_Get` 拉回的核心数据集包括： - **Access and Mobility Subscription Data**： subscribed NSSAI、默认NSSAI、是否允许漫游、签约的TA范围、SMS支持标志； - **Session Management Subscription Data**：每个DNN+S-NSSAI的5QI、ARP、Session-AMBR； - **SMF Selection Subscription Data**：DNN→SMF映射、SSC模式默认值。 **为什么拆成三个服务**：这是SBI架构（TS 23.501 4.x）的设计哲学——把HSS单体拆成无状态服务，UDM只管逻辑（读/写），实际数据存在 **UDR（Unified Data Repository）**，UDM通过Nudr接口访问。这样AMF、SMF、PCF、NEF可以并行、独立地访问各自的订阅数据视图，而不用像4G那样排队经过HSS的单点。 UDM收到 `Nudm_UECM_Registration` 后，如果发现这个UE之前由别的AMF服务（即记录里有旧GUAMI），会向 **Old AMF** 发 `Nudm_UECM_DeregistrationNotification`，触发旧AMF清理上下文——这就是注册流程里"换AMF"的善后机制。 --- ## 七、第五阶段：PCF AM策略关联 注册流程最后一块拼图是策略。AMF通过 **Npcf_AMPolicyControl_Create**（TS 29.507 Section 4.2.2）建立与PCF的策略关联，获取： - **Service Area Restriction**：UE的允许/禁止TA列表（比TAI List更细粒度）； - **RFSP Index**：无线频率选择优先级，透传给RAN影响小区重选； - **Serving Network / NRF ID**：用于切片相关的后续策略。 这一步对**语音业务**尤其关键：AMF根据策略关联结果和UE usage setting，判断该UE是Voice-centric还是Data-centric，从而决定后续是否要为VoNR预留IMS PDU会话的资源（P-CSCF发现）。这也是为什么很多EPS Fallback（VoLTE回退）的故障，根因能追溯到注册阶段的AM策略获取失败。 --- ## 八、第六阶段：Registration Accept —— 四件套下发 注册的高潮是 **Registration Accept**（TS 24.501 Section 8.2.6），它通过 **NGAP InitialContextSetup**（TS 38.413 Section 8.3.1）或 **Downlink NAS Transport** 下发给UE。该消息携带协议上称为"注册结果四件套"的关键参数： | 下发参数 | 作用 | 设计意图 | |---------|------|---------| | **5G-GUTI** | 新的全局唯一临时身份 | 之后所有NAS消息优先用它，隐藏SUPI | | **Allowed NSSAI** | 网络批准UE在本PLMN+接入类型下可用的切片 | 真正生效的切片，可能少于Requested NSSAI | | **TAI List**（Registration Area） | 一组TA，UE在其中移动不触发注册更新 | 尽量大以减少信令，但受策略限制 | | **Configured NSSAI**（可选）| UE在该HPLMN下的配置切片 | 跨PLMN漫游时RPLMN本地配置 | **Allowed NSSAI vs Requested NSSAI 的关系**：UE发的Requested NSSAI是"我想要"，网络返回的Allowed NSSAI是"我批准的"。批准过程要同时满足三个条件：UE签约（UDM的subscribed NSSAI）∩ 网络支持（NSI信息）∩ 当前TA可用。三者取交集就是Allowed NSSAI。这就是为什么UE注册后可用切片可能比预期的少。 **5G-GUTI 重分配的精妙**：注意Registration Accept里下发的5G-GUTI **不一定** 与UE在请求里用的GUTI相同。AMF可以在此时主动分配新GUTI（即隐含的GUTI Reallocation），让UE尽快用上"新鲜的"临时身份，降低被追踪风险。这是5G隐私保护链条的一环。 --- ## 九、状态机视角：5GMM的RM与CM双重状态 注册不只是收发消息，它驱动UE和AMF双方的状态迁移。理解状态机才能在抓包时快速定位"卡在哪一步"。 ```mermaid stateDiagram-v2 [*] --> RM_DEREGISTERED : UE开机 RM_DEREGISTERED --> RM_REGISTERED : 发送Registration Request RM_REGISTERED --> RM_DEREGISTERED : Deregistration/隐式去注册 state RM_REGISTERED { [*] --> CM_IDLE : 注册完成无连接 CM_IDLE --> CM_CONNECTED : Service Request/初始注册 CM_CONNECTED --> CM_IDLE : N2释放(RRC Inactive) } note right of RM_REGISTERED 初始注册成功后: UE进入 RM-REGISTERED + CM-CONNECTED 随后进入 CM-IDLE end note ``` 初始注册成功后，UE同时进入 **5GMM RM-REGISTERED** 和 **CM-CONNECTED** 状态。之后若无业务，N2信令连接释放，UE转入 **CM-IDLE**，但仍保持REGISTERED——这就是5G"控制面连接与注册状态解耦"的核心，与4G的ECM概念类似但粒度更细（多了RRC Inactive的中间态）。 --- ## 十、抓包识别与常见故障 ### 10.1 抓包如何识别初始注册 用Wireshark/TShark过滤： - **N2(NGAP)**：`ngap.procedureCode == 15`（InitialUEMessage）/ `== 18`（InitialContextSetup）/ `== 32`（RerouteNASRequest） - **NAS**：`nas_5gs.message_type == 0x41`（Registration Request）/ `0x42`（Registration Accept）/ `0x43`（Registration Complete） - **SBI(HTTP2)**：按URL路径过滤，如 `http2.headers.authority contains "udm"` 且 `:path contains "uecm"` 即 `Nudm_UECM_Registration` 一次完整初始注册的典型消息数：NGAP 6条左右 + NAS 8条左右 + SBI 15条左右（含认证、订阅数据、策略），合计约25-30条信令。 ### 10.2 常见故障点与排错 | 故障现象 | 可能根因 | 排查方向 | |---------|---------|---------| | 收到Authentication Reject/拒绝 | 5G AKA鉴权失败（MAC不匹配）| 检查UDM侧Ki、OPc，SUCI去隐藏是否成功 | | 卡在RerouteNASRequest循环 | RAN切片映射表错误或Target AMF未注册到NRF | 核对gNB AMF Set配置、NRF NF发现结果 | | Registration Reject #62(No suitable cells) | Allowed NSSAI为空，TA无签约切片 | 检查UDM subscribed NSSAI、NSSF配置 | | Registration Reject #22( congestion) | AMF过载控制 | 查AMF负载、过载开始的N2 Overload Start | | 无InitialContextSetup | UE未请求上下文/策略关联失败 | 查UE Context Request IE、Npcf_AMPolicyControl返回 | | 频繁周期性注册 | T3512定时器过短或TAI List配置太小 | 调整T3512、扩大Registration Area | --- ## 常见问题 **Q1：初始注册和移动性注册更新（Mobility Registration Update）在信令上有什么区别？** A：两者用同一条Registration流程，区别仅在 `5GS Registration type` IE——initial=`001`，mobility=`010`。移动性注册复用已有5G-GUTI和安全上下文，AMF会跳过完整认证（若安全上下文有效），直接走订阅数据刷新和Registration Accept，信令消息数约为初始注册的一半。 **Q2：为什么我的UE注册后可用切片比Requested NSSAI少？** A：Allowed NSSAI是"UE签约NSSAI ∩ 网络在该TA支持的切片 ∩ UE请求"三者的交集。任一条件不满足，对应切片就不会出现在Allowed NSSAI里。最常见的是UDM的subscribed NSSAI没配置该S-NSSAI，或当前TA的NSI未部署。 **Q3：InitialUEMessage和Uplink NAS Transport有什么区别？** A：InitialUEMessage是**首条**N2消息，RRC连接刚建立时用，会触发AMF创建UE上下文；Uplink NAS Transport用于已有N2连接时承载上行NAS消息（如Registration Complete）。注册流程中UE→AMF方向：第一条NAS走InitialUEMessage，之后走Uplink NAS Transport。 **Q4：Registration Accept一定通过InitialContextSetup下发吗？** A：不一定。若UE在Registration Request里带了"UE Context Request"标志，AMF会借InitialContextSetup一并下发（同时建好N3隧道上下文）；否则只用Downlink NAS Transport下发。前者省一次空口往返，是注册+PDU会话一起优化的常见做法。 **Q5：AMF重选时UE侧会感知到吗？** A：不会。UE只发出一条Registration Request，AMF重选对UE完全透明——RerouteNASRequest和N14转发都是网络内部操作，UE最终只看到一条Registration Accept从"网络"返回，并不关心是哪个AMF处理的。 --- ## 参考来源 1. [3GPP TS 23.502 V18.10.0 — Section 4.2.2.2.2 General Registration procedure](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/18.10.00_60/ts_123502v181000p.pdf) — 初始注册完整流程步骤定义 2. [3GPP TS 24.501 — NAS protocol for 5GS](https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/16.15.00_60/ts_124501v161500p.pdf) — Registration Request/Accept消息IE结构（Section 8.2.6/8.2.7） 3. [ShareTechnote — 5G Registration & 5G-GUTI](https://www.sharetechnote.com/html/5G/5G_Registration.html) — 注册流程图解与GUTI/TAI List机制 4. [3glteinfo — 5G Initial Registration Call Flow & Reroute NAS Request](https://www.3glteinfo.com/messages/5g/ngap/reroute-nas-request/) — NGAP AMF重选机制 5. [Cisco UCC 5G AMF Config Guide — Slice Selection & Allowed NSSAI](https://www.cisco.com/c/en/us/td/docs/wireless/ucc/amf/2025-02/config-and-admin/b_ucc-5g-amf-config-and-admin-guide_2025-02/m_slice_selection_support.html) — 切片选择与Allowed NSSAI下发 6. [free5GC Blog — Registration procedures](https://free5gc.org/blog/20240119/20240119/) — 开源核心网注册流程实现解析 --- > 本文由「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 等场景全覆盖。