简介这份文档面向5G网络优化工程师及备考5G中级认证的技术人员系统梳理了5G信令流程的核心知识点帮助读者理解UE与网络交互的关键环节解决注册、鉴权、随机接入等流程中的原理性困惑。资源包内含1个docx文档压缩包约316KB内容以文字讲解为主结构清晰便于查阅。文档围绕注册流程展开涵盖Registration Request携带的注册类型、SUCI或5G-GUTI、NSSAI、PDU会话状态、MICO模式首选项及DRX参数等并深入解析SUPI与SUCI的加密机制、PEI设备标识以及Null-Scheme上报的隐私与安全风险。随机接入部分则说明其目的、触发条件、基于竞争与非竞争两种方式的适用场景以及preamble发送与RAR响应等步骤。目前已有225人学习适合需要夯实信令基础、排查接入故障或进行性能调优的从业者参考。1. 5G中级认证里的信令流程为什么它是网优和核心网工程师的分水岭做5G中级认证的人十有八九卡在信令流程这一关。基站侧参数配得再熟一遇到接入失败、切换掉线、PDU会话建不起来如果不会顺着信令一条条往下捋就只能靠重启和盲调这在现网里是典型的玄学排障。5G信令流程本质上是一套“谁先说话、谁后应答、哪一步失败就断在哪”的对话规则从UE开机搜网到注册、鉴权、安全激活再到PDU会话建立和切换每一步都有明确的触发条件和失败码。它解决的不是“怎么把网建起来”而是“网建起来之后用户为什么上不去、掉得快、切不过去”。适合已经摸过5G基站和核心网、准备考中级认证、或者日常要做接入与切换问题定位的工程师。把信令流程吃透你手里的抓包和日志才不是黑匣子排障才有后悔药可吃。2. 从开机到注册5G信令流程的起点与鉴权主线2.1 注册流程的四个阶段与消息走向5G注册流程是终端进入网络的第一道门整体可以拆成四个阶段RRC连接建立、NAS注册请求、鉴权与安全激活、注册接受。UE开机后先做小区搜索读到MIB和SIB1拿到PLMN和接入控制信息然后发起RRCSetupRequest。这一步在空口上看到的是Msg1到Msg4的随机接入过程Msg3里携带的是RRCSetupRequestMsg4是RRCSetup。RRC连接建好之后UE通过RRCSetupComplete里携带的NAS PDU把Registration Request送给AMF。AMF收到注册请求后如果UE是首次接入或者没有有效上下文就会触发鉴权流程。这里就是5G AKA的主场。AMF向UDM/AUSF请求鉴权向量AUSF生成RAND和AUTN通过AMF下发给UE。UE侧的USIM卡验证AUTN里的MAC和SQN验证通过后计算RES*通过Authentication Response回给AMF。AMF比对RES和XRES一致则鉴权通过。紧接着是安全模式命令AMF下发Security Mode CommandUE回Security Mode CompleteNAS层加密和完整性保护就此激活。注册接受之后如果UE有业务需求AMF会在注册接受里带上PDU Session Establishment Accept或者UE主动发起PDU会话建立。整个注册流程里最容易出问题的是鉴权环节和RRC连接建立环节。鉴权失败通常表现为MAC failure或者SQN failure前者多半是卡和网络侧的密钥不一致后者是序列号不同步。RRC连接建立失败则要看随机接入是否成功、Msg3是否冲突、Msg4是否收到。2.2 5G AKA鉴权参数怎么算、失败怎么查5G AKA相比4G的AKA核心变化是引入了服务网络名称和归属网络名称的绑定以及RES和XRES的派生。鉴权向量由AUSF生成包含RAND、AUTN、XRES*、KAUSF。AUTN里包含MAC、SQN、AK、AMF。UE侧验证AUTN的过程是用K和RAND算出AK解出SQN检查SQN是否在合理窗口内然后用K、RAND、SQN、AMF算出XMAC和AUTN里的MAC比对。如果MAC不一致UE回Authentication Failure原因值MAC failure。如果SQN不在窗口内回Sync failure并带上UE侧的SQN网络侧据此重新同步。下面是一段用Python模拟UE侧验证AUTN的简化逻辑实际工程里不会自己实现但理解这个过程对排查鉴权失败很有帮助。# 简化模拟5G AKA中UE侧验证AUTN的核心步骤 # 注意真实USIM内部用K和OPc做运算这里只展示校验逻辑 import hmac import hashlib def derive_ak(k, rand): # 实际用Milenage或TUAK算法这里用HMAC示意 return hmac.new(k, rand b\x00, hashlib.sha256).digest()[:6] def compute_xmac(k, rand, sqn, amf): # 示意性计算真实算法在USIM内完成 msg rand sqn amf return hmac.new(k, msg, hashlib.sha256).digest()[:8] def verify_autn(k, rand, autn, amf, sqn_window32): # autn MAC(8) SQN(6) AK(6) AMF(2) mac autn[0:8] sqn_enc autn[8:14] ak derive_ak(k, rand) sqn bytes(a ^ b for a, b in zip(sqn_enc, ak)) xmac compute_xmac(k, rand, sqn, amf) if not hmac.compare_digest(mac, xmac): return MAC failure # SQN窗口检查实际还要看UE保存的SQN return OK这段代码的关键参数是K、RAND、SQN、AMF。K是卡里预置的长期密钥RAND是网络侧生成的随机数SQN是序列号AMF是鉴权管理域。排查鉴权失败时先确认卡是否插好、K值是否写对再看SQN是否同步。现网里SQN不同步多半发生在换卡、跨AMF移动或者长时间关机之后。解决方式是让网络侧重新同步或者手动触发一次鉴权失败让UE上报SQN。2.3 安全模式与NAS加密容易被忽略的激活顺序安全模式命令是注册流程里承上启下的一步。AMF在鉴权通过后会选择NAS加密算法和完整性保护算法通过Security Mode Command下发给UE。UE回Security Mode Complete之后所有NAS消息都走加密和完整性保护。这里有个容易翻车的点如果UE和AMF支持的算法集没有交集AMF会选一个默认算法或者直接拒绝。现网里常见的是UE只支持NEA0和NIA0而网络侧要求NEA2和NIA2结果就是安全模式失败注册卡死。排查这类问题要看AMF下发的Security Mode Command里带的算法列表和UE侧支持的算法做比对。如果算法不匹配要么升级UE侧配置要么在AMF侧调整算法优先级。另一个坑是安全模式命令和鉴权响应的顺序如果UE在鉴权响应还没发完就收到安全模式命令可能会丢弃。正常顺序是Authentication Response之后才发Security Mode Command。3. PDU会话建立与QoS流用户面通不通就看这几步3.1 PDU会话建立的完整信令链PDU会话建立是用户面通路的起点。UE在注册完成后如果需要上网会发起PDU Session Establishment Request通过NAS消息发给AMF。AMF收到后根据UE请求的DNN和S-NSSAI选择SMF。SMF再向UPF发起N4会话建立同时向UDM获取会话管理签约数据。SMF把分配的UE IP地址、QoS规则、会话参数通过PDU Session Establishment Accept回给AMFAMF再通过NAS透传给UE。空口侧UE收到PDU会话建立接受后会发起RRC重配置建立DRB。DRB建好之后用户面数据才能走。整个链路是UE - gNB - AMF - SMF - UPF。任何一段出问题用户面都不通。常见现象是UE显示有信号但上不了网或者能拿到IP但ping不通。这时候要分段排查先看NAS层PDU会话建立是否成功再看N4会话是否建立最后看DRB是否建立。下面是一个用Wireshark过滤5G NAS信令的显示过滤器示例实际抓包时用得上。# Wireshark显示过滤器只看5G NAS注册和PDU会话相关消息 # 在Wireshark的Filter栏输入以下表达式 # 过滤NAS EPS移动性管理消息5G NAS用gsm_map或nas-5gs nas-5gs.nas_message_type 0x41 || nas-5gs.nas_message_type 0x42 || nas-5gs.nas_message_type 0x43 || nas-5gs.nas_message_type 0x44 # 过滤PDU会话建立相关 nas-5gs.nas_message_type 0xc1 || nas-5gs.nas_message_type 0xc2 || nas-5gs.nas_message_type 0xc3 # 过滤NGAP接口上的PDU会话资源建立 ngap.procedure_code 29这些过滤器的含义是0x41是Registration Request0x42是Registration Accept0x43是Registration Complete0x44是Registration Reject。0xc1是PDU Session Establishment Request0xc2是PDU Session Establishment Accept0xc3是PDU Session Establishment Reject。ngap.procedure_code 29是PDU Session Resource Setup。抓包时先确认抓的是哪个接口N1接口看NASN2接口看NGAPN4接口看PFCP。3.2 QoS流与DRB映射5QI怎么选、坑在哪5G的QoS模型是QoS Flow每个QoS Flow用一个5QI标识。5QI决定了调度优先级、丢包率、时延预算等参数。PDU会话建立时SMF会根据签约数据和UE请求决定建几个QoS Flow。默认QoS Flow的5QI通常是9对应非保证比特率业务。如果UE发起VoNR会建一个5QI为1的QoS Flow对应语音业务。QoS Flow到DRB的映射关系由gNB决定。一个DRB可以承载多个QoS Flow但同一个QoS Flow只能映射到一个DRB。现网里常见的问题是QoS Flow建了但DRB没建或者DRB建了但QoS Flow映射错了。表现是语音断续、视频卡顿、游戏高时延。排查时要看gNB侧的DRB配置和QoS Flow的映射关系确认5QI对应的调度参数是否合理。5QI资源类型典型业务时延预算丢包率1GBR语音100ms10^-22GBR视频通话150ms10^-35GBR实时游戏100ms10^-69Non-GBR上网300ms10^-680Non-GBR低优先级数据300ms10^-6这张表是日常调参的参考。5QI 1和2是GBR业务需要预留资源如果资源不够QoS Flow建立会失败。5QI 9是默认的大部分上网业务都用这个。调参时不要随意改5QI改了要同步改调度参数和资源预留。3.3 用户面不通的分段排查法用户面不通是现网里最高频的问题之一。分段排查的思路是先看UE是否拿到IP再看UPF是否收到上行包再看gNB是否发出下行包。具体步骤是在UE侧ping网关如果ping不通看UE的PDU会话状态在UPF侧抓包看N3接口是否有上行GTP-U包在gNB侧抓包看空口是否有下行调度。常见原因有UE IP地址池配错、UPF的N3地址和gNB的N3地址不通、GTP-U隧道ID不匹配、防火墙拦截了GTP-U端口。GTP-U用的是UDP 2152端口如果中间有防火墙要确认放行。另一个坑是MTU不匹配5G用户面默认MTU是1500如果UPF侧配了更大的MTU分片会导致丢包。4. 切换信令流程Xn和N2切换的差异与失败定位4.1 Xn切换与N2切换的触发条件5G切换分两种Xn切换和N2切换。Xn切换是gNB之间直接通过Xn接口交互不需要核心网参与速度快时延低。N2切换是gNB通过AMF转发切换信令核心网参与速度慢但适用于Xn接口不可用或者跨AMF的场景。Xn切换的触发条件是源gNB和目标gNB之间有Xn接口且目标gNB有足够的资源。切换流程是源gNB发Handover Request给目标gNB目标gNB回Handover Request Acknowledge源gNB发RRCReconfiguration给UEUE切换到目标小区发RRCReconfigurationComplete目标gNB发Handover Success给源gNB。N2切换则是源gNB发Handover Required给AMFAMF转发给目标gNB目标gNB回Handover Request AcknowledgeAMF发Handover Command给源gNB后续类似。切换失败的表现是掉线、重建、或者切换后业务中断。排查时要看切换准备阶段是否成功、切换执行阶段是否超时、切换完成阶段是否有异常释放。Xn切换失败常见原因是Xn接口不通、目标小区资源不足、UE测量报告不准确。N2切换失败常见原因是AMF侧信令超时、目标gNB拒绝、核心网侧会话迁移失败。4.2 切换信令里的关键参数与定时器切换流程里有几个关键定时器和参数配错了直接导致切换失败。T304是UE侧等待切换完成的定时器默认50ms到200ms如果目标小区信号差T304超时会触发RRC重建。T310是UE侧检测无线链路失败的定时器默认1秒超时后触发重建。N310是连续失步指示次数默认1次达到后启动T310。网络侧参数有Handover Preparation定时器、Handover Execution定时器、Xn接口的流控参数。这些参数在gNB侧配置不同厂家叫法不同。调参时要根据现网覆盖和负载来定不能照搬默认值。比如密集城区T304可以设短一点避免UE在差小区上耗太久郊区可以设长一点给UE更多时间。# 切换失败日志分析示例从gNB日志里提取切换失败原因 # 假设日志格式为时间戳 事件 原因值 import re def parse_handover_failure(log_lines): failures [] pattern re.compile(r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).*Handover.*(Fail|Reject|Timeout).*cause(\w)) for line in log_lines: match pattern.search(line) if match: failures.append({ time: match.group(1), type: match.group(2), cause: match.group(3) }) return failures # 示例日志 logs [ 2024-01-15 10:23:45 Handover Preparation Fail causeXn_Not_Available, 2024-01-15 10:24:12 Handover Execution Timeout causeT304_Expiry, 2024-01-15 10:25:01 Handover Reject causeRadio_Resource_Unavailable ] for f in parse_handover_failure(logs): print(f)这段代码的作用是从日志里提取切换失败的时间、类型和原因值。实际用的时候把日志文件读进来按行匹配。关键参数是cause常见的有Xn_Not_Available、T304_Expiry、Radio_Resource_Unavailable。看到Xn_Not_Available就去查Xn接口看到T304_Expiry就去查目标小区覆盖和T304配置看到Radio_Resource_Unavailable就去查目标小区负载。4.3 切换与注册更新的边界什么时候触发TAU切换和注册更新是两回事但经常被混在一起。切换是连接态下的移动性管理注册更新是空闲态下的位置管理。UE在连接态切换时如果跨了TA切换完成后会触发TAU。TAU流程是UE发Tracking Area Update RequestAMF回Tracking Area Update Accept。如果TAU失败UE会重新注册。现网里常见的问题是切换成功了但TAU失败导致UE被叫不通。排查时要看TAU的触发条件是否满足、AMF侧是否收到TAU请求、TA列表是否配错。TA列表配错会导致UE频繁TAU增加信令负荷。另一个坑是TAU和切换并发UE在切换过程中收到TAU接受可能会丢弃。正常顺序是切换完成后才发TAU。5. 避坑与排查5G信令流程里最容易翻车的五个点5.1 鉴权失败但卡是好的现象UE反复发起注册每次都在鉴权环节失败原因值MAC failure。换一张卡就好了但原卡在别的手机上能用。原因不是卡坏了是UE侧的USIM接口或者卡座接触问题导致K值读取错误。解决先清洁卡座再换卡测试。如果换卡正常说明是卡座问题如果换卡也失败查UE侧USIM驱动。5.2 注册成功但PDU会话建不起来现象UE显示5G图标但上不了网PDU Session Establishment Request发出去后收到Reject。原因DNN配错、S-NSSAI不匹配、或者SMF侧没有签约数据。解决先看Reject里的原因值如果是DNN not supported查UE侧DNN配置和SMF侧DNN列表如果是S-NSSAI not supported查切片配置如果是Subscription not found查UDM签约数据。5.3 切换成功率低但信号都正常现象切换成功率只有70%但源小区和目标小区的RSRP、SINR都很好。原因Xn接口闪断、目标小区资源不足、或者切换参数配得太激进。解决先查Xn接口的告警和丢包再看目标小区的PRB利用率和RRC连接数最后调T304和切换门限。如果Xn接口有丢包优先解决传输问题。5.4 用户面通了但速率上不去现象UE能上网但下载速率只有几十Mbps远低于峰值。原因QoS Flow的5QI配错、DRB调度参数不合理、或者UPF侧限速。解决先看QoS Flow的5QI是不是9再看gNB侧的调度算法和MCS最后看UPF侧有没有限速策略。如果5QI是80改成9试试。5.5 抓包看到信令但解析不了现象Wireshark抓到了N2接口的包但NAS消息解析不出来显示为Unknown。原因Wireshark版本太老不支持5G NAS解析或者抓包时没有配置正确的解码器。解决升级Wireshark到较新版本在Preferences里把NAS-5GS解码器打开。如果还是不行检查抓包文件是否完整SCTP分片是否重组。6. 用日志和抓包反推信令一个可复现的验证方法信令流程学到最后最值钱的不是背流程而是能从日志和抓包里反推出问题出在哪一步。我一般会用一个笨办法先抓一次完整的注册流程把每条消息的时间戳、方向、消息类型、关键IE列出来做成一张时间线表。然后拿一个失败的案例同样列时间线对比哪一步开始分叉。这个方法不需要昂贵的仪表一台能抓包的测试终端加一个镜像口就够了。具体操作是在AMF侧抓N1和N2接口的包在gNB侧抓空口和N3接口的包在UE侧用QXDM或者类似工具抓空口日志。三份数据按时间对齐看消息的因果关系。比如UE发了Registration RequestAMF侧没收到那就是N1接口或者RAN侧的问题AMF发了Authentication RequestUE没回Authentication Response那就是空口或者UE侧的问题。下面是一个用Python把抓包时间线对齐的简单脚本输入是CSV格式的消息列表输出是按时间排序的合并时间线。# 把多份抓包日志按时间对齐输出合并时间线 import csv from datetime import datetime def load_messages(file_path, source): messages [] with open(file_path, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: messages.append({ time: datetime.strptime(row[timestamp], %Y-%m-%d %H:%M:%S.%f), source: source, direction: row[direction], message: row[message], key_ie: row.get(key_ie, ) }) return messages def merge_timeline(files): all_msgs [] for path, source in files: all_msgs.extend(load_messages(path, source)) all_msgs.sort(keylambda x: x[time]) for msg in all_msgs: print(f{msg[time]} [{msg[source]}] {msg[direction]} {msg[message]} {msg[key_ie]}) # 用法示例 # merge_timeline([(amf_n1.csv, AMF), (gnb_uu.csv, gNB), (ue_log.csv, UE)])这个脚本的关键是时间戳格式要统一CSV里要有timestamp、direction、message、key_ie四列。实际用的时候先从Wireshark导出CSV再用脚本合并。对齐之后一眼就能看出哪条消息丢了、哪条消息晚了、哪条消息回了但内容不对。我自己的习惯是每次遇到新问题先不急着改参数先把时间线拉出来。十次里有八次问题在时间线上就暴露了。剩下两次才是需要深入查协议细节的。这个习惯帮我省了很多后悔药也让我在认证考试里遇到信令题时能快速定位到考点。希望帮到你。本文还有配套的精品资源点击获取