ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

5G信令流程解析:从注册到PDU会话的排障实战

2026/10/6 4:09:56 拓冰建站 浏览量
5G信令流程解析:从注册到PDU会话的排障实战 简介一份围绕5G信令流程解析的入门资料适合移动通信初学者、网络运维人员及相关专业学生用以理解5G网络中关键信令过程并掌握系统学习方法。压缩包仅含1个docx文档大小11KB内容结构清晰、篇幅精炼便于通读与速览目前已有402人学习。文档从5G背景知识切入说明高速率、低时延、大连接特性如何使信令流程更复杂进而介绍用户终端UE、基站gNB、核心网Core Network等基本概念并把信令分为控制信令与用户数据信令两类。之后围绕接入过程、鉴权与安全、移动性管理、资源分配与调度、服务质量保障等环节展开逐项解析各自作用学习技巧部分给出系统学习、深入理解、实践操作、案例分析、持续跟进五条路径强调通过仿真与真实案例提升实操能力。读者可借此快速搭建5G信令流程的知识框架理清各环节逻辑关系为后续工程实践或技术研究提供参考。1. 5G信令流程解析为什么流程图背熟了现网日志还是看不动前阵子帮一个转5G核心网的朋友看日志他在网管平台拉了一段注册失败的信令UE一连发了三次带相同5G-GUTI的Registration RequestAMF那边就像没收到一样最后UE自己放弃屏幕上只剩一串看不懂的NAS cause。他流程图背得很熟单看每条消息也认识就是拼不出“谁在等谁、为什么重发、该查哪个网元”。这其实是大多数人学5G信令流程解析的真实状态知道“是什么”但离“能排障”还差一层。下面我按“先搭骨架、再拆注册、后上工具、最后避坑”的路径把这个方向讲透适合网优转核心网、协议栈测试以及刚入行的通信新人。2. 搭知识骨架5G信令涉及的接口、协议栈与学习顺序一个很常见的误区是以为5G信令就是NGAP一条线。实际抓包时UE与核心网之间的NAS对话、基站与核心网之间的NGAP对话、核心网内部服务化接口的HTTP/2消息经常叠加在同一条时间轴上。脑子里没有一张分层地图看再多信令流程图都是散的。2.1 一张表读懂5G信令面N1/N2/NG接口和协议栈分层5G控制面可以按“接口”切成三块空口Uu上的RRC、N2口上的NGAP、以及核心网内部的SBA服务化接口。NAS消息比较特殊它不从属于某个物理接口而是“搭车”走在空口装在RRC消息里在N2口装在NGAP的NAS-PDU字段里。先记住这一点后面看Wireshark时不会迷路。接口/场景协议栈主要承载内容新手常犯的错Uu控制面RRC / PDCP / RLC / MAC / PHYRRC连接管理、测量报告、NAS透传把RRC当作NASN1NAS5GMM 5GSM注册、鉴权、身份识别、PDU会话管理忽略NAS消息是“搭车”的N2NG-CNGAP / SCTP / IPInitial UE Message、UE Context Setup等只看NGAP不看里面的NAS-PDUNG-U用户面GTP-U / UDP / IP用户数据包拿GTP-U报文分析信令Xn-CXnAP / SCTP / IP切换准备、SN状态传输混淆Xn切换和N2切换核心网内部HTTP/2 JSONNudr、Numf、Nsmf等服务化调用以为SBI只有一种调用模型从这表能看出一个关键结论5G信令流程从来不是“一条消息走到底”而是每到一个网元信令就从一种协议换成另一种协议。比如UE发出注册请求空口先走RRCgNB收到后解掉RRC把NAS-PDU原封不动塞进NGAP的Initial UE Message发给AMFAMF又通过SBI向UDM查签约数据。同一个用户意图在三层协议里分别表达。2.2 信令流程的四个大家族注册、会话、移动性、去注册5G信令流程看着多按触发场景能收敛成四个大家族。第一是注册流程包含开机初始注册、移动注册更新、周期注册更新、紧急注册它是身份的建立。第二是PDU会话流程负责建、改、删数据通道。第三是移动性流程分Xn切换和N2切换。第四是去注册分为UE发起的和网络侧发起的。另外还有切片相关流程但本质是挂在注册和PDU会话里的子流程。流程族典型触发核心网参与网元最常见的故障点注册开机、跨TA移动、周期定时器AMF、UDM、AUSF鉴权失败、切片不被允许PDU会话建立应用请求、IMS注册AMF、SMF、UPFUPF选择失败、DNN配置不匹配切换信号变差、负载均衡AMF、SMF、UPF、目标gNB路径切换失败、Xn口不通去注册关机、显示关闭5GAMF、UDM、SMFNAS消息未加完整性保护被拒学习中我建议按“注册 PDU会话建立”先入手。5G里这两个流程经常嵌套注册请求里可能带着PDU会话建立请求注册接受里也可能带着PDU会话建立接受。把这两个连起来跑通就覆盖了日常排障里至少七成的信令场景。2.3 先NAS后AS、先注册后会话为什么这个顺序能少走弯路学习顺序上我一般会推荐“先NAS后AS”。NAS是UE和AMF之间的语义层决定“你是什么身份、能不能接入、要什么样的网络切片”而AS层像一条运输通道gNB在这条通道里干活但真正做决策的是NAS。直接啃NGAP容易陷在传输细节里丢了业务语义。还有个顺序是“先注册后会话”因为注册流程里能看到完整的鉴权、安全上下文、策略下发而这些上下文正是PDU会话建立的前提。注意别一上来就啃TS 23.501或TS 24.501全文先拿一张注册流程图配合抓包看遇到不懂的消息再回去翻规范。规范是字典不是入门书。3. 把注册流程拆开看从UE到AMF的消息封装、鉴权与状态落地注册是5G信令里最值得精读的流程因为它几乎把NAS、NGAP、SBI三种协议都串了一遍。下面按一条“开机初始注册”来拆所有步骤都是现网信令跟踪平台里能直接拉到的消息名。3.1 注册请求从哪里来RRC连接建立与NGAP Initial UE MessageUE要发注册请求第一步不是直接吐NAS消息而是先在空口做RRC连接建立。UE发RRC Setup RequestgNB回RRC SetupUE再回RRC Setup Complete。注意这时“RRC Setup Complete”里已经带上了第一条NAS消息——Registration Request。gNB解出NAS-PDU后向AMF发NGAP的Initial UE Message把这条NAS-PDU作为其中的一个IE装进去。这个阶段需要关注的关键IE在现网页面上常看到这三个IE名方向含义排障时看什么RAN-UE-NGAP-IDgNB → AMF基站侧UE编号后续所有该UE消息都带它NAS-PDUgNB → AMF透传的NAS消息消息类型是否为Registration RequestTAIgNB → AMF当前跟踪区跟签约数据里的TAI List比对PLMN IDgNB → AMF选择的公共陆地移动网有没有选错运营商初学者容易在这里翻车把“Initial UE Message”理解成“核心网给UE的第一条消息”。其实它的意思是“gNB第一次为这个UE向AMF发消息”方向是从基站到核心网别搞反。3.2 鉴权与安全上下文AMF如何确认“你是谁、你该不该接入”AMF收到Initial UE Message后先看NAS消息里的5G-GUTI或SUCI。如果只有一个SUCI就需要回Identity Request让UE上报永久身份。随后进入鉴权流程AMF向AUSF/UDM取鉴权向量AUSF返回RAND和AUTNAMF把Authentication Request发给UEUE侧用USIM里的密钥和OPc验证网络侧AUTN合法后回Authentication Response网络比对XRES和RES*一致才算“你是谁”得到确认。紧接着是NAS安全上下文建立AMF发Security Mode Command指定加密算法和完整性保护算法UE回Security Mode Complete。从这之后NAS消息就有了加密和完整性保护抓包里再看到的NAS消息头还在但内容已经是密文。这个现象在现网跟踪里非常常见——前面几条消息还能看到明文关键IESMC之后只剩消息类型中间字段变成一串十六进制。注意鉴权失败大部分不是算法问题而是USIM里的OPc或Ki和UDM签约数据不一致。实验室里改错一个OPc表现就是UE反复在Authentication Request和Authentication Failure之间循环。看到这个循环先查HLR/HSS侧密钥。3.3 注册接受之后5GMM状态、切片列表与PDU会话的关系鉴权通过后AMF向gNB发Initial Context Setup Request把UE上下文、Allowed NSSAI、PDU会话列表一起给gNB。gNB建完UE上下文后回Initial Context Setup Response。最后AMF向UE发Registration Accept里面带着新分配的5G-GUTI、TAI List、Allowed NSSAI和默认切片信息。如果AMF拒绝回的是Registration Reject根因要看5GMM cause而不是NGAP cause——这是新手最容易查错层的地方。从状态机角度看注册流程结束时UE和AMF侧都进入5GMM-REGISTERED。但这里有个大坑REGISTERED不代表能上网。注册只是打通了控制面用户面还差一个PDU会话建立流程。所以网优平台上看到UE状态是“已注册”但业务不通下一步不是查RRU而是去查PDU会话建立流程有没有跑起来。状态含义和PDU会话的关系5GMM-DEREGISTERED未注册不能发起会话5GMM-REGISTERED-INITIATED注册中网络侧暂不处理会话5GMM-REGISTERED已注册可发起会话建立5GSM会话已激活数据面就绪依赖PDU会话建立成功4. PDU会话建立实操用开源5G核心网加Wireshark把信令跑出来只靠看图和背消息名很难建立“信令时序感”。我一般建议动手搭一套实验环境把开源5G核心网和模拟基站、模拟UE跑起来再用Wireshark抓NGAP和NAS消息对照规范一步一步看。这个环境能完整复现注册、鉴权、PDU会话建立和去注册是学习性价比最高的路径。4.1 抓5G信令的三条路实验室模拟、现网跟踪与接口镜像常见做法有三种。第一种是实验室自建用开源核心网加模拟基站可控性强能随意构造失败场景也是下文要展示的。第二种是用现网网管平台的信令跟踪功能能看真实业务但通常只有消息名和IE拿不到原始码流适合验证学习结论不适合做细节分析。第三种是在N2口或N3口做流量镜像能拿到完整pcap但涉及现网数据合规普通学习环境不建议碰。对学习这件事我强烈建议从第一种开始跑通后再对照第二种的现网日志找差异。4.2 用Open5GS加UERANSIM跑通一次完整注册和PDU会话常见做法是选Open5GS充当核心网UERANSIM模拟gNB和UE两者都支持Docker或裸机部署。先准备一台Ubuntu服务器装好Docker和docker-compose然后把核心网和模拟接入网拉下来。# 拉取开源核心网项目并以docker方式启动 git clone https://github.com/open5gs/open5gs cd open5gs/docker cp docker-compose.yml.example docker-compose.yml docker compose up -d docker compose ps这个步骤做完AMF、SMF、UPF、UDM、AUSF等网元容器会陆续起来。docker compose ps看到所有网元状态为Up后再继续其中任何一个起不来后面模拟基站一接入就会报NGAP建立失败。启动完成后先不要急着配UERANSIM去改核心网的配置把UE的IMSI、Ki和OPc对应上。# UERANSIM的gNB配置片段告诉模拟基站去找哪个AMF mcc: 001 mnc: 01 linkIp: 127.0.0.1 ngapIp: 127.0.0.1 gtpIp: 127.0.0.1 amf: - address: 127.0.0.1 port: 38412这段配置里mcc/mnc要和核心网一致ngapIp填写本机IP。38412是AMF默认的NGAP监听端口改了核心网端口就要同步改这里。接下来是UE配置模拟UE要在gNB搜索列表里找到模拟基站。# UERANSIM的UE配置片段决定鉴权能否通过的密钥参数 supi: imsi-001010000000001 mcc: 001 mnc: 01 key: 0C0A34601D4F07677303652C25325321 opc: 63BF0A30FF67F5655F85B0C5F2B3DF3E amf: 8000 gnbSearchList: - 127.0.0.1这里key和opc是USIM侧参数必须和核心网里预设的一致否则鉴权一定失败。amf是5G网络侧的AMF标识改成别的值不影响注册但会影响后续某些网元对UE上下文的识别。配置完成后先启动模拟gNB再启动模拟UE正常情况下能看到UE打印出注册成功和PDU会话建立成功的日志。4.3 Wireshark里看信令NGAP、NAS-5GS和HTTP/2的过滤技巧跑通之后关键的功夫在抓包分析上。抓包时可以在模拟gNB所在机器上执行下面的命令把NGAP和NAS消息一起抓下来。# 抓取38412端口的NGAP消息并显示过滤出NGAP和NAS层 sudo tshark -i any -f sctp port 38412 -Y ngap || nas_5gs \ -T fields -e frame.time -e ngap.ProcedureCode -e nas_5gs.message_type-f是抓包前的粗过滤只抓SCTP 38412端口避免无关流量刷屏-Y是显示过滤ngap || nas_5gs表示里层和外层同时显示。ngap.ProcedureCode能看到NGAP层在跑哪个过程比如InitialContextSetup是15nas_5gs.message_type能看到NAS层消息类型。如果看到两个过滤条件结果都对说明NGAP和NAS的嵌套关系已经被拆开。注意NAS消息在Security Mode Command之后变成密文nas_5gs.message_type还能解析出“这是某条消息”但里面的IE已经看不到明文。验证加密后的行为要看的是长度和完整性保护字段而不是具体IE内容。想要更深入理解NAS消息结构可以自己写一个极简解析脚本照着TS 24.501里5GMM消息头的定义去读消息类型。下面这个例子能解析未加密的注册请求# 最简5G NAS消息类型解析只读头部适合理解消息结构 def parse_nas_5gs(data: bytes) - str: # 5G NAS头EPD(1字节) SecurityHeaderType(1字节) MessageType(1字节) epd data[0] if epd 0x7e: # 5G Mobility Management msg_type data[2] names { 0x41: Registration Request, 0x42: Registration Accept, 0x44: Identity Request, 0x4e: Authentication Request, } return names.get(msg_type, fUnknown(0x{msg_type:02x})) return fNot 5GMM(0x{epd:02x})这段代码的核心是第一个字节0x7e表示这是一条5GMM消息第三个字节才是消息类型。0x41是注册请求0x42是注册接受0x44是身份请求0x4e是鉴权请求。实际抓包里如果消息被加密第三个字节还在但后面全是密文脚本只能帮你认消息名没法看IE。5. 信令学习高频翻车点与排查思路四条血泪经验这一章把学习过程中最常见的翻车场景整理成四条。每条都是真实工作里反复踩过的坑按“现象、原因、解决”写清楚。5.1 现象一只学成功流程现网日志里的cause一个都不认识很多学习材料只画理想成功路径注册请求发出一路绿灯注册接受回来。但现网拉日志时大概率看到的是Registration Reject或者Authentication Failure策略被拒、切片不允许、区域不允许根因都在cause值里。如果你只背过消息名而没背过cause日志摆在你面前也不知道该查哪个网元。原因在于学习时没有建立“失败分支”的知识结构。解决方法是给每个流程补一张cause表5GMM cause、NGAP cause、5GSM cause分开记。比如5GMM cause #3代表Illegal UE多半是IMSI被列入黑名单#7代表5G服务不允许可能是网络没有开放5G或切片被限制#29代表User authentication failed直接查USIM密钥和签约数据。NGAP cause则要分Radio Network Layer、Transport Layer和Protocol三类分别对应无线侧、传输链路和协议参数问题。学习时不能只看“这条消息是什么”还要问“这条消息为什么是这个结果”。5.2 现象二把NGAP和NAS混在一条时间线里时序全乱Wireshark里同一时刻会同时出现NGAP和NAS两层消息比如一条Initial Context Setup Request里可能既有NGAP过程信息又带着一条NAS消息。新手常犯的错是看到NGAP层有几条就以为是几个独立流程或者把NAS消息的时间当成NGAP时间。实际这两个层面存在“承载”关系NAS-PDU只是NGAP消息里的一个IE它的时间戳和NGAP消息时间戳一致。解决方法是分析前先分两个动作第一用ngap过滤看N2口过程第二用nas_5gs过滤看UE和AMF之间的对话。每次看时序嘴里默念一句这条消息是gNB和AMF之间的还是UE和AMF之间的想清楚这件事很多“为什么这条消息先到、那条后到”的问题就自动消失了。5.3 现象三看到“没回应”就以为卡死其实是定时器在起作用现网信令跟踪里经常出现一段间隔后重复发送的相同请求很多人第一反应是核心网卡死或基站丢包。其实5G的NAS层和NGAP层都有自己的定时器机制比如UE侧的T3510控制注册请求的重传超时没收到响应就重发一次T3512控制周期注册更新到了时间自动触发一次注册流程。日志上表现为同一条消息按固定间隔出现好几次这不一定是网络故障。原因是没有把定时器纳入流程认知模型。解决方法是背流程时连定时器一起背注册请求看T3510鉴权流程看T3560PDU会话建立看T3580。同时看UERANSIM这类模拟器的日志它会明确打印“Timer T3510 expiresretransmit”这是理解“没回应”到底是什么状态的最好教材。真正需要排查的反而是“定时器还没超时就收到了拒绝”那才是有条件的问题。5.4 现象四背了一堆消息名却说不清每个消息里哪个IE最关键消息名只是外壳排障时决定方向的是IE。比如Registration Request里5G-GUTI和SUCI决定AMF按什么路径处理身份识别Requested NSSAI决定切片选择结果。只看消息名不看IE遇到注册被拒就会抓瞎。典型场景是AMF回Registration Reject你翻遍消息名也看不出原因但展开IE发现Rejected NSSAI里的原因值写的是“切片在当前位置不可用”。解决方法是强制自己做笔记时按固定格式来格式放在下一章。要点是每个流程至少记“一个关键IE 一个失败cause”。关键IE选那个“变了就会导致流程走向不同的”字段失败cause选该流程最常踩的3个值。这样笔记量不大但每条都是排障时的索引。6. 把信令流程学成肌肉记忆一条主线、两种抓包、三遍过6.1 一张“五段式”信令笔记模板前面踩了那么多坑最后落地的习惯是学一个新流程只允许自己填一张表填完能不看材料默画出流程图才算真会。这张表只有五列列要填的内容举例注册流程流程名规范里的正式名称Registration procedure触发条件什么事件引起开机、跨TA、周期更新消息时序按方向写出完整消息链UE → gNB → AMF → AUSF → UDM关键IE流程分叉时决定方向的字段5G-GUTI、Requested NSSAI失败cause最可能出现的3个原因#3、#7、#29用这张表过一遍注册流程你会发现自己真正需要记的并没有想象中那么多。填不出来就回头看TS 24.501或抓包而不是回头再背一张巨型流程图。6.2 三遍过学习法与现网验证习惯学习任何一张新流程图我习惯用三遍过法。第一遍只求全貌用信令流程图倍速扫知道消息走向和涉及网元第二遍盯细节把Wireshark里同流程的抓包逐条对照图里的每条消息重点看IE和方向第三遍主动破坏改错OPc、改错切片、停掉UPF让流程走失败分支亲眼看到cause值怎么变化。三遍过完这个流程才算长在身上。拿一张真实失败日志做验证时我现在的习惯是先问三个问题这条拒绝的cause是哪一层的这条请求有没有对应的定时器重传成功路径如果走不通网络侧有没有给降级或回退这三个问题能过滤掉一多半的无效排查。希望这套思路对你也有用。本文还有配套的精品资源点击获取