简介这份文档面向5G网络优化工程师及备考5G中级认证的技术人员系统梳理了5G信令流程的核心知识点帮助读者理解UE与网络交互的关键环节解决注册、鉴权、随机接入等流程中的原理性困惑。资源包内含1个docx文档大小约316KB内容以文字讲解为主结构清晰便于查阅。文档围绕注册流程展开涵盖Registration Request携带的注册类型、SUCI或5G-GUTI、NSSAI、PDU会话状态、MICO模式首选项及DRX参数等主要参数并深入解析SUPI与SUCI的加密机制、PEI设备标识以及5G-GUTI缺失对注册的影响。随机接入部分则说明其目的、六类触发事件、基于竞争与非竞争两种方式的适用场景以及preamble发送、RAR接收等步骤要点。目前已有225人学习适合需要夯实信令基础、排查接入问题或进行性能调优的从业者参考。1. 5G中级认证里的信令流程一份能对着抓包逐条核对的文档做5G网络优化的人迟早会遇到一个尴尬时刻现场基站状态正常、终端也显示5G图标但用户就是上不了网或者注册反复失败。这时候如果只会看KPI指标基本等于抓瞎。真正能定位问题的是能把UE从发Registration Request到鉴权完成这条链路逐条拆开看。这份《5G中级认证-5G信令流程.docx》就是干这个用的——它把注册流程、随机接入、5G AKA鉴权三大块的信令交互和关键参数整理成了可以对着抓包核对的材料。适合正在备考5G中级认证的网优工程师也适合刚接触5G核心网信令、需要快速建立流程框架的运维人员。它不是协议原文的堆砌而是把TS 33.501、TS 33.102、36.300这些文档里散落的流程串成了一条线。2. 注册流程从Registration Request到鉴权触发参数逐条拆2.1 注册的四种触发场景与消息结构UE要接受服务第一步就是注册到网络。文档里列了四种触发注册的情况初始注册到5G系统、在CM_CONNECTED或CM_IDLE模式下移动到注册区外的TA时发起的移动性注册更新、周期性注册、以及需要更新协商能力和协议参数时的注册。这四种场景对应的Registration Request消息内容有差异但核心参数集是共通的。Registration Request通过(R)AN发给AMF携带的AN参数包括注册类型、SUCI或5G-GUTI或PEI、最后访问的TAI如果可用、安全性参数、请求的NSSAI及其映射、UE无线电能力更新、UE MM核心网能力、PDU会话状态、要激活的PDU会话列表、遵循请求、MICO模式首选项、请求的DRX参数以及UE策略容器PSI列表。这些参数不是每个场景都全带比如初始注册必须带SUCI而移动性注册更新优先用5G-GUTI。注册类型决定了后续流程走向。初始注册走完整鉴权移动性注册更新如果5G-GUTI有效且AMF没变可能跳过鉴权。这里有个容易翻车的点如果Registration Request里既没有5G-GUTI或者(R)AN认为AMF-RNTI无效网络就会走Identity Request流程向UE要SUCI。很多现场注册失败就是卡在这一步——UE回了SUCI但AMF侧解密失败或者UE根本没收到Identity Request。2.2 SUCI与SUPI加密身份的处理边界5G里终端的真实身份叫SUPI类似4G的IMSI。但SUPI不能明文在空中接口传所以用USIM里的公钥加密后变成SUCI再发。SUCI传到基站后基站直接上传核心网解密只在UDM里执行而且解密算法只能执行一次。这个设计比4G的明文IMSI上报安全得多但也有代价。文档里特别提到UE收到Identity Request后不会再发明文SUPI而是发加密的SUCI除非网络明确允许Null-Scheme不加密。SUCI上报频率没有硬性规定但要求每次发送的SUCI都是新鲜且随机的。这里有个安全边界值得注意——伪基站可以不断要求手机发送SUCI虽然拿不到明文SUPI但会导致手机电力消耗甚至发起DoS攻击。做网络优化时如果发现某片区终端耗电异常可以排查是否存在异常Identity Request频繁触发。PEI是设备永久标识和SUPI是两回事。PEI标识设备SUPI标识用户。注册消息里如果既没有有效的5G-GUTI也没有PEIAMF无法完成设备识别注册会失败。2.3 用Wireshark抓包核对注册流程的实操步骤理论讲完落到怎么验证。常见做法是在N2接口抓包用Wireshark过滤NGAP和NAS消息。下面是一段过滤和提取关键字段的操作示例# 在核心网N2接口镜像口抓包过滤SCTP承载的NGAP消息 tcpdump -i eth1 -s 0 -w n2_registration.pcap sctp port 38412 # 用Wireshark打开后过滤NAS Registration Request # 显示过滤器输入nas_5gs.mm.message_type 0x41 # 0x41是Registration Request的消息类型码 # 过滤Identity Request/Response # nas_5gs.mm.message_type 0x5b (Identity Request) # nas_5gs.mm.message_type 0x5c (Identity Response) # 过滤Authentication Request/Response # nas_5gs.mm.message_type 0x56 (Authentication Request) # nas_5gs.mm.message_type 0x57 (Authentication Response)这段命令的逻辑是先在N2接口把SCTP上38412端口的流量抓下来然后用Wireshark的显示过滤器按NAS消息类型码逐条定位。参数说明sctp port 38412是NGAP的标准端口nas_5gs.mm.message_type是Wireshark对5GS NAS消息类型的解析字段。实际操作中如果抓不到先确认镜像口是否配对了N2链路以及SCTP是否走了多宿主导致抓包不全。抓到Registration Request后重点看几个字段Registration type初始/移动性/周期、5GS mobile identity是SUCI还是5G-GUTI、Requested NSSAI切片是否匹配。如果Registration Reject里带5GMM cause对照cause值查表基本能定位到是切片不匹配、鉴权失败还是网络拒绝。3. 随机接入流程preamble到Msg4每一步看什么3.1 随机接入的触发条件与两种方式的选择随机接入的目的有两个获得上行同步、为UE分配唯一的C-RNTI。触发条件文档里列了6类来自36.300的10.1.5节初始接入建立无线连接RRC_IDLE到RRC_CONNECTED、RRC连接重建、切换、RRC_CONNECTED态下下行数据到达且上行不同步、上行数据到达且上行不同步或无PUCCH资源传SR、以及定位需要的timing advance。38.300另外补了三条从RRC_INACTIVE状态变化、需要其他SI、beam失败恢复。随机接入分两种方式基于竞争和基于非竞争。基于竞争适用于前5种事件基于非竞争只适用于切换、下行数据到达、定位这三种。选择逻辑很简单——如果UE已经有专用preamble可用比如切换时网络通过RRC信令分配了dedicated preamble就走非竞争否则走竞争需要Msg3和Msg4做冲突解决。这里有个容易混淆的点基于非竞争的随机接入UE必定原本处于RRC_CONNECTED态。因为只有连接态才能通过RRC信令收到dedicated preamble配置。切换场景下UE在目标小区用的C-RNTI是通过RRCConnectionReconfiguration里的MobilityControlInfo的newUE-Identity配的不是随机接入过程中分配的。3.2 四步流程的逐步拆解与参数含义步骤一UE发preamble。Preamble由循环前缀CP和preamble序列组成在PRACH上传输。PRACH频域占6个连续RB。每个小区有64个可用preamble序列UE选一个或由eNodeB指定在PRACH上发。这些序列分两部分一部分用于竞争一部分用于非竞争。竞争用的又分group A和group Bgroup B可能不存在。Group A/B的序列本身没太大区别划分的意义在于告诉基站后续Msg3的资源需求大小。基站通过SIB2广播RACH-ConfigCommon告诉UE preamble分组、Msg3大小阈值、功率配置等信息。UE根据可能的Msg3大小和pathloss选合适的preamble。如果选错了group可能导致Msg3资源不够触发重传。步骤二基站发Random Access Response。UE发完preamble后在RAR时间窗内监听PDCCH接收对应RA-RNTI的RAR。RAR时间窗起始于发送preamble的子帧加3个子帧持续ra-ResponseWindowSize个子帧。如果窗内没收到RAR本次随机接入失败。RAR里带timing advance command、UL grant、临时C-RNTI。步骤三UE发Msg3。只有基于竞争的随机接入才需要Msg3和Msg4。Msg3在UL-SCH上传用HARQRAR里的UL grant指定的TB大小至少80比特。Msg3里必须包含每个UE唯一的标志——C-RNTI或来自核心网的UE标志S-TMSI或随机数。这个标志用于步骤四的冲突解决。步骤四基站发contention resolution。基站在Msg4里携带胜出UE的唯一标志。没胜出的UE重新发起随机接入。3.3 随机接入失败时的排查路径现场遇到随机接入失败按这个顺序查先看PRACH配置是否匹配——prach-ConfigIndex和prach-FreqOffset是否和小区实际配置一致。如果UE发的preamble基站收不到检查PRACH功率配置和pathloss计算。如果基站回了RAR但UE没收到检查RA-RNTI计算和PDCCH聚合等级。如果Msg3发不出去检查UL grant是否够大、HARQ进程是否冲突。如果Msg4冲突解决失败看Msg3里的UE标志是否和核心网侧一致。一个血泪经验切换场景下的随机接入失败很多时候不是无线问题而是目标小区的RACH-ConfigDedicated没配好UE拿不到dedicated preamble只能走竞争但切换场景走竞争又容易和初始接入的UE撞preamble。所以切换前一定要确认目标小区的dedicated RACH配置下发了。4. 5G AKA鉴权归属网络参与决策的关键差异4.1 5G AKA与EPS AKA的核心区别5G AKA和4G的EPS AKA最大的区别在于归属网络是否参与最终鉴权决策。EPS AKA流程里归属网络鉴权中心给访问网络的MME一组鉴权向量和XRES访问网络拿这些参数对UE鉴权归属网络不关心鉴权结果。5G AKA里归属网络鉴权中心给访问网络的安全锚点SEAF和AMF在一起一组5G鉴权向量和对应的HXRES*访问网络用这些参数对UE鉴权后还要把UE的鉴权响应发给归属网络做进一步鉴权归属网络再把结果发回访问网络。这个差异意味着5G下归属网络会参与鉴权并做出最后结果。对网络优化的影响是如果鉴权失败问题可能出在访问网络侧SEAF比较HRES和HXRES失败也可能出在归属网络侧AUSF比较RES和XRES失败。排查时要两边都看。4.2 鉴权向量推导链路从5G HE AV到5G AV文档把向量推导链路写得很细。UDM/ARPF收到Nudm_Authenticate_Get请求后创建5G HE AV。创建时AMF参数的separation bit必须设为0AMF是16bit最高bit是separation bit。然后按TS33.501 Annex A.2推导KAUSF按Annex A.4推导XRES*最后组成5G HE AVRAND、AUTN、XRES*、KAUSF。UDM/ARPF把5G HE AV发给AUSF。如果请求里带SUCI响应里还带SUPI。AUSF暂存XRES和SUCI或SUPI也可存KAUSF备用。然后AUSF创建5G AV按Annex A.5从XRES推导HXRES*按Annex A.6从KAUSF推导KAUSF用HXRES和KAUSF替换5G HE AV里的XRES和KAUSF得到5G AVRAND、AUTN、HXRES*、KAUSF。AUSF把5G AV发给SEAF。注意XRES和KAUSF不会离开归属网络归属网络从这两个参数推导出HXRES和KAUSF给SEAF用。这个设计保证了归属网络的核心鉴权参数不出域。4.3 用日志核对鉴权失败点的实操方法鉴权失败时光看信令流程不够要结合核心网日志定位。下面是一段从AMF和AUSF日志里提取鉴权关键参数的过滤示例# 在AMF日志里过滤鉴权相关条目 grep -E Authentication|ngKSI|HXRES|HRES /var/log/amf/amf.log | tail -100 # 在AUSF日志里过滤向量推导和比较结果 grep -E XRES|RES\*|HXRES|Authentication /var/log/ausf/ausf.log | tail -100 # 关键比对点 # AMF侧HRES* 与 HXRES* 是否相等 # AUSF侧RES* 与 XRES* 是否相等 # 如果AMF侧相等但AUSF侧不等说明UE计算的RES*和归属网络预期的XRES*不一致 # 常见原因USIM卡鉴权算法版本不匹配、AUTN验证失败、AMF separation bit设置错误这段命令的逻辑是分别在AMF和AUSF日志里搜鉴权关键字段然后比对两个比较点的结果。参数说明ngKSI是密钥集标识HXRES*是访问网络侧预期响应哈希HRES*是UE响应哈希XRES*是归属网络侧预期响应。如果AMF侧比较通过但AUSF侧失败重点查USIM卡和UDM的鉴权算法是否一致。如果AMF侧就失败查UE发的RES是否和HXRES匹配常见原因是RAND/AUTN传输过程中出错或ngKSI不匹配。还有一个容易忽略的点UE的ME要检验AUTN的AMF参数separation bit是否为1TS33.102 Annex F。如果UDM创建5G HE AV时separation bit设成了0UE侧检验会失败直接导致鉴权不通过。这个坑在跨厂商组网时特别常见——不同厂商对separation bit的处理不一致。5. 把信令流程用进日常优化三个验证习惯5.1 注册失败的分层排查表注册失败的原因可能出在无线侧、核心网侧或终端侧。下面这张表按信令阶段分层列出每层的检查点和常见原因信令阶段检查点常见失败原因Registration Request发送UE是否发出、参数是否完整SUCI加密失败、5G-GUTI无效、NSSAI不匹配Identity Request/Response网络是否要求SUCI、UE是否回复SUCI解密失败、Null-Scheme未授权AuthenticationRAND/AUTN是否送达、RES*是否匹配separation bit错误、USIM算法不匹配、ngKSI冲突Security ModeNAS安全上下文是否建立密钥推导失败、算法不支持Registration Accept网络是否接受、cause值切片拒绝、AMF容量不足、TAI不在注册区这张表的用法是抓到完整信令后看流程停在哪一步然后查对应行的检查点。比如流程停在Authentication Request之后没有Response查UE侧是否收到RAND/AUTN、USIM是否正常工作。如果流程走到Registration Reject看5GMM cause值对照表定位是切片问题还是鉴权问题。5.2 随机接入成功率低的现场核查清单随机接入成功率低是网优常见问题。按这个清单逐项核查PRACH配置是否和规划一致prach-ConfigIndex、prach-FreqOffset、根序列索引preamble格式是否匹配小区半径format 0/1/2/3对应不同覆盖功率配置是否合理preambleInitialReceivedTargetPower、powerRampingStepRAR时间窗是否够大ra-ResponseWindowSizeMsg3的UL grant是否满足业务需求冲突解决定时器是否合理mac-ContentionResolutionTimer。一个实际案例某小区随机接入成功率突然从99%掉到85%查配置发现prach-ConfigIndex被误改导致PRACH时频资源和邻区冲突UE发的preamble被邻区基站收到并回复了错误的RAR。改回原配置后恢复正常。这个坑的教训是PRACH配置变更一定要做邻区协调不能只看单小区。5.3 鉴权失败时归属网络与访问网络的联合定位鉴权失败不能只看一边。联合定位的步骤是先在AMF侧确认HRES和HXRES的比较结果如果失败说明UE计算的RES和访问网络预期的HXRES不匹配问题可能在UE侧或RAND/AUTN传输。如果AMF侧通过但AUSF侧失败说明UE计算的RES和归属网络预期的XRES不匹配问题可能在USIM卡或UDM的鉴权算法。实际操作中我一般会同时开AMF和AUSF的调试日志用同一个SUCI或SUPI关联两边的记录。如果两边日志时间戳对不上先查NTP同步——核心网网元时间不同步会导致日志关联困难白白浪费排查时间。从那以后我每次做鉴权排查前都强制走一遍时间同步检查希望帮到你。本文还有配套的精品资源点击获取
