简介这份文档面向5G网络优化工程师及备考5G中级认证的技术人员系统梳理了5G信令流程的核心知识点帮助读者理解UE与网络交互的完整过程解决注册、鉴权、随机接入等环节中的原理性困惑。资源包内含1个docx文件大小约316KB内容以文字讲解为主结构清晰便于按主题查阅。文档重点覆盖注册流程的触发条件与Registration Request携带参数SUPI与SUCI的加密机制及隐私保护设计PEI设备标识的作用以及随机接入的目的、触发事件、竞争与非竞争两种方式并详细说明preamble发送与RAR响应等步骤。目前已有225人学习适合需要夯实信令基础、排查接入类故障或准备认证考试的网络优化人员参考。1. 5G中级认证里的信令流程从AKA鉴权到注册落地的全链路拆解做5G中级认证的人绕不开一道坎信令流程。不是背不下来而是背下来了也不知道每条消息在现网里对应什么动作。我见过太多人把注册流程的十几条信令画成流程图但一问“AKA鉴权在哪一步触发”“SUCI和SUPI什么时候切换”“Registration Request里的5GMM能力字段到底影响什么”就卡住了。这篇笔记就是冲着这个痛点来的——把5G中级认证里信令流程这条线从鉴权向量生成、UE发起注册、到AMF完成认证和NAS安全模式一步步拆到能对着pcap包复现的程度。适合正在备考5G中级认证的网优、核心网运维以及需要看懂5G协议栈信令的测试工程师。读完你至少能做到拿到一段注册流程的抓包能逐条标出每条NAS/RRC消息的作用、关键IE和常见异常点。2. 注册流程全景从RRC连接到Registration Accept的九步拆解2.1 为什么注册流程是5G信令的“主干道”5G信令流程里注册Registration是UE进入网络后的第一条完整信令链路也是中级认证考试里出现频率最高的场景。它串联了RRC层、NAS层、NGAP层和核心网内部接口任何一环出问题UE就停在“无服务”或“仅限紧急呼叫”。注册流程的核心目标有三个让UE和网络互相确认身份、协商安全能力、分配临时标识5G-GUTI和跟踪区列表TAI List。这三个目标分别对应鉴权、安全模式控制和注册接受三个阶段。从协议栈角度看注册流程横跨Uu口UE- gNB、N1口UE-AMF和N2口gNB-AMF。Uu口上跑的是RRC和NAS消息N2口上跑的是NGAP消息。中级认证要求你能区分哪些消息是RRC层的比如RRCSetupRequest哪些是NAS层的比如Registration Request哪些是NGAP层的比如Initial UE Message。很多考生丢分就丢在把NAS消息当成RRC消息来答。2.2 九步信令的逐条拆解与关键IE下面按时间顺序拆解一次成功的初始注册Initial Registration流程。假设UE刚开机没有有效的5G-GUTI需要走完整鉴权。第1步RRCSetupRequestUE → gNBUE在随机接入成功后通过SRB0发送RRCSetupRequest。关键IE是ue-Identity它是一个39位的随机值用于gNB区分不同UE的接入请求。注意这个阶段还没有任何NAS消息纯粹是RRC连接建立。第2步RRCSetupgNB → UEgNB分配SRB1资源返回RRCSetup。里面包含radioBearerConfig和masterCellGroup告诉UE用哪个逻辑信道、哪个调度资源来发后续消息。第3步RRCSetupComplete Registration RequestUE → gNB这是关键一步。UE在RRCSetupComplete消息里通过dedicatedNAS-Message字段携带了第一条NAS消息——Registration Request。Registration Request里的关键IE包括5GS registration type初始注册填initial registration5GMM capabilityUE支持的NAS安全算法、是否支持切换等SUCI或5G-GUTI首次注册用SUCI后续用5G-GUTIRequested NSSAIUE请求的网络切片第4步Initial UE MessagegNB → AMFgNB把NAS消息封装在NGAP的Initial UE Message里发给AMF。关键IE包括RAN UE NGAP ID、NAS-PDU就是Registration Request的原始字节、User Location Information小区标识。第5步Authentication RequestAMF → UEAMF收到注册请求后如果UE用的是SUCIAMF会向UDM/AUSF请求鉴权向量。拿到向量后AMF通过Downlink NAS Transport把Authentication Request发给UE。这条消息里包含RAND和AUTNUE用它们来验证网络身份并计算RES*。第6步Authentication ResponseUE → UEUE验证AUTN通过后计算RES并通过Uplink NAS Transport回给AMF。AMF比对RES和XRES*一致则鉴权成功。第7步Security Mode CommandAMF → UE鉴权成功后AMF发起NAS安全模式控制。Security Mode Command里包含选定的NAS加密算法和完整性保护算法比如NEA2/NIA2。UE收到后启用这些算法。第8步Security Mode CompleteUE → AMFUE用选定的算法对Security Mode Complete消息做完整性保护后回给AMF。至此NAS层安全建立完成。第9步Registration AcceptAMF → UEAMF分配5G-GUTI和TAI List通过Registration Accept发给UE。UE回Registration Complete注册流程结束。注意如果UE在Registration Request里带了5G-GUTIAMF可以跳过鉴权直接走安全模式这就是“移动性注册更新”比“初始注册”快的原因。2.3 用Wireshark过滤注册流程的实操命令如果你手上有pcap包用下面的过滤规则能快速定位注册流程的NAS消息。假设抓包点在N2口gNB和AMF之间。# 过滤NGAP协议里的Initial UE Message和Downlink/Uplink NAS Transport tshark -r 5g_registration.pcap -Y ngap.procedureCode 15 || ngap.procedureCode 4 -V # 只看NAS消息的摘要 tshark -r 5g_registration.pcap -Y nas_5gs -T fields -e frame.number -e nas_5gs.mm.message_type -e nas_5gs.mm.5gmm_cause第一条命令里的procedureCode 15对应Initial UE MessageprocedureCode 4对应Downlink NAS Transport。第二条命令直接提取NAS消息类型message_type字段能告诉你这条是Registration Request0x41、Authentication Request0x52还是Security Mode Command0x5d。参数说明-Y是显示过滤器-T fields指定输出字段-e指定字段名。如果你在Wireshark GUI里操作直接在过滤栏输入nas_5gs即可。3. AKA鉴权从RAND/AUTN到RES*/XRES*的完整计算链路3.1 5G AKA和4G AKA的关键差异5G中级认证里AKA鉴权是必考项。很多人知道4G的AKA是“RAND AUTN → RES”但5G AKA也叫5G-EAP-AKA或5G AKA多了一层SUCI的隐私保护和RES*的二次派生。在4G里UE用IMSI明文发起附着请求。在5G里UE用SUCISubscription Concealed Identifier代替SUPI就是IMSI。SUCI是用公钥加密后的SUPI只有UDM能解密。这意味着AMF在初始注册时看不到用户的真实IMSI必须把SUCI转发给UDM/AUSF去解密并生成鉴权向量。另一个差异是RES的计算。5G AKA里UE计算的不是RES而是RES。RES* KDFRES, serving network name, RAND。这个设计是为了防止重放攻击因为serving network name里包含了AMF所在的网络标识。3.2 鉴权向量AV的生成与字段含义UDM/AUSF生成的鉴权向量包含五个字段RAND、AUTN、XRES*、KAUSF、AKA-Challenge。下面用表格说明每个字段的作用。字段长度作用谁生成谁验证RAND16字节随机挑战值AUSFUE用它计算RES*AUTN16字节网络认证令牌AUSFUE验证网络身份XRES*16字节期望的响应AUSFAMF比对RES*KAUSF32字节锚点密钥AUSFUE和AMF派生后续密钥AKA-Challenge可变EAP-AKA场景用AUSF仅EAP场景AUTN的组成是SQN ⊕ AK || AMF || MAC。SQN是序列号AK是匿名密钥AMF是认证管理字段MAC是消息认证码。UE收到AUTN后先用AK解出SQN然后验证MAC是否正确。如果MAC不对UE会认为网络是伪造的直接拒绝鉴权。3.3 用Python模拟RES*计算的代码示例下面这段代码模拟UE侧从RAND和AUTN计算RES*的过程。实际UE里用的是USIM卡但理解计算逻辑对排查鉴权失败很有帮助。import hmac import hashlib def kdf(key, s, length16): 5G KDF函数基于HMAC-SHA256 # s是拼接后的字符串FC || P0 || L0 || P1 || L1 ... # 这里简化处理实际要按3GPP TS 33.220的格式拼接 return hmac.new(key, s.encode(), hashlib.sha256).digest()[:length] def compute_res_star(res, serving_network_name, rand): 计算RES* KDF(RES, serving network name, RAND) # 按TS 33.501 Annex A.4FC0x6B fc b\x6b snn serving_network_name.encode() # 拼接FC || SNN || len(SNN) || RAND || len(RAND) s fc snn len(snn).to_bytes(2, big) rand len(rand).to_bytes(2, big) return kdf(res, s.decode(latin-1), 16) # 假设从USIM读出的RES是16字节 res bytes.fromhex(00112233445566778899aabbccddeeff) # serving network name格式5G:mnc001.mcc001.3gppnetwork.org snn 5G:mnc001.mcc001.3gppnetwork.org rand bytes.fromhex(0102030405060708090a0b0c0d0e0f10) res_star compute_res_star(res, snn, rand) print(fRES*: {res_star.hex()})这段代码的关键在compute_res_star函数。它按照3GPP TS 33.501 Annex A.4的定义把FC函数码0x6B、serving network name、RAND按顺序拼接然后用HMAC-SHA256做KDF。参数说明res是从USIM读出的原始响应值snn是服务网络名称格式固定rand是网络下发的随机挑战值。实际排查鉴权失败时如果AMF侧计算的XRES和UE侧上报的RES不一致优先检查serving network name的格式是否正确——这是最常见的翻车点。3.4 鉴权失败的三个排查方向鉴权失败在现网里表现为Registration Rejectcause值通常是#20MAC failure或#21SQN failure。排查顺序如下第一检查SQN同步。如果UE的SQN和网络侧的SQN差距超过阈值网络会触发SQN重同步流程。这时候AMF会发Authentication RejectUE需要重新发起注册。第二检查SUCI解密。如果UDM无法解密SUCI会返回鉴权向量获取失败。这时候要看UE侧的SUCI生成逻辑用的是null-scheme明文还是ECIES加密。中级认证里常考null-scheme和ECIES的区别。第三检查KAUSF派生。如果鉴权通过但后续安全模式失败可能是KAUSF派生不一致。KAUSF KDFCK||IK, serving network name, SQN⊕AK。这里CK和IK是从USIM读出的如果USIM返回的CK/IK有误KAUSF就会错。4. NAS安全模式与密钥派生从KAUSF到KNASenc的完整链路4.1 密钥派生的层级关系5G的密钥派生是一个树形结构。根密钥是KAUSF由USIM的CK/IK派生而来。从KAUSF往下派生出KSEAF再派生出KAMF然后KAMF派生出KNASenc和KNASint。如果是切换场景还会从KAMF派生出KgNB。中级认证里常考的派生公式KSEAF KDFKAUSF, serving network nameKAMF KDFKSEAF, SUPI, ABBAKNASenc KDFKAMF, NAS encryption algorithm type, 0x01KNASint KDFKAMF, NAS integrity algorithm type, 0x02ABBA参数是5G新增的用于防止降级攻击。UE和AMF各自维护一个ABBA值在鉴权过程中交换。如果ABBA不匹配安全模式会失败。4.2 Security Mode Command的字段解析Security Mode Command是AMF发给UE的NAS消息消息类型是0x5d。关键IE包括Selected NAS security algorithms一个字节高4位是加密算法低4位是完整性算法。比如0x22表示NEA2 NIA2。NAS MAC完整性保护码用KNASint计算。UE security capabilityUE在Registration Request里上报的安全能力AMF在这里回显确认。IMEISV request可选AMF可以要求UE上报IMEISV。UE收到Security Mode Command后先用KNASint验证NAS MAC。如果验证失败UE回Security Mode Rejectcause是#24security mode rejected, unspecified。如果验证通过UE启用加密和完整性保护回Security Mode Complete。4.3 用Scapy构造NAS Security Mode Command的示例下面用Scapy模拟构造一条Security Mode Command帮助理解NAS消息的字节结构。from scapy.all import * # 定义NAS 5GS消息头 class NAS5GS_Header(Packet): name NAS5GS Header fields_desc [ BitField(extended_protocol_discriminator, 0x7e, 8), BitField(security_header_type, 0x00, 4), BitField(protocol_discriminator, 0x07, 4), ByteField(message_type, 0x5d), ] # 定义Security Mode Command class SecurityModeCommand(Packet): name Security Mode Command fields_desc [ ByteField(selected_algorithms, 0x22), # NEA2 NIA2 ByteField(nas_mac, 0x00), # 实际值由KNASint计算 ByteField(ue_security_capability_len, 0x02), ByteField(ea, 0x02), # 支持NEA2 ByteField(ia, 0x02), # 支持NIA2 ] # 构造完整消息 pkt NAS5GS_Header() / SecurityModeCommand() pkt.show() hexdump(pkt)这段代码的重点是selected_algorithms字段。0x22的高4位是2NEA2低4位是2NIA2。实际现网里如果AMF选了UE不支持的算法UE会回Security Mode Reject。所以AMF在选择算法时必须取UE上报能力和自身支持能力的交集。参数说明nas_mac字段在真实消息里是用KNASint对整条消息计算的这里填0只是占位。4.4 安全模式失败的常见原因安全模式失败在现网里比鉴权失败更隐蔽。常见原因有三个第一算法不匹配。AMF选了NEA3但UE只支持NEA2UE直接拒绝。排查方法是看Registration Request里的5GMM capability字段确认UE上报的算法列表。第二KNASint不一致。如果UE和AMF派生的KNASint不同UE验证NAS MAC会失败。这通常是因为KAMF派生时ABBA值不一致。检查AMF侧配置的ABBA值和UE USIM里的ABBA值是否相同。第三消息完整性保护顺序错误。Security Mode Command本身是用KNASint做完整性保护的但加密是在安全模式完成之后才启用。如果AMF提前加密了Security Mode CommandUE无法解密直接丢弃。5. 避坑与排查5G信令流程里最容易翻车的五个点5.1 坑一Registration Request里的SUCI格式错误导致UDM解密失败现象UE发起注册后AMF回Registration Rejectcause #22Congestion或直接超时。抓包看AMF向UDM发的Nudm_UEAuthentication_Get请求UDM返回404或解密失败。原因UE生成的SUCI格式不符合TS 33.501 Annex C的要求。常见错误包括null-scheme下没有正确填充MSIN的BCD编码或者ECIES加密时公钥索引protection scheme identifier填错。解决用USIM模拟器抓SUCI的原始字节对照TS 33.501 Annex C逐字段检查。null-scheme的SUCI格式是MCCMNCMSIN其中MSIN不足10位时前面补0。ECIES的SUCI还要检查ephemeral public key和encrypted MSIN的长度。5.2 坑二5G-GUTI分配后UE不回Registration Complete现象AMF发了Registration Accept里面带了5G-GUTI但UE没有回Registration Complete。AMF侧定时器超时后释放UE上下文。原因UE收到Registration Accept后需要把5G-GUTI写入USIM或非易失存储。如果写入失败比如USIM文件系统满或写保护UE不会回Registration Complete。解决检查UE侧的USIM文件系统确认EF_5GS3GPPNSC或EF_5GS3GPPNSC文件可写。如果是测试UE检查日志里有没有“GUTI update failed”的错误。5.3 坑三TAI List里包含UE不支持的跟踪区导致重选失败现象UE注册成功后在TAI List覆盖的区域里移动时频繁发起注册更新但每次都被拒绝。原因AMF分配的TAI List里包含了UE不支持的频段或切片对应的TAI。UE在重选到这些TAI时发现没有对应的切片配置触发注册更新但被AMF拒绝。解决检查AMF的TAI List配置确保只包含UE请求的NSSAI对应的TAI。用Requested NSSAI和Allowed NSSAI做交集不要直接把所有TAI都塞进去。5.4 坑四NAS计数器溢出导致消息被丢弃现象注册流程正常但过了一段时间后UE突然掉网重新注册也失败。抓包看NAS消息的MAC验证失败。原因NAS层的上下行计数器NAS COUNT溢出。5G NAS COUNT是24位达到最大值后需要触发密钥更新。如果AMF没有及时触发密钥更新UE和AMF的计数器不同步MAC验证就会失败。解决在AMF侧配置NAS COUNT的阈值告警达到80%时触发密钥更新流程。UE侧也要支持密钥更新请求。5.5 坑五RRCSetupComplete里携带的NAS消息被截断现象gNB收到RRCSetupComplete后转发给AMF的Initial UE Message里NAS-PDU不完整AMF解析失败。原因RRCSetupComplete的dedicatedNAS-Message字段有长度限制。如果Registration Request超过限制比如带了很长的Requested NSSAIUE需要分段发送。但有些UE实现不支持NAS分段直接截断。解决检查UE的NAS分段能力。如果UE不支持分段AMF需要在Registration Accept里限制NSSAI的数量。gNB侧也要检查RRC消息的最大长度配置。6. 用pcap包验证信令流程从过滤到逐条比对的实操技巧6.1 搭建最小验证环境如果你没有现网抓包权限可以用UERANSIM Open5GS在本地搭一个最小5G核心网。UERANSIM模拟UE和gNBOpen5GS模拟AMF/SMF/UPF。这个组合在Linux上跑起来只需要两条命令。# 启动Open5GS核心网 sudo systemctl start open5gs-amfd open5gs-smfd open5gs-upfd open5gs-ausfd open5gs-udmd # 启动UERANSIM的gNB和UE sudo ./nr-gnb -c config/gnb.yaml sudo ./nr-ue -c config/ue.yaml 启动后用tcpdump在N2口抓包。N2口是gNB和AMF之间的SCTP连接默认端口是38412。sudo tcpdump -i lo -w 5g_registration.pcap sctp port 38412抓到的包用Wireshark打开过滤ngap就能看到完整的注册流程。这个环境的好处是你可以反复触发注册每次改一个参数观察信令变化。6.2 逐条比对信令的检查清单拿到pcap后按下面的清单逐条核对。每条消息都要确认三个东西方向、消息类型、关键IE。序号消息方向关键IE常见异常1RRCSetupRequestUE→gNBue-Identity随机值重复2RRCSetupgNB→UEradioBearerConfigSRB1配置缺失3RRCSetupCompleteUE→gNBdedicatedNAS-MessageNAS消息截断4Initial UE MessagegNB→AMFNAS-PDUNGAP ID冲突5Authentication RequestAMF→UERAND, AUTNAUTN MAC错误6Authentication ResponseUE→AMFRES*RES与XRES不匹配7Security Mode CommandAMF→UEselected_algorithms算法不支持8Security Mode CompleteUE→AMFNAS MACMAC验证失败9Registration AcceptAMF→UE5G-GUTI, TAI ListGUTI格式错误这张表建议打印出来每次抓包后逐条打勾。中级认证的实操题里经常给你一段不完整的信令让你补全缺失的消息或指出错误的消息类型。用这张表对照基本不会漏。6.3 一个我踩过的坑时间戳对齐有一次排查注册失败UE侧日志显示发了Registration RequestAMF侧日志显示没收到。两边时间戳差了3秒我以为是网络延迟查了半天发现是UE和AMF的NTP服务器不同步。UE用的是本地时钟AMF用的是核心网时钟差了3秒导致信令关联错误。后来我养成了一个习惯抓包前先确认所有网元的NTP同步状态。在Linux上用chronyc tracking看偏移量超过100ms就先同步再抓包。这个习惯帮我省了很多“玄学”问题的排查时间。6.4 进阶技巧用tshark脚本自动提取注册时延如果你需要批量分析注册时延可以用tshark的-z参数配合Python脚本。下面这段脚本提取从RRCSetupRequest到Registration Accept的时间差。import subprocess import re def extract_registration_delay(pcap_file): # 用tshark提取关键帧的时间戳 cmd [ tshark, -r, pcap_file, -Y, rrc_setup_request || nas_5gs.mm.message_type 0x42, -T, fields, -e, frame.time_epoch, -e, rrc_setup_request || nas_5gs.mm.message_type ] result subprocess.run(cmd, capture_outputTrue, textTrue) lines result.stdout.strip().split(\n) timestamps [] for line in lines: parts line.split(\t) if len(parts) 2: timestamps.append(float(parts[0])) if len(timestamps) 2: delay timestamps[-1] - timestamps[0] print(f注册时延: {delay*1000:.2f} ms) else: print(未找到完整的注册流程) extract_registration_delay(5g_registration.pcap)这段脚本的核心是-Y过滤器它同时匹配RRCSetupRequest和Registration AcceptNAS消息类型0x42。frame.time_epoch给出每个包的绝对时间戳相减就是注册时延。参数说明-e指定要提取的字段多个-e用制表符分隔。实际用的时候如果pcap里有多条注册流程需要按UE ID分组再计算。我一般会把这个脚本挂在测试环境里每次版本更新后跑一遍对比注册时延的变化。如果时延突然增加超过50ms就去查AMF的鉴权向量获取时间或者UDM的响应时间。这个习惯让我在两次版本迭代中提前发现了UDM查询慢的问题避免了现网投诉。希望帮到你。本文还有配套的精品资源点击获取
