简介一份专门梳理5G NR独立组网SA终端附着完整信令流程的docx文档主要面向5G网络优化工程师、通信技术支持人员以及刚入门SA信令的网优学习者。文档以空口OTA消息时序图为骨架完整覆盖UE从接收SSBPSS/SSS/MIB完成下行同步读取SIB1与其它SIB获取系统配置通过PRACH发送随机接入前导Msg1接收Msg2随机接入响应、Msg3 RRC Setup Request、Msg4 RRC Setup再到RRC Setup Complete携带NAS Registration Request随后依次经历身份请求/响应、鉴权、安全模式命令及完成最终由RRC Reconfiguration下发Registration Accept完成PDU Session建立的整个流程。每一步都标注了消息方向、对应信道及关键参数如RA-RNTI、T-C-RNTI、C-RNTI同时说明HARQ ACK/NACK在PDSCH/PUSCH传输中的保障作用。资源为1个docx文件整体仅127KB内容精炼可配合Amarisoft等日志工具直接对照分析。目前已有428人学习适合用于5G接入失败排查、信令流程培训和日常网优参考。1. 5G NR SA 里的“附着”注册流程为何值得你逐段拆开把 5G 终端在 SA 基站下开机、入网、建立会话这件事摊开你看到的不是一个“附着”动作而是一串跨越终端、基站、核心网的消息编排。4G 时代叫 Attach5G SA 里它被拆成 Registration初始注册与 PDU Session Establishment会话建立两段流程前者负责身份认证和网络可达后者负责用户面数据通路。正因为 SA 没有锚点网元替你兜底消息链上任何一段失败都会让终端反复新建 RRC 连接表现为“有信号但上不了网”。这篇文章不讨论网优指标只把 NG-RAN 和 5GC 之间的 N1/N2/N3 链路按真实流程逐段拆开从 RACH 的 preamble 格式选择到 AMF 的鉴权与 NSSAI 协商最后落在信令日志的排障锚点上。无论你是在实验室调基站、在核心网侧看注册成功率还是处理“5G 信号满格却无法注册”的工单这套流程拆解都能直接对应到信令平面上的某一条消息。2. SA 终端附着消息链路从 RRC 建立到 Registration Complete 的主要流程2.1 RRC 层交付附着流程的第一段承载终端在 SA 小区上的附着流程第一步与 LTE 相同点在于都要先完成 RRC 建立但 5G NR 里 RRC 建立所承载的意义变了。RRCSetupRequest 里使用 InitialUE-Identity 区分终端如果终端有 5G-S-TMSI就用这个临时标识如果是开机首次发起或 TMSI 不可用就填一个来自高层的随机值。gNB 看到随机值时就知道这是一次初始注册后续会触发完整的鉴权流程。RRCSetupComplete 消息里会携带 NAS 层的第一条关键消息——Registration Request。这条消息附着在 RRC 之上通过 SRB2 之前的 SRB1 传递包含 SUCI 或 5G-GUTI、requested NSSAI、UE 的 5GMM 能力、PDU session 状态等。gNB 在这里扮演的角色只是透传它从 RRCSetupComplete 里取出 NAS PDU再封装到 NGAP 的 INITIAL UE MESSAGE 里往核心网侧转发。这一环节最常见的失败点是 RRCSetup 之后终端一直不反馈 RRCSetupComplete或者反馈了但 gNB 侧解析不到完整的 NAS PDU。排查方向通常集中在 T300 超时、SRB1 的 RLC 配置异常以及终端和基站之间的安全能力不匹配。注意SRB1 在 RRCSetup 之后就建立完成但 NAS 信令此时仍未加密完整性保护也要等到后面 NAS SMC 完成后才生效。2.2 注册消息进入核心网INITIAL UE MESSAGE 与 AMF 选择INITIAL UE MESSAGE 是 NGAP 层的第一跳消息它把 RRCSetupComplete 里的 NAS PDU 原样搬到核心网。gNB 在发送这条消息前必须先选定一个 AMF。选 AMF 的逻辑依据是 gNB 本地配置的 AMF Set、终端携带的 5G-GUTI 中的 GUAMI 信息以及 requested NSSAI 对应的切片可用性。终端如果携带了有效的 5G-GUTIgNB 会优先把消息路由到 GUAMI 指向的 AMF这样可以做到跨 AMF 的上下文关联。AMF 收到 INITIAL UE MESSAGE 之后开始做注册类型判断initial registration、mobility registration update、periodic registration update 三种类型决定了后续是否要做完整鉴权。终端在 Registration Request 里如果有 PDU session status 信息AMF 还会据此判断哪些会话需要重建或移交到新的 SMF。这里要提醒一点AMF 选择错误导致的消息路由风暴经常被误判成终端问题。对于现网排查我一般会在 gNB 和 AMF 之间抓 NGAP 消息重点看 INITIAL UE MESSAGE 里的 RAN UE NGAP ID、AMF UE NGAP ID 以及 NAS PDU 长度。NAS PDU 长度为零或小于预期值时说明 RRC 层透传不完整问题出在空口侧而不是核心网侧。2.3 鉴权、NAS 安全与 Registration AcceptAMF 在确认需要完整鉴权后会先向 AUSF/UDM 发起鉴权向量获取再向终端下发 Authentication Request。5G 的鉴权过程分为 5G-AKA 和 EAP-AKA 两种前者用于 USIM 卡后者多用于物联网卡和非 3GPP 接入。终端收到鉴权请求后用 USIM 里的密钥和算法计算响应值返回给网络网络侧比对成功后AMF 才下发 NAS Security Mode Command激活 NAS 层的加密和完整性保护。5G SA 与 4G 的一个显著差异是NAS SMC 之后还有 AS SMC。gNB 从 AMF 收到 INITIAL CONTEXT SETUP REQUEST其中包含需要激活的 AS 安全上下文。gNB 基于此下发 AS Security Mode Command空口 SRB/DRB 的加密与完整性保护随后生效。到这里终端和网络之间才真正建立了一个可信的注册上下文后续的 Registration Accept 才允许携带核心网参数。Registration Accept 里包含 5G-GUTI、TAI List、allowed NSSAI、registration timer 等关键参数。终端收到后返回 Registration CompleteAMF 侧确认收到即完成注册状态。附着流程走到这里信令面的初始注册就已闭环但用户面还没有可用通道需要继续走 PDU Session Establishment 流程由 AMF 选择 SMF、SMF 选择 UPF 并建立 N3/N4 隧道。2.4 一条完整附着消息链的信令日志切片现网看附着流程我最常用的手段是把 UE 侧或 gNB 侧的信令日志按消息类型做时间排序。下面是从 gNB 侧抓取的一段典型信令切片只保留关键消息名和方向# 用 grep 过滤信令日志中的附着关键消息并按时间排序 grep -E RRCSetupRequest|RRCSetupComplete|InitialUEMessage|AuthenticationRequest|AuthenticationResponse|SecurityModeCommand|SecurityModeComplete|InitialContextSetupRequest|RegistrationAccept trace.log \ | awk {print $2, $3, $NF} | sort -n | head -50参数说明$2和$3在大多数信令追踪工具里对应毫秒级时间戳和消息方向DL/UL$NF是消息名。排序是为了快速确认消息顺序是否符合预期。正常一条初始注册链路应该按“RRCSetupRequest → RRCSetupComplete → InitialUEMessage → AuthenticationRequest → AuthenticationResponse → SecurityModeCommand → SecurityModeComplete → InitialContextSetupRequest → RegistrationAccept”展开如果缺少其中某个环节失败点就锁定在缺消息的前后两侧。提示不要只盯 Registration Accept 是否下发。很多场景下核心网早已下发了 Accept但终端没能收到或没能解码真正的断点可能在 AS SMC 或 RRC 重配置阶段。3. 终端侧前置动作随机接入、preamble 长格式与 T304 定时器3.1 小区选择和 PLMN 选择决定了附着起点终端开机后并不是直接找一个最强信号的小区接入。它先从 USIM 里读出 EHPLMN、HPLMN、OPLMN 等信息再扫描频点把扫描到的小区与用户选择的 PLMN 做匹配。这一步的优先级顺序是上次驻留小区、等效 PLMN、已注册 PLMN、可用的高优先级 PLMN。SA 终端在搜索时同时扫 FR1 和 FR2 频段但只有小区广播的 SIB1 里配置了cellReservedForOperatorUse标志为 not reserved并且 SIB1 里正确广播了trackingAreaCode终端才可能选择它做附着。这里面有个容易被忽略的参数是q-RxLevMin。终端做小区选择时要求测量到的 RSRP 高于q-RxLevMin q-RxLevMinOffset如果这个值设得过高会出现“明明有 5G 信号但终端始终不发起随机接入”的现象。更隐蔽的是SA 小区开了 TAC 与核心网侧注册区不一致时终端会在 TAU 或注册更新上反复失败表现为附着流程走到半路被回退到 LTE。3.2 RACH 参数与 preamble 长格式的选择逻辑终端确定了要接入的小区后通过 PRACH 发起随机接入。NR 的 preamble 序列分长序列和短序列两大类长序列格式共有 4 种Format 0/1/2/3短序列格式有 A1/A2/A3/B1/B2/B3/B4/C0/C2 等 9 种。长格式覆盖半径大适合低频大站短格式适合小间距、高速移动和波束扫描场景。gNB 通过 SIB1 里的prach-ConfigurationIndex和msg1-FDM、msg1-FrequencyStart来广播具体的时频资源配置。SIB1 中常见的 RACH 配置片段UE 侧解析后 prach-ConfigurationIndex: 2 msg1-FDM: 4 msg1-FrequencyStart: 0 zeroCorrelationZoneConfig: 5 preambleReceivedTargetPower: -100这段配置的含义prach-ConfigurationIndex2表示随机接入机会的时域密度较高适合小区用户数较多的场景msg1-FDM4说明在频域上复用了 4 个 PRACH 传输机会preambleReceivedTargetPower-100是 gNB 期望收到的前导码目标功率终端会根据路损估计自行抬高发射功率。现场经常遇到的“RACH 接入成功率低”问题多半不是终端故障而是zeroCorrelationZoneConfig设置和小区覆盖半径不匹配导致多个终端在同一 PRACH 资源上用高相关性的 preamble 互相冲突。3.3 与附着流程强相关的 3 个定时器RACH 阶段涉及的定时器里T304 常被单独拿出来讨论是因为它直接决定切换和重建失败后的行为。T304 在终端收到 RRCReconfiguration携带同步重配或切换命令时启动在随机接入成功后停止超时则视为切换失败终端回退到源小区并触发 RRC 重建。附着流程里初始随机接入不使用 T304用的是 T300——RRCSetupRequest 发出后等待 RRCSetup 的定时器以及 T3502——注册失败后等待下次发起注册的定时器。定时器启动条件超时行为对附着的影响T300发送 RRCSetupRequest进入 RRC_IDLE重新选小区初始 RRC 建立失败附着流程无法开始T304收到带 sync 的重配/切换命令RRC 重建流程切换场景的附着中断PDU 会话可能被释放T3502注册失败或拒绝后等待期满后允许再次注册控制终端反复注册的节流周期过短会造成信令风暴从附着流程角度理解这三个定时器T300 管的是流程能不能启动T304 管的是流程进行中如果发生切换是否能在目标小区顺利续上T3502 管的是失败后终端什么时候才被允许重试。排障时如果看到终端每隔固定周期又发起一次注册大概率是 T3502 保护下的周期性重试而不是终端在“疯狂拨号”。4. 核心网侧注册流程AMF 选择、5G-AKA 与 NSSAI 协商的失败定位4.1 AMF 重选与终端上下文建立INITIAL UE MESSAGE 到达 AMF 后AMF 首先解码 NAS 消息里的注册类型和终端标识。当终端发出的是初始注册请求且 AMF 判断这是新的 UE 时核心网侧开始建立一个逻辑上的 UE Context。这个上下文的载体就是AMF UE NGAP ID从第一个消息开始贯穿整条 N2 链路直到UE Context Release Command出现才释放。如果终端携带了 5G-GUTI但目标 AMF 发现 GUAMI 指向的是另一个 AMF它会通过 Namf_Communication 服务向源 AMF 发起 UE context transfer把终端的注册上下文、安全上下文、PDU session 等相关信息拉取过来。这个机制叫 AMF 间切换常见于跨 AMF Set 的移动性注册更新场景。排障时遇到“每次 TA 更新都在完整重鉴权”原因大概率是源 AMF 未能成功完成上下文转发目标 AMF 只能退化为完整初始注册。AMF 决定接受注册后会向 gNB 下发INITIAL CONTEXT SETUP REQUEST。注意这条消息的时机必须在 NAS SMC 完成后因为 gNB 需要用它携带的密钥参数做 AS 安全激活。有些厂商实现里会把 Registration Accept 和 Initial Context Setup Request 打包下发这样终端收到 Accept 时AS 安全上下文也同时就绪空口承载可以立即进入数据服务阶段。4.2 鉴权请求与 5G-AKA 的关键参数顺序5G-AKA 的鉴权流程不是一次性完成。AMF 向 AUSF 发起鉴权请求时需要先拿到 SUPI 或者从 SUCI 解密得到 SUPI。这个过程依赖 UDM 里保存的签约数据如果终端 SIM 卡里没有对应的 5G 签约或密钥算法不匹配UDM 会返回鉴权数据获取失败。这里的关键点是SUCI 加密保护方案可以是 null-scheme也可以是 ECIES 椭圆曲线加密运营商网络侧维持 null-scheme 是为了兼容老终端但 null-scheme 下 SUPI 在空口是明文暴露的排查安全问题时需要确认 USER CONCEALED IDENTITY 里的保护方案标识。鉴权成功后AMF 下发Authentication Request携带 RAND 和 AUTN。终端侧 USIM 会先验证 AUTN 里的 MAC 和 SQN 序列号范围AUTN 校验不通过时终端直接回Authentication Failure并且携带CAUSE21SYNCH failure。这个 21 号原因值在现网中出现频率不低常见根因是核心网侧 SQN 和终端 USIM 里的序列号偏移超限。处理办法不是换卡而是让核心网侧做重同步ResynchronizationUE 在失败消息里会携带auts参数供网络侧重新对齐序列号。# 解析终端回送的 Authentication Failure 里的 5GMM cause # 典型日志片段演示原因值判断逻辑 failure { cause: 21, # 5GMM cause21 SYNCH failure auts: 6a2f9c..., # 重同步参数存在时表示需要重同步 ngKsi: 1 # NAS key set identifier } if failure[cause] 21 and failure[auts]: print(detect SQN mismatch, resync UDM/ARPF by auts) elif failure[cause] 23: print(authentication failure: MAC mismatch check USIM key)这段代码对应的是排障人员根据日志里 Authentication Failure 的原因值做根因分支判断的常见做法21 号原因代表 SQN 失步依赖 auts 参数重同步23 号则是 MAC 不匹配问题集中在 USIM 里的根密钥 K 与核心网侧 Ki 不一致。注意这不是直接可用的现网工具但展示了原因值→处理动作的映射逻辑。4.3 NSSAI 协商和 Registration Accept 参数5G SA 附着与 4G 最大的差异体现在网络切片协商。终端在 Registration Request 里携带requested NSSAIAMF 根据 UDM 中的签约 NSSAI 以及本地的切片准入策略决定最终允许哪些 S-NSSAI 接入并通过allowed NSSAI下发给终端。每个 S-NSSAI 由 SSTSlice/Service Type和可选 SD 组成SST 为数值型例如 1 代表 eMBB、2 代表 URLLC、3 代表 MIoT。如果终端请求的 NSSAI 里包含核心网不认可或不签约的切片AMF 不会直接拒绝整个注册而会把允许的 NSSAI 子集下发给终端同时通过rejected NSSAI告知哪些切片被拒。终端拿到被拒的切片后在同一个 TAI 或 PLMN 内不会再次请求。现网里常见的问题是 5G 终端显示 5G 图标却打不开业务打开信令一看requested NSSAI 里第一个 S-NSSAI 的 SST 值与该运营商默认承载的切片不一致导致终端被允许注册但所有 PDU Session 建立请求都被 SMF 拒绝。Registration Accept 里还包含一个容易被忽略的equivalent PLMN列表和T3502值。终端进入漫游状态时会依据 equivalent PLMN 做网络重选T3502 则控制注册失败后的重试时延。如果核心网把 T3502 配得过长终端在附着失败后长时间不重试用户体验就是“有信号但注册不上”配得过短则终端反复发起注册造成核心网信令面拥塞。5. 用日志锚点快速判断附着流程卡在哪一步5.1 五类锚点消息对应的问题区间处理 5G 全网排障时我习惯先把端到端注册流程压缩成 4 个逻辑断点每个断点对应一组可检索的信令锚点断点锚点消息问题区间断点 1RRCSetupRequest / RRCSetupComplete空口覆盖、随机接入、T300 超时、干扰断点 2INITIAL UE MESSAGE / DL NAS TRANSPORTgNB-AMF 路由、NG 接口、AMF 过载断点 3Authentication Request / CompleteUSIM 卡、AUTN、SQN、密钥不一致断点 4Security Mode Complete / Registration Accept安全算法协商、NSSAI 准入、UDM 签约判断方法很简单从日志里筛出这四组锚点看最后一条成功消息落在哪一行。最后成功消息在断点 1说明空口接入都还没完成不用去查核心网最后成功消息在断点 3说明问题大概率出在鉴权向量计算或 SIM 卡侧和基站参数没有关系。5.2 用时间戳做流程区段计时定位到具体断点后下一步是看每个区段消耗的时间。注册流程的整体时延对用户体验感知最强的是“从 RRCSetupComplete 到 Registration Accept”这段正常应在几百毫秒内完成。如果某个区段耗时异常用下面的命令做分段耗时统计# 提取关键锚点时间并计算相邻锚点之间的间隔毫秒 awk /RRCSetupComplete|InitialUEMessage|AuthenticationRequest|SecurityModeComplete|RegistrationAccept/ { if (match($0, /time([0-9])/, m)) { msg $NF; t m[1]; if (prev_msg ! ) { printf %s - %s: %d ms\n, prev_msg, msg, t - prev_t; } prev_msg msg; prev_t t; } } trace.log这段脚本从日志中提取每条锚点消息里的time字段并顺次计算相邻锚点间的间隔。实际使用时日志格式不同需要调整time的匹配方式但核心思路是通用的把“端到端注册总时延”拆成“空口接入 核心网鉴权 安全激活 接受下发”四段哪段耗时长就说明哪段所在的网元是瓶颈。5.3 一个固化的技能点把失败码映射到流程阶段最后分享一个日常处理附着类工单时很好用的小技巧就是维护一张自己的“原因值映射表”。5GMM cause 和 RRC release cause 种类繁多但 90% 的附着失败原因集中在少数几个值上5GMM cause #3Illegal UE大多指向 USIM 卡或终端被列入黑名单#6Illegal ME指向 IMEI 拦截#75G services not allowed说明该签约不允许 5G 接入#11PLMN not allowed指向 RORE/PRM 参数限制。把这些值做成告警关键词写入监控平台每条告警自动关联到本文第二、三章的对应环节比每次翻协议查 3GPP 24.501 快得多。实际做网优和核心网对接时真正有用的不是背下一整套标准流程而是建立“信号消息 → 问题网元 → 配置参数”的反射式映射。终端附着失败的工单八成因由一条消息定位到前一个网元的某个配置项——要么是 T304 设短了要么是 requested NSSAI 没对齐要么是鉴权向量算错。记住5G SA 的附着流程是标准化的但每个环节都允许你通过参数把它“调坏”排障的本事就在于你有能力按链路逐段排除而不是靠重启大法。本文还有配套的精品资源点击获取 5G NR SA注册流程详解：从RRC建立到Registration Complete的信令拆解
简介一份专门梳理5G NR独立组网SA终端附着完整信令流程的docx文档主要面向5G网络优化工程师、通信技术支持人员以及刚入门SA信令的网优学习者。文档以空口OTA消息时序图为骨架完整覆盖UE从接收SSBPSS/SSS/MIB完成下行同步读取SIB1与其它SIB获取系统配置通过PRACH发送随机接入前导Msg1接收Msg2随机接入响应、Msg3 RRC Setup Request、Msg4 RRC Setup再到RRC Setup Complete携带NAS Registration Request随后依次经历身份请求/响应、鉴权、安全模式命令及完成最终由RRC Reconfiguration下发Registration Accept完成PDU Session建立的整个流程。每一步都标注了消息方向、对应信道及关键参数如RA-RNTI、T-C-RNTI、C-RNTI同时说明HARQ ACK/NACK在PDSCH/PUSCH传输中的保障作用。资源为1个docx文件整体仅127KB内容精炼可配合Amarisoft等日志工具直接对照分析。目前已有428人学习适合用于5G接入失败排查、信令流程培训和日常网优参考。1. 5G NR SA 里的“附着”注册流程为何值得你逐段拆开把 5G 终端在 SA 基站下开机、入网、建立会话这件事摊开你看到的不是一个“附着”动作而是一串跨越终端、基站、核心网的消息编排。4G 时代叫 Attach5G SA 里它被拆成 Registration初始注册与 PDU Session Establishment会话建立两段流程前者负责身份认证和网络可达后者负责用户面数据通路。正因为 SA 没有锚点网元替你兜底消息链上任何一段失败都会让终端反复新建 RRC 连接表现为“有信号但上不了网”。这篇文章不讨论网优指标只把 NG-RAN 和 5GC 之间的 N1/N2/N3 链路按真实流程逐段拆开从 RACH 的 preamble 格式选择到 AMF 的鉴权与 NSSAI 协商最后落在信令日志的排障锚点上。无论你是在实验室调基站、在核心网侧看注册成功率还是处理“5G 信号满格却无法注册”的工单这套流程拆解都能直接对应到信令平面上的某一条消息。2. SA 终端附着消息链路从 RRC 建立到 Registration Complete 的主要流程2.1 RRC 层交付附着流程的第一段承载终端在 SA 小区上的附着流程第一步与 LTE 相同点在于都要先完成 RRC 建立但 5G NR 里 RRC 建立所承载的意义变了。RRCSetupRequest 里使用 InitialUE-Identity 区分终端如果终端有 5G-S-TMSI就用这个临时标识如果是开机首次发起或 TMSI 不可用就填一个来自高层的随机值。gNB 看到随机值时就知道这是一次初始注册后续会触发完整的鉴权流程。RRCSetupComplete 消息里会携带 NAS 层的第一条关键消息——Registration Request。这条消息附着在 RRC 之上通过 SRB2 之前的 SRB1 传递包含 SUCI 或 5G-GUTI、requested NSSAI、UE 的 5GMM 能力、PDU session 状态等。gNB 在这里扮演的角色只是透传它从 RRCSetupComplete 里取出 NAS PDU再封装到 NGAP 的 INITIAL UE MESSAGE 里往核心网侧转发。这一环节最常见的失败点是 RRCSetup 之后终端一直不反馈 RRCSetupComplete或者反馈了但 gNB 侧解析不到完整的 NAS PDU。排查方向通常集中在 T300 超时、SRB1 的 RLC 配置异常以及终端和基站之间的安全能力不匹配。注意SRB1 在 RRCSetup 之后就建立完成但 NAS 信令此时仍未加密完整性保护也要等到后面 NAS SMC 完成后才生效。2.2 注册消息进入核心网INITIAL UE MESSAGE 与 AMF 选择INITIAL UE MESSAGE 是 NGAP 层的第一跳消息它把 RRCSetupComplete 里的 NAS PDU 原样搬到核心网。gNB 在发送这条消息前必须先选定一个 AMF。选 AMF 的逻辑依据是 gNB 本地配置的 AMF Set、终端携带的 5G-GUTI 中的 GUAMI 信息以及 requested NSSAI 对应的切片可用性。终端如果携带了有效的 5G-GUTIgNB 会优先把消息路由到 GUAMI 指向的 AMF这样可以做到跨 AMF 的上下文关联。AMF 收到 INITIAL UE MESSAGE 之后开始做注册类型判断initial registration、mobility registration update、periodic registration update 三种类型决定了后续是否要做完整鉴权。终端在 Registration Request 里如果有 PDU session status 信息AMF 还会据此判断哪些会话需要重建或移交到新的 SMF。这里要提醒一点AMF 选择错误导致的消息路由风暴经常被误判成终端问题。对于现网排查我一般会在 gNB 和 AMF 之间抓 NGAP 消息重点看 INITIAL UE MESSAGE 里的 RAN UE NGAP ID、AMF UE NGAP ID 以及 NAS PDU 长度。NAS PDU 长度为零或小于预期值时说明 RRC 层透传不完整问题出在空口侧而不是核心网侧。2.3 鉴权、NAS 安全与 Registration AcceptAMF 在确认需要完整鉴权后会先向 AUSF/UDM 发起鉴权向量获取再向终端下发 Authentication Request。5G 的鉴权过程分为 5G-AKA 和 EAP-AKA 两种前者用于 USIM 卡后者多用于物联网卡和非 3GPP 接入。终端收到鉴权请求后用 USIM 里的密钥和算法计算响应值返回给网络网络侧比对成功后AMF 才下发 NAS Security Mode Command激活 NAS 层的加密和完整性保护。5G SA 与 4G 的一个显著差异是NAS SMC 之后还有 AS SMC。gNB 从 AMF 收到 INITIAL CONTEXT SETUP REQUEST其中包含需要激活的 AS 安全上下文。gNB 基于此下发 AS Security Mode Command空口 SRB/DRB 的加密与完整性保护随后生效。到这里终端和网络之间才真正建立了一个可信的注册上下文后续的 Registration Accept 才允许携带核心网参数。Registration Accept 里包含 5G-GUTI、TAI List、allowed NSSAI、registration timer 等关键参数。终端收到后返回 Registration CompleteAMF 侧确认收到即完成注册状态。附着流程走到这里信令面的初始注册就已闭环但用户面还没有可用通道需要继续走 PDU Session Establishment 流程由 AMF 选择 SMF、SMF 选择 UPF 并建立 N3/N4 隧道。2.4 一条完整附着消息链的信令日志切片现网看附着流程我最常用的手段是把 UE 侧或 gNB 侧的信令日志按消息类型做时间排序。下面是从 gNB 侧抓取的一段典型信令切片只保留关键消息名和方向# 用 grep 过滤信令日志中的附着关键消息并按时间排序 grep -E RRCSetupRequest|RRCSetupComplete|InitialUEMessage|AuthenticationRequest|AuthenticationResponse|SecurityModeCommand|SecurityModeComplete|InitialContextSetupRequest|RegistrationAccept trace.log \ | awk {print $2, $3, $NF} | sort -n | head -50参数说明$2和$3在大多数信令追踪工具里对应毫秒级时间戳和消息方向DL/UL$NF是消息名。排序是为了快速确认消息顺序是否符合预期。正常一条初始注册链路应该按“RRCSetupRequest → RRCSetupComplete → InitialUEMessage → AuthenticationRequest → AuthenticationResponse → SecurityModeCommand → SecurityModeComplete → InitialContextSetupRequest → RegistrationAccept”展开如果缺少其中某个环节失败点就锁定在缺消息的前后两侧。提示不要只盯 Registration Accept 是否下发。很多场景下核心网早已下发了 Accept但终端没能收到或没能解码真正的断点可能在 AS SMC 或 RRC 重配置阶段。3. 终端侧前置动作随机接入、preamble 长格式与 T304 定时器3.1 小区选择和 PLMN 选择决定了附着起点终端开机后并不是直接找一个最强信号的小区接入。它先从 USIM 里读出 EHPLMN、HPLMN、OPLMN 等信息再扫描频点把扫描到的小区与用户选择的 PLMN 做匹配。这一步的优先级顺序是上次驻留小区、等效 PLMN、已注册 PLMN、可用的高优先级 PLMN。SA 终端在搜索时同时扫 FR1 和 FR2 频段但只有小区广播的 SIB1 里配置了cellReservedForOperatorUse标志为 not reserved并且 SIB1 里正确广播了trackingAreaCode终端才可能选择它做附着。这里面有个容易被忽略的参数是q-RxLevMin。终端做小区选择时要求测量到的 RSRP 高于q-RxLevMin q-RxLevMinOffset如果这个值设得过高会出现“明明有 5G 信号但终端始终不发起随机接入”的现象。更隐蔽的是SA 小区开了 TAC 与核心网侧注册区不一致时终端会在 TAU 或注册更新上反复失败表现为附着流程走到半路被回退到 LTE。3.2 RACH 参数与 preamble 长格式的选择逻辑终端确定了要接入的小区后通过 PRACH 发起随机接入。NR 的 preamble 序列分长序列和短序列两大类长序列格式共有 4 种Format 0/1/2/3短序列格式有 A1/A2/A3/B1/B2/B3/B4/C0/C2 等 9 种。长格式覆盖半径大适合低频大站短格式适合小间距、高速移动和波束扫描场景。gNB 通过 SIB1 里的prach-ConfigurationIndex和msg1-FDM、msg1-FrequencyStart来广播具体的时频资源配置。SIB1 中常见的 RACH 配置片段UE 侧解析后 prach-ConfigurationIndex: 2 msg1-FDM: 4 msg1-FrequencyStart: 0 zeroCorrelationZoneConfig: 5 preambleReceivedTargetPower: -100这段配置的含义prach-ConfigurationIndex2表示随机接入机会的时域密度较高适合小区用户数较多的场景msg1-FDM4说明在频域上复用了 4 个 PRACH 传输机会preambleReceivedTargetPower-100是 gNB 期望收到的前导码目标功率终端会根据路损估计自行抬高发射功率。现场经常遇到的“RACH 接入成功率低”问题多半不是终端故障而是zeroCorrelationZoneConfig设置和小区覆盖半径不匹配导致多个终端在同一 PRACH 资源上用高相关性的 preamble 互相冲突。3.3 与附着流程强相关的 3 个定时器RACH 阶段涉及的定时器里T304 常被单独拿出来讨论是因为它直接决定切换和重建失败后的行为。T304 在终端收到 RRCReconfiguration携带同步重配或切换命令时启动在随机接入成功后停止超时则视为切换失败终端回退到源小区并触发 RRC 重建。附着流程里初始随机接入不使用 T304用的是 T300——RRCSetupRequest 发出后等待 RRCSetup 的定时器以及 T3502——注册失败后等待下次发起注册的定时器。定时器启动条件超时行为对附着的影响T300发送 RRCSetupRequest进入 RRC_IDLE重新选小区初始 RRC 建立失败附着流程无法开始T304收到带 sync 的重配/切换命令RRC 重建流程切换场景的附着中断PDU 会话可能被释放T3502注册失败或拒绝后等待期满后允许再次注册控制终端反复注册的节流周期过短会造成信令风暴从附着流程角度理解这三个定时器T300 管的是流程能不能启动T304 管的是流程进行中如果发生切换是否能在目标小区顺利续上T3502 管的是失败后终端什么时候才被允许重试。排障时如果看到终端每隔固定周期又发起一次注册大概率是 T3502 保护下的周期性重试而不是终端在“疯狂拨号”。4. 核心网侧注册流程AMF 选择、5G-AKA 与 NSSAI 协商的失败定位4.1 AMF 重选与终端上下文建立INITIAL UE MESSAGE 到达 AMF 后AMF 首先解码 NAS 消息里的注册类型和终端标识。当终端发出的是初始注册请求且 AMF 判断这是新的 UE 时核心网侧开始建立一个逻辑上的 UE Context。这个上下文的载体就是AMF UE NGAP ID从第一个消息开始贯穿整条 N2 链路直到UE Context Release Command出现才释放。如果终端携带了 5G-GUTI但目标 AMF 发现 GUAMI 指向的是另一个 AMF它会通过 Namf_Communication 服务向源 AMF 发起 UE context transfer把终端的注册上下文、安全上下文、PDU session 等相关信息拉取过来。这个机制叫 AMF 间切换常见于跨 AMF Set 的移动性注册更新场景。排障时遇到“每次 TA 更新都在完整重鉴权”原因大概率是源 AMF 未能成功完成上下文转发目标 AMF 只能退化为完整初始注册。AMF 决定接受注册后会向 gNB 下发INITIAL CONTEXT SETUP REQUEST。注意这条消息的时机必须在 NAS SMC 完成后因为 gNB 需要用它携带的密钥参数做 AS 安全激活。有些厂商实现里会把 Registration Accept 和 Initial Context Setup Request 打包下发这样终端收到 Accept 时AS 安全上下文也同时就绪空口承载可以立即进入数据服务阶段。4.2 鉴权请求与 5G-AKA 的关键参数顺序5G-AKA 的鉴权流程不是一次性完成。AMF 向 AUSF 发起鉴权请求时需要先拿到 SUPI 或者从 SUCI 解密得到 SUPI。这个过程依赖 UDM 里保存的签约数据如果终端 SIM 卡里没有对应的 5G 签约或密钥算法不匹配UDM 会返回鉴权数据获取失败。这里的关键点是SUCI 加密保护方案可以是 null-scheme也可以是 ECIES 椭圆曲线加密运营商网络侧维持 null-scheme 是为了兼容老终端但 null-scheme 下 SUPI 在空口是明文暴露的排查安全问题时需要确认 USER CONCEALED IDENTITY 里的保护方案标识。鉴权成功后AMF 下发Authentication Request携带 RAND 和 AUTN。终端侧 USIM 会先验证 AUTN 里的 MAC 和 SQN 序列号范围AUTN 校验不通过时终端直接回Authentication Failure并且携带CAUSE21SYNCH failure。这个 21 号原因值在现网中出现频率不低常见根因是核心网侧 SQN 和终端 USIM 里的序列号偏移超限。处理办法不是换卡而是让核心网侧做重同步ResynchronizationUE 在失败消息里会携带auts参数供网络侧重新对齐序列号。# 解析终端回送的 Authentication Failure 里的 5GMM cause # 典型日志片段演示原因值判断逻辑 failure { cause: 21, # 5GMM cause21 SYNCH failure auts: 6a2f9c..., # 重同步参数存在时表示需要重同步 ngKsi: 1 # NAS key set identifier } if failure[cause] 21 and failure[auts]: print(detect SQN mismatch, resync UDM/ARPF by auts) elif failure[cause] 23: print(authentication failure: MAC mismatch check USIM key)这段代码对应的是排障人员根据日志里 Authentication Failure 的原因值做根因分支判断的常见做法21 号原因代表 SQN 失步依赖 auts 参数重同步23 号则是 MAC 不匹配问题集中在 USIM 里的根密钥 K 与核心网侧 Ki 不一致。注意这不是直接可用的现网工具但展示了原因值→处理动作的映射逻辑。4.3 NSSAI 协商和 Registration Accept 参数5G SA 附着与 4G 最大的差异体现在网络切片协商。终端在 Registration Request 里携带requested NSSAIAMF 根据 UDM 中的签约 NSSAI 以及本地的切片准入策略决定最终允许哪些 S-NSSAI 接入并通过allowed NSSAI下发给终端。每个 S-NSSAI 由 SSTSlice/Service Type和可选 SD 组成SST 为数值型例如 1 代表 eMBB、2 代表 URLLC、3 代表 MIoT。如果终端请求的 NSSAI 里包含核心网不认可或不签约的切片AMF 不会直接拒绝整个注册而会把允许的 NSSAI 子集下发给终端同时通过rejected NSSAI告知哪些切片被拒。终端拿到被拒的切片后在同一个 TAI 或 PLMN 内不会再次请求。现网里常见的问题是 5G 终端显示 5G 图标却打不开业务打开信令一看requested NSSAI 里第一个 S-NSSAI 的 SST 值与该运营商默认承载的切片不一致导致终端被允许注册但所有 PDU Session 建立请求都被 SMF 拒绝。Registration Accept 里还包含一个容易被忽略的equivalent PLMN列表和T3502值。终端进入漫游状态时会依据 equivalent PLMN 做网络重选T3502 则控制注册失败后的重试时延。如果核心网把 T3502 配得过长终端在附着失败后长时间不重试用户体验就是“有信号但注册不上”配得过短则终端反复发起注册造成核心网信令面拥塞。5. 用日志锚点快速判断附着流程卡在哪一步5.1 五类锚点消息对应的问题区间处理 5G 全网排障时我习惯先把端到端注册流程压缩成 4 个逻辑断点每个断点对应一组可检索的信令锚点断点锚点消息问题区间断点 1RRCSetupRequest / RRCSetupComplete空口覆盖、随机接入、T300 超时、干扰断点 2INITIAL UE MESSAGE / DL NAS TRANSPORTgNB-AMF 路由、NG 接口、AMF 过载断点 3Authentication Request / CompleteUSIM 卡、AUTN、SQN、密钥不一致断点 4Security Mode Complete / Registration Accept安全算法协商、NSSAI 准入、UDM 签约判断方法很简单从日志里筛出这四组锚点看最后一条成功消息落在哪一行。最后成功消息在断点 1说明空口接入都还没完成不用去查核心网最后成功消息在断点 3说明问题大概率出在鉴权向量计算或 SIM 卡侧和基站参数没有关系。5.2 用时间戳做流程区段计时定位到具体断点后下一步是看每个区段消耗的时间。注册流程的整体时延对用户体验感知最强的是“从 RRCSetupComplete 到 Registration Accept”这段正常应在几百毫秒内完成。如果某个区段耗时异常用下面的命令做分段耗时统计# 提取关键锚点时间并计算相邻锚点之间的间隔毫秒 awk /RRCSetupComplete|InitialUEMessage|AuthenticationRequest|SecurityModeComplete|RegistrationAccept/ { if (match($0, /time([0-9])/, m)) { msg $NF; t m[1]; if (prev_msg ! ) { printf %s - %s: %d ms\n, prev_msg, msg, t - prev_t; } prev_msg msg; prev_t t; } } trace.log这段脚本从日志中提取每条锚点消息里的time字段并顺次计算相邻锚点间的间隔。实际使用时日志格式不同需要调整time的匹配方式但核心思路是通用的把“端到端注册总时延”拆成“空口接入 核心网鉴权 安全激活 接受下发”四段哪段耗时长就说明哪段所在的网元是瓶颈。5.3 一个固化的技能点把失败码映射到流程阶段最后分享一个日常处理附着类工单时很好用的小技巧就是维护一张自己的“原因值映射表”。5GMM cause 和 RRC release cause 种类繁多但 90% 的附着失败原因集中在少数几个值上5GMM cause #3Illegal UE大多指向 USIM 卡或终端被列入黑名单#6Illegal ME指向 IMEI 拦截#75G services not allowed说明该签约不允许 5G 接入#11PLMN not allowed指向 RORE/PRM 参数限制。把这些值做成告警关键词写入监控平台每条告警自动关联到本文第二、三章的对应环节比每次翻协议查 3GPP 24.501 快得多。实际做网优和核心网对接时真正有用的不是背下一整套标准流程而是建立“信号消息 → 问题网元 → 配置参数”的反射式映射。终端附着失败的工单八成因由一条消息定位到前一个网元的某个配置项——要么是 T304 设短了要么是 requested NSSAI 没对齐要么是鉴权向量算错。记住5G SA 的附着流程是标准化的但每个环节都允许你通过参数把它“调坏”排障的本事就在于你有能力按链路逐段排除而不是靠重启大法。本文还有配套的精品资源点击获取