简介5G信令流程解析是移动通信领域的重要学习主题这份docx文档面向5G初学者、通信专业学生及从业者系统整理了信令流程的核心知识点与学习方法。内容从背景知识切入对比5G相较于前代在速率、时延与连接密度方面的提升随后介绍UE、gNB、核心网等关键网元及相互间的通信关系重点讲解了控制信令与用户数据信令的区别并覆盖接入过程、鉴权安全、移动性管理、资源分配与调度、服务质量保障等主要环节。文档还给出了系统学习、深入原理、仿真实践、案例分析和持续跟进等实用学习技巧有助于读者将理论对应到实际网络场景中为后续从事5G运维、优化或研究打下基础。压缩包共1个docx文件大小约11KB全文内容精炼、条理清晰方便在碎片时间快速阅读学习。该文档已有402人学习适合准备系统入门5G信令或进行阶段性复习的读者。1. 5G信令流程为什么难啃先建立一张全局图背信令最快的办法不是把TS 38.331、TS 24.501从头啃下来而是先接受一个反直觉的事实5G信令流程是一张状态图不是一串消息列表。注册、服务请求、PDU会话建立、切换、去注册每条流程看起来都是十几条消息来回但真正决定流程成败的往往只有几个关键参数——SUCI还是5G-GUTI、Request NSSAI里的切片值、PDU Session Type和SSC Mode的组合。这份5G信令流程解析信息介绍及学习技巧资源的价值就在这它不按协议章节讲而是按流程拆把每条消息里该看的字段、该留意的时序、容易踩的坑都串起来。适合刚转5G的网优、核心网交付测试、协议栈开发以及那些已经会用Wireshark抓包但不知道下一步看什么的人。2. 注册流程拆解从RRC到AMF一条注册消息里藏了四个关键字段2.1 注册请求里的四个必认字段SUCI、5G-GUTI、Request NSSAI和Registration Type注册流程是5G信令的基础几乎所有其他流程都建立在UE完成注册之后。我在看注册请求时不会从头到尾把每个IE都读一遍只盯四个字段。第一个是UE身份标识。UE第一次进网或没有有效GUTI时上报的是SUCISubscription Concealed Identifier这是SUPI加密后的结果。如果UE之前注册过会上报5G-GUTIAMF靠它能直接找到UE的上下文省掉整条鉴权链路。很多新手看到Registration Request里只有一个长长的SUCI字符串就觉得流程不对其实这恰恰说明UE真的是第一次注册或者AMF发生了改变。第二个是Request NSSAI也就是UE想用的切片。它直接决定了AMF会把这个注册请求路由到哪个AMF以及后续允许哪些网络切片。现网里最常见的注册失败原因之一就是Request NSSAI里的SST/SD组合在签约数据里不存在AMF返回的5GMM Cause是62No Network Slices Available。所以看注册请求时先抄下S-NSSAI的值再对照注册接受里的Allowed NSSAI一眼就能判断是UE的配置问题还是签约问题。第三个是Registration Type这是个很容易被看一眼就跳过的字段。它取值有三种Initial、Mobility Update、Periodic Update。其中Mobility Update后面通常会跟着一组TAI列表能看出UE在哪些位置区之间移动Periodic Update则不会走完整的鉴权AMF和UE之间的上下文直接复用。判断一个注册流程是正常周期性更新还是跨AMF的初始注册第一个就要看它。第四个是5GMM Cause在NAS消息里携带。它不只在注册拒绝里出现在后续的身份验证、安全模式控制里也会出现。我习惯把Cause值和对应的网元记录下来因为同一个Cause在不同阶段的含义完全不同比如Cause 3Illegal UE和Cause 6Illegal ME分别指向SIM卡和终端IMEI方向完全不同。2.2 鉴权链路5G-AKA和EAP-AKA什么时候会触发二次鉴权注册请求进了AMF之后AMF会向UDM取鉴权向量。这一步里AMF和UDM之间的消息是Nausf_UEAuthentication走的是HTTP/2而UE和AMF之间的NAS鉴权消息则通过gNB透明传输。这里有个容易混淆的点5G鉴权有两种机制5G-AKA和EAP-AKA。5G-AKA是默认机制AMF从UDM拿到的鉴权向量里包含RAND、AUTN、XRES、KSEAF等参数然后AMF向UE发送NAS Authentication RequestUE侧用USIM里的密钥计算AUTN校验网络合法性后再生成RES返回。EAP-AKA则是在需要二次认证、或UE是某些特殊终端时才会走整个流程会变成AMF转发EAP消息给UEUE完成EAP认证后再回到NAS安全模式。我看鉴权流程时最关注的不是加密算法而是两个地方一是Authentication Request里的AUTN和RAND是否成对如果UE侧的AUTN校验失败通常是因为网络侧和UE侧的密钥版本不一致常见于空口抓包遇到了老终端和新增密法的混用二是是否出现二次鉴权——某些企业定制网络的R17方案里会引入二次鉴权流程多一次AMF与AAA/EAP Server的交互如果以前的脚本直接按Authentication Request → Response → Security Mode Command判断流程结束就会误报失败。2.3 从gNB到AMFInitial UE Message里的TAC、CellId和RAN UE NGAP IDNAS消息要离开空口进入核心网封装在NGAP的Initial UE Message里从gNB发到AMF。这一步很多分析工具只显示NGAP层不展开RRC透明容器导致新手以为NAS消息丢了。实际上Initial UE Message里有几个NGAP IE是定位问题的重要依据。第一个是TAI它包含PLMN和TAC。如果TAI里的TAC和UE侧跟踪区列表里的TAC不一致AMF会认为UE所在位置超出注册范围触发Registered Area Reallocation并重新进行移动性注册更新。第二个是Cell ID在NR-CGI里它精确到小区配合TAC可以做越区覆盖和切换路径的关联分析。第三个是RAN UE NGAP IDgNB分配给这条UE连接的唯一标识不管后续是Initial Context Setup还是UE Context Release都靠它保持关联。除NGAP IE外Initial UE Message里有一个携带在RRC容器中的RRC Establishment Cause我在分析无线侧接入成功率时会对照它判断同一时间大量高优先级的接入请求可能是网络拥塞低优先级大量重试可能是配置错误导致的反复接入。从RRC Establishment Cause到RRC Setup、再到Initial UE Message整个过程配合gNB侧的时间和UE侧的时间差能定位接入瓶颈是在无线侧还是核心网侧。注册流程走到这里AMF对UE的合法性有了确认接下来会发送Security Mode Command建立NAS安全上下文然后下发Registration Accept。如果AMF下发的Allowed NSSAI里包含S-NSSAIUE才会继续发起PDU会话建立。这就是为什么我总把注册流程称为PDU会话的前置闸门——注册没过后面的流程连启动条件都没有。3. PDU会话建立流程参数组合才是考试重点别只背消息序列3.1 PDU Session Type和SSC Mode一组常见的错误组合PDU会话建立是5G承载用户面数据的核心流程也是信令分析中被误解最多的流程。误解的根源在于很多人把它的消息序列当成一个简单的请求——响应来看而实际上PDU会话建立是N1、N2、N4三个接口同时协作的结果任何一个接口的异常都会导致用户面数据无法转发。先看UE发起的PDU Session Establishment Request里最关键的两个参数组合。PDU Session Type决定UE需要什么类型的IP或非IP连接取值有IPv4、IPv6、IPv4v6和Ethernet非IP类型。SSC Mode则决定UE在PDU会话生命周期中的连续性保障取值有SSC Mode 1、Mode 2、Mode 3。它们不是随便搭配的选型逻辑通常是SSC Mode 1适合要求IP地址保持不变的场景无论UPF怎么改变IP地址不释放SSC Mode 3则是先建立新会话再释放旧会话适合在不中断业务的前提下切换UPF的场景SSC Mode 2则会先断开旧会话再建立新会话IP地址会变适合对连续性要求不高的场景。Group ID for Network Slicing、Non-3GPP access这些高级字段可以先不碰但上面这两个组合要记牢。现网里最典型的失败是UE请求IPv4v6但核心网只配置了IPv4地址池SMF返回的PDU会话建立拒绝里带5GSM Cause是32No DNN or unknown DNN或38Network not yet registered。另一种更隐蔽的情况是UE请求了SSC Mode 2但DNN对应的协议配置和下沉UPF的锚点位置冲突导致会话建立请求走到N4会话建立时才被UPF拒绝。PDU Session TypeSSC Mode常见适配场景UPF锚点变化后的行为IPv41需要固定IP的业务IP地址保持UPF可灵活选择IPv4v62一般移动宽带先断旧会话再建新会话IP地址变化IPv43需要平滑切换的实时业务新会话建立后释放旧会话IP地址在切换期间保持Ethernet1工业互联网、企业专网非IP链路主推服务化接口适配3.2 UPF选择与QoS Flow映射SMF、UPF和N4接口上到底发了什么UE的PDU会话建立请求到达AMF后AMF根据DNN和S-NSSAI选择SMFSMF再结合位置、能力、负载选择UPF。这个UPF的选择过程在信令上看不到UE发出来的消息只能在SMF到UPF的N4协商过程中推断。N4接口上SMF向UPF发送PFCP Session Establishment Request里面携带的关键参数包括F-SEIDFully Qualified Session Endpoint Identifier、PDU类型、QoS规则、以及转发规则FAR。UPF收到后返回PFCP Session Establishment Response带上UPF侧的F-SEID和Cause。这里我特别强调F-SEID因为N4会话的关联不靠Node ID而是靠SMF侧和UPF侧两套F-SEID互相指认后面PFCP Session Modification、Deletion全都基于它。QoS Flow的映射则要看另一组参数。SMF从EPS Bearer可吸收5G QoS Flow的映射关系里拿到的不是单一数值而是每个QoS Flow对应的5QI、GBR属性、以及分配与保留优先级ARP。IPv4、IPv6、Ethernet类型不同的时候QoS Flow的NumOfPackets、PacketDetectionRule也会有差异这里先不展开。对这些参数不熟的人分析N4接口时最容易犯的错是把PFCP层里的QERQoS Enforcement Rule当成空口上的QoS参数去对照DRB的配置。实际上QER只负责UPF侧的执行策略空口DRB的承载级别映射要到NGAP的PDU Session Resource Setup Request里去看QosFlowSetupRequestListItem和对应的DRB ID层级不同不要混在一起看。3.3 N1/N2/N4三条链路怎么串起来读从请求到DRB建立的完整路径PDU会话建立不是只有一条路径而是N1、N2、N4三个接口同时推进。我通常按这个顺序串读消息。第一条是N1路径UE到AMF。UE发PDU Session Establishment RequestAMF返回PDU Session Establishment Accept之前会通过NGAP的DL NAS Transport把它转发给gNB再由gNB通过RRC重配置携带给UE。这条路径里最重要的信息就是PDU Session Establish Result里的Authorized QoS Rules和IP地址分配结果。第二条是N2路径AMF到gNB。AMF向gNB发PDU Session Resource Setup Request里面携带的是PDU会话对应的QoS Flow列表、gNB侧的TEID、S-NSSAI、以及每个QoS Flow映射到哪个DRB的建议。gNB收到后返回PDU Session Resource Setup Response带出gNB分配的下行TEID和空口DRB配置结果。第三条是N4路径SMF到UPF。SMF和UPF之间完成PFCP Session Establishment建立UU、N3、N6方向的转发通道给UPF下发转发规则和QoS执行规则。很多资料把这三条路径分开画但实际排障要合在一起看。我常用的方法是选定一个PDU会话的GUTI或SUPI把N1/N2/N4消息按时间排列观察授权QoS规则是否先于N4协商完成这一时序。如果SMF先把Accept发给UE但UPF的PFCP会话还没建立成功那用户面数据必然在UPF侧积压或丢弃现象就是UE显示已连接但业务流量跑不起来。这种问题只看空口或只看N2抓包根本发现不了必须三个接口对齐。4. 信令看不明白的常见原因五个排查切入点4.1 现象Wireshark里只看到NGAP层NAS消息全是乱码或空抓了N2接口的包展开消息只看到Initiating Message和Successful Outcome看不到NAS内容或者NAS部分显示为不可解的数据。原因NAS消息在NGAP里是作为透明容器传输的Wireshark默认不一定会自动解析RRC容器里的NAS 5GS。如果抓包是空口Uu接口采集NAS躲在RRC层的ULInformationTransfer/DLInformationTransfer里面Wireshark需要从RRC消息里逐层解下去。解决在Wireshark里把NAS 5GS的解析依赖打开。最常见的做法是确认NGAP的Protocol配置没有被关闭同时使用过滤表达式ngap或nas_5gs来定位消息如果是自主开发的解析脚本检查是否在NGAP的ProtocolIE-Field里预设了nAS-PDU字段的解码入口。另一个实用技巧是不要只抓SCTP 3843端口把SCTP 3842端口也一起抓下来NGAP控制面和SCTP偶联检测的包往往混在一起过滤时先按SCTP端口排除掉心跳包。4.2 现象SCTP重传被当成业务流程失败在抓包里看到同一对IP和端口间出现大量SCTP DATA重传就认为业务重复发送了甚至把这个当成核心网侧有问题。原因SCTP的重传机制和TCP类似是传输层在丢包或链路拥塞时的自动恢复行为。如果NGAP偶联在这段时间内发生抖动SCTP会主动重传DATA块这属于传输层行为不代表UE和AMF之间的NAS消息被重新处理。解决先按SCTP重传过滤sctp.data和时间戳结合确认是单包重传还是整段偶联重建。正常情况下SCTP的T3-rtx重传次数是3次超过后才会关闭偶联。如果重传频繁但业务流程最终成功那问题在网络链路质量不在信令流程。在分析工具里要开启标记重传包功能并在统计时把重传包排除掉避免误判。4.3 现象NGAP的UE上下文ID和PFCP的会话ID对不上拿NGAP里Initial Context Setup Request的AMF UE NGAP ID去N4接口的消息里找相同数值找不到怀疑流程错乱。原因NGAP和PFCP是两套完全独立的会话标识体系。NGAP上下文由AMF在N2接口上分配AMF UE NGAP ID和RAN UE NGAP ID只在gNB与AMF之间有含义PFCP会话由SMF在N4接口上管理F-SEID才是在SMF和UPF之间唯一标识一条PDU会话的凭据。它们之间没有共同ID只有通过PDU Session Resource Setup Request里携带的相关的IP地址、TEID才能建立间接关联。解决跨接口关联时不要再按ID直接匹配。正确做法是以PDU会话的SUPI和DNN为基础N2侧记录gNB侧TEIDN4侧记录UPF侧F-SEID再用N3接口的TEID把两侧的数关联起来。如果必须用自动脚本关联建议建立SUPI DNN UL TEID的三元组作为主键不要单独依赖任何一个ID。4.4 现象把Service Request当成切换流程UE从空闲态恢复数据业务信令里先是Service Request然后是NGAP的Initial Context Setup Request有人把它当成基于N2的切换判定逻辑直接错位。原因Service Request和Handover的启动者完全不同。服务请求是UE从CM-IDLE状态发起UE侧要恢复用户面资源触发AMF重建NGAP上下文切换则是gNB基于测量评估决定让UE迁移到另一个小区源gNB和目标gNB之间通过Xn或N2进行小区切换。两者消息序列相似但关键差异在于是否出现Handover Preparation、Handover Resource Allocation等流程。解决判断一个信令过程是否是切换先看两个关键信息一是RRC建立原因里是否为mt-Access或mo-Signalling它们对应服务请求二是NGAP消息类型里是否出现Path Switch Request或Handover Required。只要消息序列中出现Handover Required HANDOVER REQUEST并携带目标Cell ID就必然是切换。服务请求则不会携带目标小区信息只恢复原上下文。4.5 现象把NAS的5GMM Cause和NGAP Cause混用UE注册被拒看NGAP层时的Cause值为11认为是终端问题但实际NAS层5GMM Cause才是真正原因Cause为7表示失败原因是5GMM拒绝。原因NAS层和NGAP层各自的Cause根本不同NGAP的Cause描述的是N2接口上gNB与AMF之间的传输失败、资源不足等NAS的5GMM Cause则是UE和AMF之间的移动性管理结果。两层Cause没有对应关系拿NGAP Cause去判断NAS流程结果永远找不准。解决分析注册失败、PDU会话建立失败时先看最内层的NAS消息Cause值再看外层NGAP的Cause值。若NAS消息是5GMM cause 7或5GSM cause 32再回到NGAP找对应的gNB或AMF侧的行为参考。如果NAS层已被解密直接以NAS层Cause为准如果NAS层不可解才依据NGAP的Cause猜测是传输链路问题还是上下文丢失问题。5. 搭一个信令分析工作台Wireshark、过滤表达式和一段统计脚本5.1 用Wireshark抓N2和N4接口SCTP端口与PFCP以太网类型配置绝大多数5G信令分析场景都以N2和N4接口为主因为空口采集往往需要专用工具而N2/N4的流量可以从核心网接入侧镜像口拿到。Wireshark默认能识别大部分5G信令协议但要正确解码N2上的NGAP必须让Wireshark知道NGAP跑在SCTP端口上默认是3843。抓包时用下面的过滤表达式能直接筛出N2控制面消息。# 抓取NGAP控制面流量SCTP端口3843 tcpdump -i any -s 0 -w ngap.pcap tcp port 3843# 抓取PFCP控制面流量UDP端口8805 tcpdump -i any -s 0 -w n4.pcap udp port 8805第一条命令把SCTP 3843端口的所有包存为ngap.pcap这是N2接口的控制面流量入口第二条命令抓UDP 8805端口这是N4接口的标准PFCP端口。抓包时加-s 0是为了抓全包长避免截断导致NGAP的容器内容不完整影响后续的NAS解码。如果现场环境里有多个网元建议加上具体的IP过滤比如host 192.168.10.1 and tcp port 3843避免把不必要的流量混进来。把pcap文件拖进Wireshark后手动检查NGAP层能否正常显示。如果协议列里只显示SCTP而不显示NGAP说明解码器没挂上需要到Edit → Preferences → Protocols里找到NGAP确认Decoder Profile里设置了SCTP端口3843。PFCP同理检查PFCP解码器是否关联到UDP 8805端口。5.2 高效定位消息一组能直接用的显示过滤表达式Wireshark的显示过滤表达式是分析信令效率的关键。下面是几个我几乎每天在用的过滤规则。# 只看NGAP的Initial UE Message过滤掉心跳 ngap ngap.procedureCode 8 # 只看NAS 5GS的注册请求消息消息类型值为1 nas_5gs.message_type 0x01 # 只看PDU会话建立请求消息类型值为0xc1 nas_5gs.message_type 0xc1 # 只看PFCP会话建立消息消息类型值为1 pfcp.msg_type 1第一条过滤表达式中的ngap.procedureCode 8对应NGAP的Initial UE Message这个流程值可以在ngap.h里确认第二条把NAS层消息限定为Registration Request这里0x01是3GPP TS 24.501中定义的Registration Request消息类型第三条0xc1是PDU Session Establishment Request第四条针对N4接口的PFCP Session Establishment。使用的时候要注意NGAP的procedureCode和PFCP的msg_type都是十六进制数要从协议文档里对应查到不要凭记忆硬记。5.3 写一段Python脚本统计各流程消息次数抓包文件大了之后靠肉眼数消息不现实。这段脚本从Wireshark导出的JSON文件里读取所有消息统计各消息类型出现的次数快速得到整体流程分布。import json import sys def count_messages(json_file): with open(json_file, r, encodingutf-8) as f: packets json.load(f) stat_dict {} for pkt in packets: # 获取协议列里是否包含NGAP、NAS_5GS、PFCP protocols pkt.get(_source, {}).get(layers, {}).keys() for proto in protocols: if proto in (ngap, nas_5gs, pfcp): stat_dict[proto] stat_dict.get(proto, 0) 1 return stat_dict if __name__ __main__: # 用法: python count_5g_messages.py export.json stat count_messages(sys.argv[1]) for k, v in sorted(stat.items(), keylambda x: x[1], reverseTrue): print(f{k}: {v})这个脚本的逻辑是读取Wireshark导出的JSON文件遍历每一条包的layers字段判断其是否包含ngap、nas_5gs、pfcp三种协议之一命中就累加计数。使用前需要在Wireshark里执行File → Export Packet Dissections → As JSON把pcap导成包含_source.layers的JSON文件。参数上脚本只接受一个参数即JSON路径如果导出的JSON文件没有_source.layers字段说明导出时勾选的字段不全需要重新导出。这个统计结果配合时间轴可以快速看出流程集中在哪几分钟、哪类消息占比异常从而定位问题窗口。6. 用注册流程做一次全链路验证从一条Log里倒推网络配置6.1 固定五个检查点把注册流程读成一个配置清单拿到一条注册流程的Log或抓包我习惯按固定顺序检查五个位置第一步看注册请求里的SUCI还是5G-GUTI第二步看Request NSSAI中的S-NSSAI第三步看鉴权响应里的AUTN校验结果第四步看AMF返回的Allowed NSSAI和TAC列表第五步看PDU会话建立请求是否触发。这五个位置看完整个网络的切片配置、签约数据、TAI规划、DNN配置基本都能摸清楚。这套顺序不只是为了判断流程有没有走通更核心的价值在于倒推配置。比如Allowed NSSAI里如果包含了多个S-NSSAI配合其SST值能推断AMF支持哪些切片TAC列表则能判断切换和注册更新的边界在哪。6.2 从信令倒推配置实例说明我在分析一个商用网络的注册Log时通过四步就从抓包里还原了它的配置注册请求携带5G-GUTI说明这是GUTI重注册AMF返回的Allowed NSSAI有两个切片SST分别为1和2TAC列表里有三个值PDU会话建立请求里的DNN是internet。这四个信息直接对应了AMF配置的TAC列表、签约数据里允许的切片、以及SMF为这个DNN分配的地址池。我自己最早做信令分析的时候只盯着NAS消息的字面内容不看时序、不跨接口结果在现网一个sle服务请求失败的问题里翻了车——单看NAS层一条消息没问题后来把N2接口的SCTP重传和NGAP上下文恢复对齐才发现是传输链路抖动。从那以后我每次拿到抓包都会强制自己先画一条从UE到UPF的时序列再把每条消息填进去形成习惯之后定位信令问题的速度快了很多也少了很多看谁都像没毛病的尴尬时刻。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/6 13:40:58 · 阅读 1.2k 5G核心网信令分析：从注册流程到PDU会话建立
简介5G信令流程解析是移动通信领域的重要学习主题这份docx文档面向5G初学者、通信专业学生及从业者系统整理了信令流程的核心知识点与学习方法。内容从背景知识切入对比5G相较于前代在速率、时延与连接密度方面的提升随后介绍UE、gNB、核心网等关键网元及相互间的通信关系重点讲解了控制信令与用户数据信令的区别并覆盖接入过程、鉴权安全、移动性管理、资源分配与调度、服务质量保障等主要环节。文档还给出了系统学习、深入原理、仿真实践、案例分析和持续跟进等实用学习技巧有助于读者将理论对应到实际网络场景中为后续从事5G运维、优化或研究打下基础。压缩包共1个docx文件大小约11KB全文内容精炼、条理清晰方便在碎片时间快速阅读学习。该文档已有402人学习适合准备系统入门5G信令或进行阶段性复习的读者。1. 5G信令流程为什么难啃先建立一张全局图背信令最快的办法不是把TS 38.331、TS 24.501从头啃下来而是先接受一个反直觉的事实5G信令流程是一张状态图不是一串消息列表。注册、服务请求、PDU会话建立、切换、去注册每条流程看起来都是十几条消息来回但真正决定流程成败的往往只有几个关键参数——SUCI还是5G-GUTI、Request NSSAI里的切片值、PDU Session Type和SSC Mode的组合。这份5G信令流程解析信息介绍及学习技巧资源的价值就在这它不按协议章节讲而是按流程拆把每条消息里该看的字段、该留意的时序、容易踩的坑都串起来。适合刚转5G的网优、核心网交付测试、协议栈开发以及那些已经会用Wireshark抓包但不知道下一步看什么的人。2. 注册流程拆解从RRC到AMF一条注册消息里藏了四个关键字段2.1 注册请求里的四个必认字段SUCI、5G-GUTI、Request NSSAI和Registration Type注册流程是5G信令的基础几乎所有其他流程都建立在UE完成注册之后。我在看注册请求时不会从头到尾把每个IE都读一遍只盯四个字段。第一个是UE身份标识。UE第一次进网或没有有效GUTI时上报的是SUCISubscription Concealed Identifier这是SUPI加密后的结果。如果UE之前注册过会上报5G-GUTIAMF靠它能直接找到UE的上下文省掉整条鉴权链路。很多新手看到Registration Request里只有一个长长的SUCI字符串就觉得流程不对其实这恰恰说明UE真的是第一次注册或者AMF发生了改变。第二个是Request NSSAI也就是UE想用的切片。它直接决定了AMF会把这个注册请求路由到哪个AMF以及后续允许哪些网络切片。现网里最常见的注册失败原因之一就是Request NSSAI里的SST/SD组合在签约数据里不存在AMF返回的5GMM Cause是62No Network Slices Available。所以看注册请求时先抄下S-NSSAI的值再对照注册接受里的Allowed NSSAI一眼就能判断是UE的配置问题还是签约问题。第三个是Registration Type这是个很容易被看一眼就跳过的字段。它取值有三种Initial、Mobility Update、Periodic Update。其中Mobility Update后面通常会跟着一组TAI列表能看出UE在哪些位置区之间移动Periodic Update则不会走完整的鉴权AMF和UE之间的上下文直接复用。判断一个注册流程是正常周期性更新还是跨AMF的初始注册第一个就要看它。第四个是5GMM Cause在NAS消息里携带。它不只在注册拒绝里出现在后续的身份验证、安全模式控制里也会出现。我习惯把Cause值和对应的网元记录下来因为同一个Cause在不同阶段的含义完全不同比如Cause 3Illegal UE和Cause 6Illegal ME分别指向SIM卡和终端IMEI方向完全不同。2.2 鉴权链路5G-AKA和EAP-AKA什么时候会触发二次鉴权注册请求进了AMF之后AMF会向UDM取鉴权向量。这一步里AMF和UDM之间的消息是Nausf_UEAuthentication走的是HTTP/2而UE和AMF之间的NAS鉴权消息则通过gNB透明传输。这里有个容易混淆的点5G鉴权有两种机制5G-AKA和EAP-AKA。5G-AKA是默认机制AMF从UDM拿到的鉴权向量里包含RAND、AUTN、XRES、KSEAF等参数然后AMF向UE发送NAS Authentication RequestUE侧用USIM里的密钥计算AUTN校验网络合法性后再生成RES返回。EAP-AKA则是在需要二次认证、或UE是某些特殊终端时才会走整个流程会变成AMF转发EAP消息给UEUE完成EAP认证后再回到NAS安全模式。我看鉴权流程时最关注的不是加密算法而是两个地方一是Authentication Request里的AUTN和RAND是否成对如果UE侧的AUTN校验失败通常是因为网络侧和UE侧的密钥版本不一致常见于空口抓包遇到了老终端和新增密法的混用二是是否出现二次鉴权——某些企业定制网络的R17方案里会引入二次鉴权流程多一次AMF与AAA/EAP Server的交互如果以前的脚本直接按Authentication Request → Response → Security Mode Command判断流程结束就会误报失败。2.3 从gNB到AMFInitial UE Message里的TAC、CellId和RAN UE NGAP IDNAS消息要离开空口进入核心网封装在NGAP的Initial UE Message里从gNB发到AMF。这一步很多分析工具只显示NGAP层不展开RRC透明容器导致新手以为NAS消息丢了。实际上Initial UE Message里有几个NGAP IE是定位问题的重要依据。第一个是TAI它包含PLMN和TAC。如果TAI里的TAC和UE侧跟踪区列表里的TAC不一致AMF会认为UE所在位置超出注册范围触发Registered Area Reallocation并重新进行移动性注册更新。第二个是Cell ID在NR-CGI里它精确到小区配合TAC可以做越区覆盖和切换路径的关联分析。第三个是RAN UE NGAP IDgNB分配给这条UE连接的唯一标识不管后续是Initial Context Setup还是UE Context Release都靠它保持关联。除NGAP IE外Initial UE Message里有一个携带在RRC容器中的RRC Establishment Cause我在分析无线侧接入成功率时会对照它判断同一时间大量高优先级的接入请求可能是网络拥塞低优先级大量重试可能是配置错误导致的反复接入。从RRC Establishment Cause到RRC Setup、再到Initial UE Message整个过程配合gNB侧的时间和UE侧的时间差能定位接入瓶颈是在无线侧还是核心网侧。注册流程走到这里AMF对UE的合法性有了确认接下来会发送Security Mode Command建立NAS安全上下文然后下发Registration Accept。如果AMF下发的Allowed NSSAI里包含S-NSSAIUE才会继续发起PDU会话建立。这就是为什么我总把注册流程称为PDU会话的前置闸门——注册没过后面的流程连启动条件都没有。3. PDU会话建立流程参数组合才是考试重点别只背消息序列3.1 PDU Session Type和SSC Mode一组常见的错误组合PDU会话建立是5G承载用户面数据的核心流程也是信令分析中被误解最多的流程。误解的根源在于很多人把它的消息序列当成一个简单的请求——响应来看而实际上PDU会话建立是N1、N2、N4三个接口同时协作的结果任何一个接口的异常都会导致用户面数据无法转发。先看UE发起的PDU Session Establishment Request里最关键的两个参数组合。PDU Session Type决定UE需要什么类型的IP或非IP连接取值有IPv4、IPv6、IPv4v6和Ethernet非IP类型。SSC Mode则决定UE在PDU会话生命周期中的连续性保障取值有SSC Mode 1、Mode 2、Mode 3。它们不是随便搭配的选型逻辑通常是SSC Mode 1适合要求IP地址保持不变的场景无论UPF怎么改变IP地址不释放SSC Mode 3则是先建立新会话再释放旧会话适合在不中断业务的前提下切换UPF的场景SSC Mode 2则会先断开旧会话再建立新会话IP地址会变适合对连续性要求不高的场景。Group ID for Network Slicing、Non-3GPP access这些高级字段可以先不碰但上面这两个组合要记牢。现网里最典型的失败是UE请求IPv4v6但核心网只配置了IPv4地址池SMF返回的PDU会话建立拒绝里带5GSM Cause是32No DNN or unknown DNN或38Network not yet registered。另一种更隐蔽的情况是UE请求了SSC Mode 2但DNN对应的协议配置和下沉UPF的锚点位置冲突导致会话建立请求走到N4会话建立时才被UPF拒绝。PDU Session TypeSSC Mode常见适配场景UPF锚点变化后的行为IPv41需要固定IP的业务IP地址保持UPF可灵活选择IPv4v62一般移动宽带先断旧会话再建新会话IP地址变化IPv43需要平滑切换的实时业务新会话建立后释放旧会话IP地址在切换期间保持Ethernet1工业互联网、企业专网非IP链路主推服务化接口适配3.2 UPF选择与QoS Flow映射SMF、UPF和N4接口上到底发了什么UE的PDU会话建立请求到达AMF后AMF根据DNN和S-NSSAI选择SMFSMF再结合位置、能力、负载选择UPF。这个UPF的选择过程在信令上看不到UE发出来的消息只能在SMF到UPF的N4协商过程中推断。N4接口上SMF向UPF发送PFCP Session Establishment Request里面携带的关键参数包括F-SEIDFully Qualified Session Endpoint Identifier、PDU类型、QoS规则、以及转发规则FAR。UPF收到后返回PFCP Session Establishment Response带上UPF侧的F-SEID和Cause。这里我特别强调F-SEID因为N4会话的关联不靠Node ID而是靠SMF侧和UPF侧两套F-SEID互相指认后面PFCP Session Modification、Deletion全都基于它。QoS Flow的映射则要看另一组参数。SMF从EPS Bearer可吸收5G QoS Flow的映射关系里拿到的不是单一数值而是每个QoS Flow对应的5QI、GBR属性、以及分配与保留优先级ARP。IPv4、IPv6、Ethernet类型不同的时候QoS Flow的NumOfPackets、PacketDetectionRule也会有差异这里先不展开。对这些参数不熟的人分析N4接口时最容易犯的错是把PFCP层里的QERQoS Enforcement Rule当成空口上的QoS参数去对照DRB的配置。实际上QER只负责UPF侧的执行策略空口DRB的承载级别映射要到NGAP的PDU Session Resource Setup Request里去看QosFlowSetupRequestListItem和对应的DRB ID层级不同不要混在一起看。3.3 N1/N2/N4三条链路怎么串起来读从请求到DRB建立的完整路径PDU会话建立不是只有一条路径而是N1、N2、N4三个接口同时推进。我通常按这个顺序串读消息。第一条是N1路径UE到AMF。UE发PDU Session Establishment RequestAMF返回PDU Session Establishment Accept之前会通过NGAP的DL NAS Transport把它转发给gNB再由gNB通过RRC重配置携带给UE。这条路径里最重要的信息就是PDU Session Establish Result里的Authorized QoS Rules和IP地址分配结果。第二条是N2路径AMF到gNB。AMF向gNB发PDU Session Resource Setup Request里面携带的是PDU会话对应的QoS Flow列表、gNB侧的TEID、S-NSSAI、以及每个QoS Flow映射到哪个DRB的建议。gNB收到后返回PDU Session Resource Setup Response带出gNB分配的下行TEID和空口DRB配置结果。第三条是N4路径SMF到UPF。SMF和UPF之间完成PFCP Session Establishment建立UU、N3、N6方向的转发通道给UPF下发转发规则和QoS执行规则。很多资料把这三条路径分开画但实际排障要合在一起看。我常用的方法是选定一个PDU会话的GUTI或SUPI把N1/N2/N4消息按时间排列观察授权QoS规则是否先于N4协商完成这一时序。如果SMF先把Accept发给UE但UPF的PFCP会话还没建立成功那用户面数据必然在UPF侧积压或丢弃现象就是UE显示已连接但业务流量跑不起来。这种问题只看空口或只看N2抓包根本发现不了必须三个接口对齐。4. 信令看不明白的常见原因五个排查切入点4.1 现象Wireshark里只看到NGAP层NAS消息全是乱码或空抓了N2接口的包展开消息只看到Initiating Message和Successful Outcome看不到NAS内容或者NAS部分显示为不可解的数据。原因NAS消息在NGAP里是作为透明容器传输的Wireshark默认不一定会自动解析RRC容器里的NAS 5GS。如果抓包是空口Uu接口采集NAS躲在RRC层的ULInformationTransfer/DLInformationTransfer里面Wireshark需要从RRC消息里逐层解下去。解决在Wireshark里把NAS 5GS的解析依赖打开。最常见的做法是确认NGAP的Protocol配置没有被关闭同时使用过滤表达式ngap或nas_5gs来定位消息如果是自主开发的解析脚本检查是否在NGAP的ProtocolIE-Field里预设了nAS-PDU字段的解码入口。另一个实用技巧是不要只抓SCTP 3843端口把SCTP 3842端口也一起抓下来NGAP控制面和SCTP偶联检测的包往往混在一起过滤时先按SCTP端口排除掉心跳包。4.2 现象SCTP重传被当成业务流程失败在抓包里看到同一对IP和端口间出现大量SCTP DATA重传就认为业务重复发送了甚至把这个当成核心网侧有问题。原因SCTP的重传机制和TCP类似是传输层在丢包或链路拥塞时的自动恢复行为。如果NGAP偶联在这段时间内发生抖动SCTP会主动重传DATA块这属于传输层行为不代表UE和AMF之间的NAS消息被重新处理。解决先按SCTP重传过滤sctp.data和时间戳结合确认是单包重传还是整段偶联重建。正常情况下SCTP的T3-rtx重传次数是3次超过后才会关闭偶联。如果重传频繁但业务流程最终成功那问题在网络链路质量不在信令流程。在分析工具里要开启标记重传包功能并在统计时把重传包排除掉避免误判。4.3 现象NGAP的UE上下文ID和PFCP的会话ID对不上拿NGAP里Initial Context Setup Request的AMF UE NGAP ID去N4接口的消息里找相同数值找不到怀疑流程错乱。原因NGAP和PFCP是两套完全独立的会话标识体系。NGAP上下文由AMF在N2接口上分配AMF UE NGAP ID和RAN UE NGAP ID只在gNB与AMF之间有含义PFCP会话由SMF在N4接口上管理F-SEID才是在SMF和UPF之间唯一标识一条PDU会话的凭据。它们之间没有共同ID只有通过PDU Session Resource Setup Request里携带的相关的IP地址、TEID才能建立间接关联。解决跨接口关联时不要再按ID直接匹配。正确做法是以PDU会话的SUPI和DNN为基础N2侧记录gNB侧TEIDN4侧记录UPF侧F-SEID再用N3接口的TEID把两侧的数关联起来。如果必须用自动脚本关联建议建立SUPI DNN UL TEID的三元组作为主键不要单独依赖任何一个ID。4.4 现象把Service Request当成切换流程UE从空闲态恢复数据业务信令里先是Service Request然后是NGAP的Initial Context Setup Request有人把它当成基于N2的切换判定逻辑直接错位。原因Service Request和Handover的启动者完全不同。服务请求是UE从CM-IDLE状态发起UE侧要恢复用户面资源触发AMF重建NGAP上下文切换则是gNB基于测量评估决定让UE迁移到另一个小区源gNB和目标gNB之间通过Xn或N2进行小区切换。两者消息序列相似但关键差异在于是否出现Handover Preparation、Handover Resource Allocation等流程。解决判断一个信令过程是否是切换先看两个关键信息一是RRC建立原因里是否为mt-Access或mo-Signalling它们对应服务请求二是NGAP消息类型里是否出现Path Switch Request或Handover Required。只要消息序列中出现Handover Required HANDOVER REQUEST并携带目标Cell ID就必然是切换。服务请求则不会携带目标小区信息只恢复原上下文。4.5 现象把NAS的5GMM Cause和NGAP Cause混用UE注册被拒看NGAP层时的Cause值为11认为是终端问题但实际NAS层5GMM Cause才是真正原因Cause为7表示失败原因是5GMM拒绝。原因NAS层和NGAP层各自的Cause根本不同NGAP的Cause描述的是N2接口上gNB与AMF之间的传输失败、资源不足等NAS的5GMM Cause则是UE和AMF之间的移动性管理结果。两层Cause没有对应关系拿NGAP Cause去判断NAS流程结果永远找不准。解决分析注册失败、PDU会话建立失败时先看最内层的NAS消息Cause值再看外层NGAP的Cause值。若NAS消息是5GMM cause 7或5GSM cause 32再回到NGAP找对应的gNB或AMF侧的行为参考。如果NAS层已被解密直接以NAS层Cause为准如果NAS层不可解才依据NGAP的Cause猜测是传输链路问题还是上下文丢失问题。5. 搭一个信令分析工作台Wireshark、过滤表达式和一段统计脚本5.1 用Wireshark抓N2和N4接口SCTP端口与PFCP以太网类型配置绝大多数5G信令分析场景都以N2和N4接口为主因为空口采集往往需要专用工具而N2/N4的流量可以从核心网接入侧镜像口拿到。Wireshark默认能识别大部分5G信令协议但要正确解码N2上的NGAP必须让Wireshark知道NGAP跑在SCTP端口上默认是3843。抓包时用下面的过滤表达式能直接筛出N2控制面消息。# 抓取NGAP控制面流量SCTP端口3843 tcpdump -i any -s 0 -w ngap.pcap tcp port 3843# 抓取PFCP控制面流量UDP端口8805 tcpdump -i any -s 0 -w n4.pcap udp port 8805第一条命令把SCTP 3843端口的所有包存为ngap.pcap这是N2接口的控制面流量入口第二条命令抓UDP 8805端口这是N4接口的标准PFCP端口。抓包时加-s 0是为了抓全包长避免截断导致NGAP的容器内容不完整影响后续的NAS解码。如果现场环境里有多个网元建议加上具体的IP过滤比如host 192.168.10.1 and tcp port 3843避免把不必要的流量混进来。把pcap文件拖进Wireshark后手动检查NGAP层能否正常显示。如果协议列里只显示SCTP而不显示NGAP说明解码器没挂上需要到Edit → Preferences → Protocols里找到NGAP确认Decoder Profile里设置了SCTP端口3843。PFCP同理检查PFCP解码器是否关联到UDP 8805端口。5.2 高效定位消息一组能直接用的显示过滤表达式Wireshark的显示过滤表达式是分析信令效率的关键。下面是几个我几乎每天在用的过滤规则。# 只看NGAP的Initial UE Message过滤掉心跳 ngap ngap.procedureCode 8 # 只看NAS 5GS的注册请求消息消息类型值为1 nas_5gs.message_type 0x01 # 只看PDU会话建立请求消息类型值为0xc1 nas_5gs.message_type 0xc1 # 只看PFCP会话建立消息消息类型值为1 pfcp.msg_type 1第一条过滤表达式中的ngap.procedureCode 8对应NGAP的Initial UE Message这个流程值可以在ngap.h里确认第二条把NAS层消息限定为Registration Request这里0x01是3GPP TS 24.501中定义的Registration Request消息类型第三条0xc1是PDU Session Establishment Request第四条针对N4接口的PFCP Session Establishment。使用的时候要注意NGAP的procedureCode和PFCP的msg_type都是十六进制数要从协议文档里对应查到不要凭记忆硬记。5.3 写一段Python脚本统计各流程消息次数抓包文件大了之后靠肉眼数消息不现实。这段脚本从Wireshark导出的JSON文件里读取所有消息统计各消息类型出现的次数快速得到整体流程分布。import json import sys def count_messages(json_file): with open(json_file, r, encodingutf-8) as f: packets json.load(f) stat_dict {} for pkt in packets: # 获取协议列里是否包含NGAP、NAS_5GS、PFCP protocols pkt.get(_source, {}).get(layers, {}).keys() for proto in protocols: if proto in (ngap, nas_5gs, pfcp): stat_dict[proto] stat_dict.get(proto, 0) 1 return stat_dict if __name__ __main__: # 用法: python count_5g_messages.py export.json stat count_messages(sys.argv[1]) for k, v in sorted(stat.items(), keylambda x: x[1], reverseTrue): print(f{k}: {v})这个脚本的逻辑是读取Wireshark导出的JSON文件遍历每一条包的layers字段判断其是否包含ngap、nas_5gs、pfcp三种协议之一命中就累加计数。使用前需要在Wireshark里执行File → Export Packet Dissections → As JSON把pcap导成包含_source.layers的JSON文件。参数上脚本只接受一个参数即JSON路径如果导出的JSON文件没有_source.layers字段说明导出时勾选的字段不全需要重新导出。这个统计结果配合时间轴可以快速看出流程集中在哪几分钟、哪类消息占比异常从而定位问题窗口。6. 用注册流程做一次全链路验证从一条Log里倒推网络配置6.1 固定五个检查点把注册流程读成一个配置清单拿到一条注册流程的Log或抓包我习惯按固定顺序检查五个位置第一步看注册请求里的SUCI还是5G-GUTI第二步看Request NSSAI中的S-NSSAI第三步看鉴权响应里的AUTN校验结果第四步看AMF返回的Allowed NSSAI和TAC列表第五步看PDU会话建立请求是否触发。这五个位置看完整个网络的切片配置、签约数据、TAI规划、DNN配置基本都能摸清楚。这套顺序不只是为了判断流程有没有走通更核心的价值在于倒推配置。比如Allowed NSSAI里如果包含了多个S-NSSAI配合其SST值能推断AMF支持哪些切片TAC列表则能判断切换和注册更新的边界在哪。6.2 从信令倒推配置实例说明我在分析一个商用网络的注册Log时通过四步就从抓包里还原了它的配置注册请求携带5G-GUTI说明这是GUTI重注册AMF返回的Allowed NSSAI有两个切片SST分别为1和2TAC列表里有三个值PDU会话建立请求里的DNN是internet。这四个信息直接对应了AMF配置的TAC列表、签约数据里允许的切片、以及SMF为这个DNN分配的地址池。我自己最早做信令分析的时候只盯着NAS消息的字面内容不看时序、不跨接口结果在现网一个sle服务请求失败的问题里翻了车——单看NAS层一条消息没问题后来把N2接口的SCTP重传和NGAP上下文恢复对齐才发现是传输链路抖动。从那以后我每次拿到抓包都会强制自己先画一条从UE到UPF的时序列再把每条消息填进去形成习惯之后定位信令问题的速度快了很多也少了很多看谁都像没毛病的尴尬时刻。希望帮到你。本文还有配套的精品资源点击获取