5G(NR)初始注册信令流程详解：从RRC连接到NAS鉴权的完整交互与排查

简介这份文档面向5G网络优化工程师、核心网测试人员及通信专业学习者系统梳理了NR网络中终端注册与初始注册的完整流程帮助读者理解UE接入5GC并建立用户上下文的关键机制。资源包内含1个docx文件约224KB以图文与报文解析为主便于对照查阅与笔记整理。内容覆盖三类注册类型——开机初始注册、移动更新注册与周期性注册并逐步拆解初始注册的无线接入、鉴权加密、注册请求与注册完成四大阶段同时给出NrnasOtaMsgInterface-MSG报文字段示例逐项说明协议版本、安全头类型、注册类型及SUPI等移动身份信息。目前已有1135人学习适合用于网络规划、故障排查与性能调优场景也可作为5G核心网信令流程的入门参考。1. 5G(NR)注册流程到底在解决什么问题从开机到能上网的那几秒手机开机、插卡、信号格从无到有这背后最关键的一步就是 5G(NR) 网络的用户注册。很多人以为“注册”就是登录一下其实在 5G 核心网里注册Registration是 UE用户设备和 AMF接入与移动性管理功能之间建立信任、协商能力、分配标识的一整套信令交互。没有完成注册你的手机连一个字节的数据都发不出去。初始注册Initial Registration特指 UE 从关机、飞行模式恢复或首次入网时发起的那次注册它和移动性注册更新、周期注册更新最大的区别在于网络对这台设备一无所知需要从零建立上下文。这篇文章面向的是需要看懂 5G 协议栈信令、做核心网调测、或者准备 5G 实训室方案的一线工程师我会把初始注册的信令流程、关键参数、常见翻车点拆开讲清楚让你能对着抓包和日志一步步复现排查。2. 初始注册的信令链路从 RRC 到 NAS 的完整交互2.1 注册之前UE 必须先完成的 RRC 连接建立在 NAS 层的注册请求发出之前UE 和 gNB 之间必须先建立 RRC 连接。这一步是很多新手容易忽略的以为注册就是 NAS 消息一来一回实际上没有 RRC 连接NAS 消息根本没有承载通道。UE 在空闲态下想要发起注册会先做小区搜索和系统消息读取拿到 MIB 和 SIB1确认这个小区能不能驻留、能不能接入。然后 UE 向 gNB 发 RRCSetupRequestgNB 回 RRCSetupUE 再回 RRCSetupComplete。这条 RRCSetupComplete 消息里会携带一个关键的 NAS PDU也就是初始的 Registration Request。换句话说RRC 连接建立和 NAS 注册请求是打包在一起走的不是两个完全独立的阶段。这里有个实操中经常遇到的点如果 gNB 侧配置的 TACTracking Area Code和 AMF 侧配置的 TAC 不一致UE 的 Registration Request 会被 AMF 拒绝原因值通常是 #12Tracking area not allowed。排查的时候先看 gNB 的 SIB1 里广播的 TAC再对 AMF 配置里的 TAI List两边必须能对上。我一般会在 gNB 的配置文件里搜tac这个字段然后在 AMF 的amf.yaml或者对应配置里搜tai逐项比对。2.2 Registration Request 里到底带了什么UE 发出的 Registration Request 是一条 NAS 消息封装在 RRC 的 UL 信息传输里。这条消息里包含几个核心 IE5GS Registration Type、SUCI 或 5G-GUTI、UE 的能力信息、请求的 NSSAI 等。5GS Registration Type 字段决定了这次注册是初始注册值设为“initial registration”还是移动性注册更新。如果是初始注册UE 还没有 5G-GUTI所以必须带 SUCISUCI 是由 IMSI 经过公钥加密生成的隐私保护标识。AMF 收到 SUCI 后如果本地没有该用户的上下文就会向 UDM/UDR 发起鉴权向量获取流程。下面是一个用 Python 解析 NAS 消息中 Registration Request 关键字段的示例假设你已经从抓包里提取出了 NAS 的十六进制载荷# 解析 5G NAS Registration Request 的关键字段 # 输入nas_hex 是从 pcap 中提取的 NAS PDU 十六进制字符串 nas_hex 7e0041790001... # 实际抓包替换 nas_bytes bytes.fromhex(nas_hex) # 第一个字节是扩展协议鉴别器 安全头类型 epd nas_bytes[0] sec_header nas_bytes[1] # 5GS Registration Type 在第三个字节的低4位 reg_type nas_bytes[2] 0x0F # 0x01 initial registration, 0x02 mobility registration updating reg_type_map {1: initial registration, 2: mobility registration updating, 3: periodic registration updating, 4: emergency registration} # 5GS Mobile Identity IE 通常跟在后面类型值 0x77 表示 SUCI # 这里只做示意实际解析需要按 IE 长度逐字段推进 print(fSecurity Header Type: {sec_header:#04x}) print(f5GS Registration Type: {reg_type_map.get(reg_type, unknown)})这段代码的逻辑是先定位 NAS 消息头再按 5G NAS 协议3GPP TS 24.501的 IE 排列顺序提取 Registration Type。参数说明nas_bytes[0]是扩展协议鉴别器5G NAS 固定为 0x7Enas_bytes[1]的高 4 位是安全头类型低 4 位是协议鉴别器nas_bytes[2]的低 4 位才是注册类型。实际抓包里如果启用了 NAS 安全Registration Request 之后的消息会被加密你只能看到明文的那一条初始请求。这也是为什么调测时一定要在 AMF 侧开 NAS 明文日志否则后面鉴权、安全模式命令这些全是被加密的黑匣子。2.3 鉴权与安全模式AMF 和 UE 之间的信任建立AMF 收到 Registration Request 后如果发现是初始注册且没有有效上下文就会触发鉴权流程。AMF 向 UDM 发 Nudm_UEAuthentication_Get RequestUDM 生成鉴权向量RAND、AUTN、XRES*、KAUSF回给 AMF。AMF 把 RAND 和 AUTN 通过 Authentication Request 发给 UEUE 侧的 USIM 卡计算 RES*回 Authentication Response。AMF 比对 XRES* 和 RES*一致则鉴权通过。紧接着 AMF 发起 Security Mode Command协商 NAS 加密和完整性保护算法UE 回 Security Mode Complete。从这一刻起后续的 NAS 消息全部加密。这里有个血泪经验如果 USIM 卡里的鉴权算法和 UDM 侧配置的不匹配鉴权会直接失败UE 会收到 Authentication Reject然后可能触发多次重试最后显示“无法注册”。排查的时候先看 AMF 日志里的鉴权失败原因如果是 MAC failure通常是 AUTN 里的 MAC 校验不过说明卡和网络侧的 K 值不一致。如果是 SQN failure说明序列号不同步需要重新同步 SQN。我一般会先用一个已知能用的测试卡验证网络侧配置再换目标卡这样能快速定位是卡的问题还是网络的问题。2.4 Registration Accept 与 UE 上下文的最终建立鉴权和安全模式完成后AMF 会向 UDM 发起 Nudm_UECM_Registration把 AMF 自己注册为该 UE 的服务 AMF。然后 AMF 根据 UE 请求的 NSSAI 和签约的 NSSAI 做切片选择选出允许的 S-NSSAI再决定是否触发 PDU 会话建立。最后 AMF 向 UE 发 Registration Accept里面包含 5G-GUTI、TAI List、允许的 NSSAI、网络切片配置等信息。UE 回 Registration Complete整个初始注册流程才算走完。Registration Accept 里的 5G-GUTI 是后续移动性注册更新的关键如果 AMF 没有正确分配 GUTIUE 下次做移动性注册更新时还得带 SUCI会增加信令开销。实操中我会在 AMF 配置里确认guti相关的分配策略是否开启有些测试环境为了简化会关掉 GUTI 分配但生产环境必须开。3. 用开源工具抓包验证初始注册从 pcap 到信令时序3.1 搭建最小验证环境gNB AMF UE 模拟器如果你想亲手验证初始注册流程最直接的方式是用开源 5G 核心网加一个 UE 模拟器。常见的做法是用 free5GC 或者 Open5GS 作为核心网gNB 侧可以用 UERANSIM 模拟。UERANSIM 既能模拟 gNB也能模拟 UE非常适合做信令流程验证。部署的时候AMF 的 NGAP 接口监听在 SCTP 38412 端口gNB 侧配置要指向 AMF 的 IP 和端口。UE 模拟器启动后会读取配置文件里的 IMSI、K、OPC 等参数这些必须和核心网 UDM 里配置的用户信息一致否则鉴权必挂。下面是一个 UERANSIM UE 配置文件的片段展示了关键参数# ueransim UE 配置文件关键字段 supi: imsi-001010000000001 # 用户永久标识必须和 UDM 一致 mcc: 001 # 移动国家码 mnc: 01 # 移动网络码 key: 465B5CE8B199B49FAA5F0A2EE238A6BC # 用户密钥 K op: E8ED289DEBA952E4283B54E88E6183CA # 运营商变体算法参数 OPc amf: 8000 # 鉴权管理字段 imei: 356938035643803 # 设备标识 imeiSv: 4370816125816151 # 设备软件版本 gnbSearchList: - 127.0.0.1 # gNB 地址本地测试指向回环参数说明supi是用户永久标识格式是imsi-加 MCCMNCMSINkey和op必须和 UDM 里该用户的配置完全一致差一个字符鉴权就会失败gnbSearchList告诉 UE 去哪里找 gNB本地测试填 127.0.0.1 即可。启动顺序是先起核心网再起 gNB最后起 UE。UE 启动后会自动发起初始注册你可以在 AMF 的日志里看到完整的信令交互。3.2 在 AMF 侧抓取 NGAP 和 NAS 日志UERANSIM 和 free5GC 都支持日志输出。free5GC 的 AMF 可以配置日志级别为 debug这样 NGAP 和 NAS 消息都会打印出来。如果你用的是 Open5GS可以在amf.yaml里把logger.level设为debug。日志里你会看到类似[AMF] Handle Registration Request这样的条目后面跟着 SUCI、注册类型等信息。如果你想更直观地看信令时序可以在 gNB 和 AMF 之间的 SCTP 链路上抓包用 Wireshark 打开过滤ngap或者nas-5gs协议。Wireshark 内置了 5G NAS 的解析器能直接展开 Registration Request 里的各个 IE。抓包的时候注意一点如果你在容器环境里跑核心网SCTP 抓包需要在宿主机上对 veth 接口抓或者直接在容器内用 tcpdump 抓。我一般会在 AMF 容器里执行tcpdump -i any -s 0 -w /tmp/amf.pcap sctp port 38412然后把 pcap 拷出来用 Wireshark 分析。这样抓到的包包含完整的 NGAP 和 NAS 消息比看日志更可靠。3.3 用 Wireshark 过滤并解读 Registration RequestWireshark 打开 pcap 后在过滤栏输入nas-5gs.nas_5gs_message_type 0x41可以只显示 Registration Request 消息。0x41 是 5G NAS 里 Registration Request 的消息类型值。展开后你能看到 5GS Registration Type、5GS Mobile Identity、UE Security Capability 等字段。如果看到 Registration Request 之后直接跟 Registration Reject展开 Reject 消息里的 5GMM Cause常见的原因值有 #3Illegal UE、#6Illegal ME、#75GS services not allowed、#12Tracking area not allowed、#22Congestion。每个原因值对应不同的排查方向比如 #7 通常是签约数据里没开 5G 服务需要去 UDM 里检查该用户的签约切片和 DN 配置。4. 初始注册的避坑与排查那些让注册卡住的常见原因4.1 坑一SUCI 解密失败导致鉴权无法发起现象UE 发出 Registration Request 后AMF 日志显示收到消息但迟迟不发 Authentication Request或者直接回 Registration Reject原因值 #3。原因AMF 需要用私钥解密 SUCI 里的 IMSI如果 AMF 配置的公私钥对和 UE 侧加密用的公钥不匹配解密就会失败。常见于自己生成密钥对但只更新了一侧的场景。解决确认 AMF 侧的 SUCI 解密配置free5GC 里在amf.yaml的suci段配置私钥路径Open5GS 在amf.yaml里配置security.suci相关字段。UE 侧使用的公钥必须和 AMF 私钥配对测试环境可以直接用核心网自带的默认密钥对。4.2 坑二NSSAI 不匹配导致切片选择失败现象鉴权通过、安全模式完成但 AMF 回 Registration Reject原因值 #62No network slices available或者 #69Requested NSSAI not available。原因UE 在 Registration Request 里请求的 S-NSSAI 和 UDM 签约的 S-NSSAI 对不上或者 AMF 配置的 TAI 不支持该切片。解决先看 UE 请求的 NSSAI 值再对 UDM 里该用户的签约切片最后确认 AMF 的plmn_support配置里该 TAC 是否绑定了对应的 S-NSSAI。三处必须一致缺一不可。4.3 坑三TAC 不一致导致跟踪区不允许现象Registration Request 发出后立刻收到 Registration Reject原因值 #12。原因gNB 广播的 TAC 和 AMF 配置的 TAI List 里的 TAC 不匹配。UE 驻留的小区 TAC 不在 AMF 允许的跟踪区列表里。解决在 gNB 配置里找到tac字段在 AMF 配置里找到tai_list或tac字段确保 gNB 的 TAC 在 AMF 的 TAI List 范围内。如果是多 gNB 环境每个 gNB 的 TAC 都要在 AMF 的列表里。4.4 坑四UE 安全能力不匹配导致 Security Mode 失败现象鉴权通过后AMF 发 Security Mode Command但 UE 回 Security Mode Reject 或者根本不回。原因AMF 选择的 NAS 加密算法或完整性保护算法UE 不支持。常见于 UE 模拟器配置的安全能力字段和 AMF 支持的算法集没有交集。解决在 AMF 配置里查看支持的算法列表通常有 NEA0/NEA1/NEA2/NEA3 和 NIA0/NIA1/NIA2/NIA3在 UE 侧确认其声明的安全能力。测试环境可以先把算法优先级调成 NEA0/NIA0即不加密确认流程能走通后再逐步启用加密算法。4.5 坑五UDM 签约数据缺失导致注册被拒现象鉴权通过但 AMF 向 UDM 查询签约数据时返回错误最终 Registration Reject原因值 #7 或 #22。原因UDM/UDR 里没有该用户的签约数据或者签约数据里没有开通 5G 服务。解决检查 UDM 里该 SUPI 对应的用户是否存在签约的切片、DN、QoS 配置是否完整。如果是用 Web 控制台添加用户注意有些字段有默认值但切片信息必须手动添加否则 AMF 查不到可用的 S-NSSAI。5. 从初始注册延伸到移动性注册一个参数决定信令开销初始注册走通之后UE 进入连接态或空闲态。当 UE 移动导致跟踪区变化时会触发移动性注册更新Mobility Registration Updating。这两种注册最大的区别在于初始注册必须带 SUCI而移动性注册更新如果 UE 有有效的 5G-GUTI就可以只带 GUTIAMF 通过 GUTI 直接找到上下文省去 SUCI 解密和 UDM 查询的步骤。所以 5G-GUTI 的分配策略直接影响后续的信令开销。我一般会在 AMF 配置里确认 GUTI 的分配是开启的并且 GUTI 的 PLMN 部分和当前服务网络的 PLMN 一致。如果 GUTI 里的 PLMN 不对UE 在做移动性注册更新时会被 AMF 拒绝原因值 #9UE identity cannot be derived by the network。另一个值得关注的参数是 T3512 定时器它控制周期注册更新的间隔。T3512 设得太短UE 会频繁发起周期注册增加信令负载设得太长UE 失联后网络侧不能及时感知。常见做法是根据业务场景调整eMBB 场景可以设长一些URLLC 场景需要设短一些。在 AMF 配置里搜t3512就能找到对应的定时器值单位是秒。我一般会在实验室环境先设一个较小的值比如 60 秒来快速验证周期注册流程确认没问题后再改回生产推荐值。验证移动性注册更新是否成功可以在 UE 侧看日志里有没有Mobility Registration Updating的字样然后在 AMF 侧确认收到的 Registration Request 里 5GS Registration Type 是 0x02。如果 UE 明明有 GUTI 却还是带了 SUCI说明 GUTI 没有被正确保存或者已经失效需要检查 UE 的 USIM 或非易失存储里 GUTI 的写入逻辑。这个细节在做 5G 模组开发时特别容易翻车因为有些模组的 GUTI 存储是在 RAM 里断电就丢下次开机又得走完整的初始注册。希望帮到你。本文还有配套的精品资源点击获取