# 5G网络注册全流程：从开机到在线的信令旅程 你刚买了一台5G手机，按下开机键，屏幕上信号栏从空格变成满格——这短短几秒钟里，手机和网络之间已经完成了一场精密的多方协作。从物理层的随机接入，到RRC连接建立，再到NAS层的注册、认证、安全协商，涉及终端、基站、AMF、AUSF、UDM、PCF等六七个网元的协同配合。 这篇文章就把这段旅程完整拆开，让你看清每一步"为什么这样设计"。 ## 一、从生活类比理解注册 想象你搬进一个新小区： | 注册步骤 | 生活类比 | |---|---| | 小区搜索+随机接入 | 找到小区大门，按门铃 | | RRC连接建立 | 保安给你开门，建立通话通道 | | 注册请求 | 到物业前台登记 | | 身份验证 | 出示身份证，物业核验真伪 | | 安全模式设置 | 物业给你配一把加密的门禁卡 | | 签约数据获取 | 物业查你的业主信息（能享受哪些服务） | | 注册接受 | 物业说"登记成功，这是你的门禁卡号" | 整条链路的核心目标只有三个：**你是谁**（身份认证）、**你有权用什么**（签约授权）、**我怎么安全地找到你**（安全上下文+临时标识）。 ## 二、全局流程概览 先看完整信令流程，心中有一张全景图： ```mermaid sequenceDiagram participant UE as 手机(UE) participant gNB as 基站(gNB) participant AMF as 接入管理(AMF) participant AUSF as 认证服务(AUSF) participant UDM as 统一数据(UDM) participant PCF as 策略控制(PCF) Note over UE,gNB: 阶段1: 物理层接入 UE->>gNB: 1. PRACH preamble（随机接入前导） gNB->>UE: 2. Random Access Response（TA调整+UL授权） UE->>gNB: 3. RRCSetupRequest（携带UE标识） Note over UE,gNB: 阶段2: RRC连接建立 gNB->>UE: 4. RRCSetup（分配SRB1配置） UE->>gNB: 5. RRCSetupComplete + NAS Registration Request Note over gNB,AMF: 阶段3: NAS注册与路由 gNB->>AMF: 6. N2 Initial UE Message（转发NAS） opt AMF无法识别UE AMF->>UE: 7. Identity Request UE->>AMF: 8. Identity Response（返回SUCI） end Note over AMF,UDM: 阶段4: 认证与密钥协商 AMF->>AUSF: 9. Nausf_UEAuthentication Request AUSF->>UDM: 10. Nudm_UEAuthentication Get UDM-->>AUSF: 11. 认证向量(RAND,AUTN,XRES*) AUSF-->>AMF: 12. (RAND,AUTN,HXRES*,K_SEAF) AMF->>UE: 13. Authentication Request（RAND+AUTN） UE->>AMF: 14. Authentication Response（RES*） AMF->>AUSF: 15. 验证确认请求 AUSF-->>AMF: 16. 认证确认+K_AUSF Note over UE,AMF: 阶段5: NAS安全激活 AMF->>UE: 17. Security Mode Command UE->>AMF: 18. Security Mode Complete Note over AMF,PCF: 阶段6: 签约数据与策略 AMF->>UDM: 19. Nudm_UECM_Registration（AMF注册） AMF->>UDM: 20. Nudm_SDM_Get（获取签约数据） UDM-->>AMF: 21. 签约数据返回 AMF->>PCF: 22. AM Policy Association（策略关联） Note over UE,AMF: 阶段7: 注册完成 AMF->>UE: 23. Registration Accept（含5G-GUTI、Allowed NSSAI、TAI List） UE->>AMF: 24. Registration Complete ``` 七个阶段，环环相扣。接下来逐阶段深入。 ## 三、阶段1-2：从物理世界到信令通道 ### 随机接入——敲基站大门 手机开机后先做小区搜索（搜索SSB、解调MIB/SIB1），确定驻留小区后发起**随机接入**。这个过程在《5G随机接入：手机敲基站大门的暗号》中已有详解，这里只说关键点： - 手机发送PRACH preamble，基站回复RAR（Random Access Response），完成上行同步 - 随后手机发送**RRCSetupRequest**，携带一个临时标识（39-bit或52-bit的random value） **为什么用随机值而非真实身份？**因为此时没有任何安全上下文，在空口暴露真实身份是危险的。这就像你去银行，在大厅里不会喊出身份证号，而是先拿一个排队号。 ### RRC连接建立——搭起信令管道 基站收到RRCSetupRequest后，回复**RRCSetup**消息，分配SRB1（Signaling Radio Bearer 1）的配置。手机再发**RRCSetupComplete**，关键的是——这条消息里**捎带**了NAS层的Registration Request。 ``` ┌──────────────────────────────────────────────┐ │ RRCSetupComplete │ │ ├── selectedPLMN-Identity │ │ ├── registeredAMF (如果有旧GUTI) │ │ └── dedicatedNAS-Message │ │ └── Registration Request ← NAS消息嵌套 │ │ ├── Registration Type: Initial │ │ ├── 5G-GUTI 或 SUCI │ │ ├── Requested NSSAI │ │ └── UE security capability │ └──────────────────────────────────────────────┘ ``` 这里体现了通信协议设计中"**嵌套封装**"的核心理念：RRC是接入层协议，负责无线链路管理；NAS是非接入层协议，负责核心网信令。NAS消息像信封里的信，RRC是快递员——快递员不需要知道信的内容，只需要送到对的地址。 ## 四、阶段3：基站如何找到对的AMF 基站收到RRCSetupComplete后，需要把NAS消息转发给核心网。但5G核心网里有很多AMF，**基站怎么知道该送给谁？** 这就是5G的**AMF选择机制**： ```mermaid flowchart TD A[基站收到NAS注册请求] --> B{NAS中携带5G-GUTI?} B -->|是| C[从GUAMI提取旧AMF地址] B -->|否,携带SUCI| D[从SUCI提取Home Network ID] B -->|仅携带SUCI+Requested NSSAI| E[综合路由信息选择] C --> F{旧AMF可达?} F -->|是| G[直接转发至旧AMF] F -->|否| H[查询AMF Set/DNS选择新AMF] D --> H E --> H H --> I{需要NSSF参与?} I -->|Requested NSSAI不为空| J[咨询NSSF获取目标AMF] I -->|无切片需求| K[基于PLMN+TAC路由至默认AMF] J --> L[转发N2 Initial UE Message] K --> L G --> L ``` **设计哲学**：4G里MME选择相对简单，主要靠TAC（Tracking Area Code）。5G引入了**网络切片**，选择AMF不仅要考虑位置（TAC），还要考虑切片（NSSAI）。这意味着同一栋楼里的两个用户，如果签约了不同的切片（比如一个是eMBB，一个是URLLC），可能被路由到不同的AMF。 | 选择依据 | 4G MME选择 | 5G AMF选择 | |---|---|---| | 位置信息 | TAC → MME Pool | TAC + AMF Region/Set | | 切片信息 | 无 | Requested NSSAI → NSSF | | 负载均衡 | MME Pool内权重 | AMF Set内权重 + AMF容量 | | 旧标识 | GUTI → 旧MME | 5G-GUTI → 旧AMF（可跨AMF Set） | ## 五、阶段4：认证——网络和手机互相验明正身 ### 为什么需要双向认证？ 在2G时代，只有**网络认证手机**（网络检查SIM卡是否合法），但手机不认证网络。这导致一个严重漏洞：攻击者可以部署伪基站，手机会乖乖连上去。从3G开始引入双向认证，5G进一步强化。 ### SUCI——保护你的"身份证号" 5G的一个重大隐私增强是**SUCI（Subscription Concealed Identifier）**。 4G里手机开机时发送IMSI（明文或简单加密），容易被空口窃听。5G中，手机用运营商的**公钥**加密SUPI（5G版的IMSI），生成SUCI： $$\text{SUCI} = \text{SUPI Type} \| \text{Home Network ID} \| \text{Routing Indicator} \| \text{Scheme Output}$$ 其中Scheme Output是用ECIES（椭圆曲线集成加密方案）加密的结果： $$\text{Scheme Output} = \text{Eph.\ Public Key} \| \text{Enc(SUPI)} \| \text{MAC tag}$$ 只有运营商核心网中的**SIDF（Subscription Identifier De-concealing Function）**，位于UDM中，持有对应的**私钥**才能解密。空口上任何人截获的都只是一串无意义的密文。 ### 5G-AKA认证流程 认证的核心是挑战-应答机制： ``` 网络说："给你一个随机数RAND和认证令牌AUTN，证明你持有正确的密钥K" 手机说："我用K算出RES*，你验证一下" 网络验证："RES*正确，你确实是合法用户" 手机验证："AUTN正确，你确实是合法网络" ``` 具体密钥推导层级： ```mermaid flowchart BT K[永久密钥 K
存储在USIM和UDM中] --> K_AUSF K_AUSF[K_AUSF
AUSF生成] --> K_SEAF K_SEAF[K_SEAF
SEAF生成] --> K_AMF K_AMF[K_AMF
AMF生成] --> KNAS_int K_AMF --> KNAS_enc K_AMF --> KgNB KgNB --> KRRC_int KgNB --> KRRC_enc KgNB --> KUP_enc style K fill:#ff6b6b,color:#fff style K_AUSF fill:#ffa502,color:#fff style K_SEAF fill:#ffd43b,color:#333 style K_AMF fill:#51cf66,color:#fff ``` **设计要点**： - 永久密钥K永远不离开USIM和UDM，空口传输的只有随机挑战和计算结果 - 密钥层层衍生，每层只暴露给需要的网元——AMF拿不到K_AUSF，gNB拿不到K_AMF - 引入**K_SEAF**（ Serving Network Anchor Key）是5G的新设计，把密钥锚定在服务网络，防止跨运营商的密钥滥用 ## 六、阶段5：安全模式——给信令通道上锁 认证通过后，AMF立即发起**NAS Security Mode Control**： 1. AMF → UE：Security Mode Command，携带选定的加密/完整性保护算法 2. UE → UE：本地推导KNAS_int和KNAS_enc 3. UE → AMF：Security Mode Complete，用新密钥做完整性保护 **为什么完整性保护是强制的？**在4G中，NAS完整性保护是可选的（有些运营商不开），但5G规定**所有NAS信令必须做完整性保护**。原因很简单：完整性保护防的是篡改，加密防的是窃听。篡改比窃听更危险——攻击者修改一条NAS消息（比如修改注册区域的TAI List），就能把用户误导到错误的区域。 | 安全特性 | 4G NAS | 5G NAS | |---|---|---| | 加密（Confidentiality） | 推荐 | 推荐 | | 完整性（Integrity） | 可选 | **强制** | | 算法 | AES/SNOW/祖冲之 | 同左 + 空算法仅限紧急注册 | | 初始NAS消息保护 | 无 | **有**（部分IE加密） | ## 七、阶段6：签约数据——查查你能用什么 安全激活后，AMF需要获取用户的签约信息。这涉及与UDM的两次交互： ### 7.1 AMF注册自己 AMF先通过**Nudm_UECM_Registration**告诉UDM："我是当前服务这个用户的AMF"。这有两个目的： - UDM记录当前服务AMF，后续网络侧需要联系UE时（比如被叫寻呼），知道找谁 - 如果用户之前在其他AMF注册过，UDM会通知旧AMF清理上下文 ### 7.2 获取签约数据 然后AMF通过**Nudm_SDM_Get**拉取用户的签约数据，包括： | 数据类型 | 包含内容 | 影响什么 | |---|---|---| | Access and Mobility | 允许的TA列表、漫游限制、RAT限制 | 移动性管理 | | SMF Selection | 默认SMF、DNN配置、切片信息 | PDU会话建立 | | UE context in SMF | 已有的PDU会话信息 | 会话 continuity | | LCS | 定位服务签约 | 定位精度和权限 | | SMS | SMS over NAS支持 | 短信能力 | 特别值得关注的是**NSSAI协商**：UE在注册请求中携带Requested NSSAI（我想用的切片），AMF从签约数据中获取Subscribed S-NSSAI（你签约的切片），两者取交集就是Allowed NSSAI（你实际能用的切片）。这个过程可能有NSSF参与，做更精细的切片路由。 ## 八、阶段7：注册接受——拿到"通行证" 一切就绪后，AMF发送**Registration Accept**，这是整条流程的收尾消息，携带多个关键信息： ``` Registration Accept ├── 5G-GUTI ← 你的新临时身份 ├── Allowed NSSAI ← 你能用的切片 ├── TAI List ← 你的注册区域范围 ├── LADN Information ← 本地数据网络信息 ├── MICO Mode Indication ← 是否允许仅信令连接 ├── T3512 Timer Value ← 周期性注册定时器 └── Operator-defined Access Category Definitions ``` ### 5G-GUTI的设计 5G-GUTI是AMF分配给UE的临时标识，结构如下： $$\text{5G-GUTI} = \text{GUAMI} \| \text{5G-TMSI}$$ 其中GUAMI = PLMN ID + AMF Region ID + AMF Set ID + AMF Pointer。 **为什么要分配临时标识？**如果手机每次通信都用SUCI（虽然已加密），攻击者还是可以通过SUCI的固定字段（Home Network ID + Routing Indicator）跟踪用户。用随机化的5G-GUTI后，同一用户在不同时刻用不同的临时标识，大大增加了跟踪难度。 **Registration Complete**消息是UE收到Registration Accept后的确认，主要是确认收到了新的5G-GUTI。这保证了一次性分配机制——如果UE没确认，AMF不知道GUTI是否生效，下次会继续用旧标识。 ## 九、四种注册类型对比 注册不只"开机注册"这一种场景： | 注册类型 | 触发条件 | 核心差异 | |---|---|---| | **初始注册** | 开机、从盲区恢复、显式去注册后 | 完整流程，必经认证 | | **移动性注册** | 进入新TA不在TAI List中 | 可能触发AMF重选，可能跳过认证 | | **周期性注册** | T3512定时器超时 | 通常跳过认证（安全上下文仍有效） | | **紧急注册** | 无USIM/USIM无效时打紧急电话 | 跳过认证或使用受限认证 | 一个精妙的设计：周期性注册用定时器T3512控制。手机在空闲态（CM-IDLE）时，核心网不知道手机是否还在服务区。T3512强制手机定期"报平安"——如果AMF在多个T3512周期内没收到注册，就认为用户不可达，停止为其分配资源。 ## 十、与4G Attach的本质区别 很多人会问：这和4G的Attach有什么不同？ | 维度 | 4G Attach | 5G Registration | |---|---|---| | 命名 | Attach | Registration | | 是否建立默认承载 | **是**，Attach过程中建立 | **否**，PDU Session是独立流程 | | 身份保护 | IMSI明文（隐私弱点） | SUCI加密（ECIES保护） | | 切片支持 | 无 | NSSAI协商 | | 认证方式 | EPS-AKA | 5G-AKA或EAP-AKA' | | 多接入统一 | 仅3GPP | 3GPP+非3GPP统一注册框架 | | 完整性保护 | 可选 | **强制** | 5G最大的架构变化是**注册和会话分离**。4G中Attach必定建立默认承载（PDN Connection），这导致Attach流程很重，MME要同时和S-GW、P-GW交互。5G中Registration完成后，手机处于"注册但无数据连接"的状态，PDU Session可以按需建立，甚至可以建立多个。 ## 十一、现网调试实战 ### 11.1 抓包看什么 在现网排查注册失败时，信令抓包的切入点： | 失败阶段 | 表现 | 排查方向 | |---|---|---| | RRC建立失败 | RRCSetupRequest后无响应 | 覆盖问题、PRACH参数配置 | | AMF拒绝注册 | Registration Reject（Cause #11等） | PLMN限制、TA不在签约区域 | | 认证失败 | Authentication Failure | SIM卡问题、Ki/K OP不匹配 | | 安全模式失败 | Security Mode Reject | 算法不匹配、密钥推导异常 | | UDM查询失败 | 超时无响应 | UDM接口故障、用户数据缺失 | ### 11.2 常见陷阱 **陷阱1：SUCI解密失败** 如果USIM中的公钥ID和UDM中配置的密钥对不匹配（比如换卡后USIM用新密钥，但UDM还配着旧密钥），SIDF无法解密SUCI，AMF会发起Identity Request要求UE发送明文SUPI。在严格隐私策略下，某些运营商配置为直接拒绝，导致注册失败。 **陷阱2：AMF选择死循环** 当UE携带的5G-GUTI指向一个已经不存在的AMF（比如AMF重启/缩容），新AMF尝试联系旧AMF获取上下文会超时。正常流程会fallback到请求SUCI重新认证，但如果路由配置有误，可能反复选择到错误的AMF。 **陷阱3：NSSAI不匹配** UE请求的切片不在签约数据中。5G的容错设计是：如果所有请求的切片都不允许，Registration Reject；如果部分允许，返回Allowed NSSAI，手机只能用允许的切片建PDU Session。调试时注意看Registration Accept中的Allowed NSSAI是否为空。 ## 十二、完整时序的"时间感" 一个典型的5G初始注册，从PRACH到Registration Complete，在良好无线条件下： ``` PRACH → RAR: ~2-5ms RRC Setup三步: ~5-15ms N2转发到AMF: ~5-10ms 认证(AUSF/UDM往返): ~20-50ms（取决于UDM部署位置） 安全模式: ~5-10ms 签约数据查询: ~10-30ms Registration Accept: ~5-10ms ───────────────────────────── 总计: ~50-130ms ``` 对比4G Attach通常需要100-200ms，5G的注册流程本身更轻量（因为不建承载），但后续的PDU Session建立会额外增加100-200ms。总体的"开机到上网"时间，5G略优于4G。 ## 常见问题 **Q: 手机从4G切换到5G，需要重新注册吗？** A: 取决于场景。如果4G和5G共用5G核心网（5GC，即SA模式），且AMF相同，可以做**idle mobility from E-UTRA**——手机从4G小区移动到5G小区时，发起Mobility Registration，可以复用已有的安全上下文，流程比初始注册快得多。如果是EPS（4G核心网EPC）到5GC的跨系统切换，则需要完整的初始注册。 **Q: 为什么不把PDU Session建立合并到注册流程中？** A: 这是5G架构的核心设计理念——**控制面和用户面解耦**。注册解决的是"你是谁、你在哪"的问题，PDU Session解决的是"你要什么数据通道"的问题。分离后，一个注册的用户可以按需建立/释放多个PDU Session，而不需要每次都重新认证。这也让网络切片的实现更灵活——不同切片的PDU Session可以由不同的SMF管理。 **Q: 周期性注册会不会浪费电？** A: 会的。T3512越短，手机越频繁"报平安"，越费电。但太长的话，核心网不知道用户是否可达，被叫寻呼范围会过大。运营商通常配置T3512为54分钟到6小时之间。5G还引入了**MICO mode（Mobile Initiated Connection Only）**，允许某些物联网终端在注册时声明"我只主动发起连接，不需要被寻呼"，这样核心网可以给更长的T3512甚至免除周期性注册。 **Q: 注册失败后手机会怎么做？** A: 取决于拒绝原因值。如果是#11（PLMN not allowed），手机会将该PLMN加入禁止列表，尝试下一个PLMN。如果是#12（Tracking Area not allowed），手机尝试选择同一PLMN中的其他TA。如果是#22（Congestion），手机会在backoff timer超时后重试。不同原因值对应不同的重试策略，这保证了网络拥塞时不会雪崩。 **Q: 非3GPP接入（比如WiFi）的注册和这个一样吗？** A: 信令流程基本相同，但接入段不同。非3GPP接入通过N3IWF（Non-3GPP InterWorking Function）建立IPsec隧道，NAS消息在隧道中传输。AMF用同一套框架处理3GPP和非3GPP接入的注册——这正是5G统一接入控制的核心设计。同一张5G-GUTI可以同时用于5G基站和WiFi。 ## 参考来源 1. [ShareTechnote - 5G Registration](https://www.sharetechnote.com/html/5G/5G_Registration.html) — 详细的5G注册流程说明与消息解析 2. [free5GC - Registration Procedures](https://free5gc.org/blog/20240119/20240119/) — 开源5G核心网项目的注册流程技术文档 3. [3GLTEInfo - 5G NR Initial Registration Procedure](https://www.3glteinfo.com/call-flows/5g/initial-registration/) — 5G初始注册信令流程图与步骤分解 4. [TelecomTrainer - 5G AMF Interactions Explained](https://www.telecomtrainer.com/5g-amf-interactions-explained-step-by-step-5g-standalone-access-registration-flow/) — AMF选择与N2接口信令详解 5. [华为云社区 - 5GC的注册管理](https://bbs.huaweicloud.com/blogs/291684) — 5GC注册管理状态模型与流程分析 --- > 本文由「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 等场景全覆盖。