简介本资源为《5G信令流程解析》PDF文档聚焦5G网络中信令流程的完整运作机制适合通信工程师、网络运维人员及5G技术学习者阅读。文档从信令流程概述入手依次详解设备接入、会话建立、数据传输等核心环节并梳理RRC连接建立、PDU会话、QoS协商与流量控制等关键知识点同时客观分析了5G信令流程的复杂性、高效性、安全性特点及兼容性、资源管理、安全威胁等现实挑战有助于读者系统构建5G信令知识框架。资源包共1个文件为PDF格式压缩包大小约105KB内容精炼便于快速查阅。已有254人学习下载可作为5G网络原理学习、技术培训或日常排障的参考材料。1. 信令流程解析不会读等于黑匣子先找一个能复现的起点刚上手5G项目时大多数人是被一封带着attachment的《5g信令流程解析.pdf》拽进来的。第一反应往往是打开PDF、看流程图、背下来真正到了现场UE连不上网、注册被拒、PDU会话起不来对着信令看板一头雾水——那份PDF里的每个框都认识就是不知道哪一段出了错。原因很简单信令流程要落到抓包、落到消息字段、落到cause code上才有用。本文把注册、鉴权、PDU会话建立三条主流程拆开再从Wireshark/tshark的抓包视角逐层读最后给出高频故障的定位套路。写给做核心网测试、接入网协议开发以及网优的从业者目标是让读信令从背图变成排障手段顺便把那些信令看板上不会直接告诉你的坑一次排干净。2. 把5G信令流程的骨架立住从UE到核心网的五个动作和三条链路2.1 先立骨架5G协议栈里N1、N2、N3、N4各管哪一段5G信令流程的复杂度源于它把控制面和用户面拆得很开。控制面路径上是UE、gNB、AMF、SMF、UDM、AUSF这一串网元用户面则是UE、gNB、UPF三个节点。所谓信令流程绝大多数是控制面消息在N1、N2、N4三个接口上的流动外加NAS消息在空口的承载。可以先记一句话N1上跑的是UE与AMF之间的NAS消息N2上跑的是gNB与AMF之间的NGAP消息N4上跑的是SMF与UPF之间的PFCP消息N3是用户面。信令流程解析第一步是给每一条抓到的消息标好这是哪个接口的消息接口错了后面的字段解读全部没有意义。常见做法是先在脑海里把接口和协议栈对上NAS跑在N1承载它的底层是RRCNGAP跑在N2底层是SCTPPFCP跑在N4底层是UDP。实际抓包时Wireshark里ngap、nas-5gs、pfcp三个过滤器分别对应这三路。很多新手一上来就把所有包混在一个文件里然后问为什么看不到AMF发给SMF的消息——不是没抓到是N11接口上的HTTP/2消息与N1上的NAS消息根本不在同一个抓包点。所以做信令流程分析的第一步永远是明确抓包位置而不是打开Wireshark乱点。这份判断力比背一百页流程图都值钱。2.2 注册流程UE从我是谁到我能用哪些服务要走完的七个节点注册流程是5G信令流程最完整的一条链路值得优先把它读透。UE开机先发Registration Request这条NAS消息里如果带5G-GUTI就被AMF用来直接识别UE没有GUTI时带上SUCIAMF就需要和AUSF/UDM配合完成归属网络识别与鉴权。RRC层收到NAS消息后通过RRCSetupComplete把它透传给gNBgNB根据请求的NSSAI选一个AMF构造NGAP InitialUEMessage转发过去——这一步是接入网第一次和核心网对话抓包时能看到NGAP层包着一个NAS的payload。接下来的重头是鉴权与安全模式。AMF向AUSF发起鉴权请求AUSF走UDM取鉴权向量返回鉴权挑战AMF通过NGAP DownlinkNASTransport把NAS Authentication Request递给UE。UE算出RES*回Authentication ResponseAMF做一致性校验。校验通过后走到Security Mode Command/Complete空口开始加密和完整性保护这个动作在信令看板上就是安全模式已建立。需要注意Security Mode Command里带的完整性算法如果UE不支持UE会直接发起Security Mode Reject整个注册流程就会卡在鉴权和安全模式这一段。流程最后是核心网侧为UE准备注册态。AMF向UDM注册UE位置、取签约数据选好默认切片和默认DNN下发Registration Accept。Accept里最关键的是分配新的5G-GUTI和TAC listUE拿它做下一次注册的标识。如果注册被拒AMF会在NAS消息里带一个5GMM cause这个cause是排障的起点。整个过程对应信令流程解析文档里的编号列表可以对照着看自己在抓包里是否走完了全部七步注册请求、鉴权挑战、鉴权应答、安全模式、注册接受、注册完成、上下文释放。少任何一步后面都走不顺畅。2.3 PDU会话建立流程真正让UE能上网的一条独立链路注册流程解决的是UE被网络承认PDU会话建立解决的是UE有数据通路。两者最容易混淆的地方在于Registration Accept下来之后PDU会话建立请求并不会自动触发它由UE上层应用发起。UE在注册成功后收到URSP规则应用层根据规则决定是走eMBB切片还是其他切片然后构造PDU Session Establishment Request通过N1在NAS里带上DNN、S-NSSAI和请求的QoS参数。很多刚转5G的工程师会把注册成功当成联网成功看到终端没有数据流就一头扎进无线侧查覆盖实际信令里根本没有PDU会话建立请求问题出在应用层或URSP规则。AMF收到后要先做切片和DNN合法性校验再选SMF把上下文转给SMF。SMF与UPF之间建立N4会话分配隧道信息然后由AMF下发N2 PDU Session Resource Setup Request给gNB让gNB为这条会话建立空口数据无线承载。gNB回N2响应后AMF经N1把PDU Session Establishment Accept发给UE。这个Accept里带QoS Flow的映射规则核心网侧和空口侧是以QoS Flow标识对齐的。读PDU会话建立流程时重点看三处字段请求里的DNN和S-NSSAI、响应里的QoS Flow标识、以及N4接口上的PFCP规则。任何一个不匹配都会导致会话在半路被释放。很多能注册但无法上网的故障都是PDU会话建立流程里的某一步失败而不是注册流程有问题。2.4 服务请求与去注册把信令流程解析的视野补完整服务请求流程是UE从空闲态回到连接态的路它比注册流程短但抓包频率极高。UE在空闲态收到下行数据通知或需要发上行数据时发起Service RequestgNB帮它找到AMF随后网络侧重建UE上下文、恢复用户面承载。这个流程调优时会看延迟常见优化点是空口DRX周期和N2通知的触发时机。在信令看板上Service Request常常被误认为一次新的注册流程区分方法是看NAS消息类型Service Request的类型值和Registration Request完全不同。去注册流程则容易被忽略它由UE关机、注销或网络侧发起核心是AMF释放上下文并通知SMF拆除N4会话。如果在测试里看到UE反复注册又反复去注册先别急着怀疑核心网——去查UE的省电策略或测试脚本是不是把去注册写进了死循环。信令流程解析文档往往把注册画得很细对去注册只给一条线但现场排障时这两条线同样重要。把四条主流程都走一遍才算把这份PDF真正读全。我见过不少团队花了两周排查UE频繁掉线最后发现是测试终端的省电策略在空闲态主动触发去注册和网络侧一点关系都没有。3. 从抓包到读包用Wireshark和tshark把注册流程还原成字段明细3.1 抓包位置与过滤器先决定观察点再决定命令信令流程解析最常见的落地动作是抓包。抓包位置决定你能看到哪一段在UE与gNB之间抓的是空口RRC/NAS在gNB与核心网之间抓的是NGAP与SCTP在SMF与UPF之间抓的是PFCP。做整链路分析时大多数人采用gNB与核心网之间加镜像端口的方式因为这里同时能看到NGAP承载的NAS消息和N2用户面建立消息信息最全。空口抓包需要特殊设备或测试终端的信令日志成本高通常在定位空口调度时才做。记住这个选择逻辑先问自己这次要排的是注册问题、会话问题还是用户面问题再决定抓包点。打开抓包文件后先按协议过滤。一个中庸的显示过滤器是好入门的起点ngap || nas-5gs || pfcp这个过滤器把三条最核心的控制面协议都放出来。NGAP在SCTP之上packet list里看到SCTP后跟着NGAP字样就是N2接口消息NAS 5GS是承载在RRC或NGAP里的那层协议它的payload里有Registration Request、Authentication Response这些你看得懂的字段名PFCP是N4接口的协议端口通常是8805。如果要快速统计会话里有哪些信令消息用tshark比逐个点开快得多tshark -r reg.pcap -Y ngap || nas-5gs || pfcp -T fields -e frame.number -e frame.time_relative -e _ws.col.Info这里的-r指定读入文件-Y是显示过滤器-T fields把输出切换成字段列表-e后面跟要打印的字段。frame.number是包序号frame.time_relative是相对时间秒_ws.col.Info是消息摘要。输出会是一行一条适合先把整条注册流程的事件序列拉出来。确认事件序列正常后再用Wireshark图形界面点进具体包看字段树。参数上有一点要注意相对时间默认从抓包文件第一包算起如果信令看板的时间戳对不上改成frame.time或frame.time_delta才能和外部日志对齐。我在现场吃过这个亏拿相对时间和核心网日志对了半天最后发现是时间基准没设对。3.2 读一个注册流程的正确顺序先看NAS再看NGAP最后往回翻鉴权很多人读信令包是从第一个包开始翻翻到一半就迷失。我一般按三段读先找NAS层的Registration Request再找AMF回的Registration Accept最后倒回去看中间的鉴权和安全模式。先找起点和终点比顺序读更容易建立流程框架。这就像拿到一份流程图先看两个端点的框中间的分支逐个展开不容易被细节带偏。用过滤器单独抓NAS层能快速定位起点tshark -r reg.pcap -Y nas-5gs -T fields -e frame.number -e nas_5gs.nas_msg_typenas_5gs.nas_msg_type是消息类型字段取值会在显示摘要里给出比如0x41对应Registration request0x42对应Registration accept。先把这个字段对应的包号找出来起点和终点自然浮现。随后针对起点包展开看NAS层里的5GS registration request这里能读到UE给的5G-GUTI还是SUCI、UE的安全能力、请求NSSAI。再看终点包的Registration Accept重点读分配下来的5G-GUTI和允许的NSSAI列表。起点和终点确认后中间那段鉴权只需要验证挑战-应答-安全模式三步是否完整不需要每个字段都啃。这里有一个判断技巧如果NAS消息在NGAP包里以透传形式存在Wireshark会在NGAP层里嵌一个NAS-PDU字段。那么通读流程时你要区分这条NGAP消息自己带了什么和这条NGAP消息透传了UE什么NAS消息。NGAP InitialUEMessage里既有gNB侧的UE上下文信息也透传了RRC传来的NAS Registration Request。在信令流程解析文档里这两部分是并列的流程节点但在抓包里是同一包的两层。读包时先展开NGAP层看gNB提供的PLMN、TAC、Cell ID再展开NAS-PDU看UE的请求内容才能做到字段级定位。很多现场拍脑袋猜AMF选错了的结论其实在NGAP的PLMN字段就已经露出端倪。3.3 三个字段级验证秒数、cause、QoS Flow抓包分析大概率会在三个点上卡住时间对不上、cause code看不懂、QoS参数没对齐。时间问题用tshark解决忽略协议细节只提时间tshark -r reg.pcap -Y nas-5gs.msg_type 0x42 -T fields -e frame.time_relative0x42是Registration Accept的类型值这样能精确拿到Accept出现的时间。如果终端日志里显示收到Accept的时间和抓包时间差了几百毫秒通常是终端日志用本地时间、抓包用UTC时间把时区对齐再看。cause code和QoS参数的问题留到下一章展开这里先记住一个原则凡是信令流程解析文档里没有明说的地方都以抓包里的实际字段为准不要用经验补位。比如文档画了PDU会话建立时QoS规则下发但没有告诉你规则在下发前可能被网络侧改写这种边界只能靠抓包验证。3.4 从简到繁的读包顺序一种适合新手入门的观察方法如果觉得整条注册流程消息太多可以从简到繁分三层观察。第一层只看NAS层的消息类型序列确认注册请求、鉴权、安全模式、注册接受这个骨架在不在。第二层只看NGAP层的消息类型比如InitialUEMessage、DownlinkNASTransport、UplinkNASTransport、UEContextReleaseRequest确认核心网与gNB的交互节奏。第三层才去对照协议文档查字段比如Security Mode Command里选的完整性算法是哪一种PDU会话建立请求里请求的DNN是什么。这三层观察法对应了信令流程解析文档里三种粒度的流程图高层流程、网络交互流程、字段级流程。我多次在排障中靠第二层发现问题——比如UE回了一包UplinkNASTransport但AMF没继续发Downlink消息大概率是AMF侧卡在鉴权或签约数据同步上干脆放弃逐字段查NAS先去查核心网日志。信令流程解析的价值不是让你每个字节都读而是先建立消息到了哪一步的坐标再决定深挖哪一层。新手容易掉进另一个坑花半小时研究一个不重要的保留字段却忽略了对整条流程走向的把握。把三层观察法用熟读包效率会明显提升。4. 把关键信令IE吃透SUCI、5G-GUTI、QoS Flow与cause code4.1 SUCI与5G-GUTIUE第一次进网和后续进网的两套身份注册流程里有两类身份标识是最容易被忽略又最容易出错的SUCI和5G-GUTI。SUCI是加密后的用户标识在首次注册或GUTI失效时出现。它的结构是SUPI类型、归属网络标识、路由标识、加密的MSIN以及保护方案标识。看到SUCI时不要试图直接从里面读IMSI它是用公钥加密的归属网络的UDM/AUSF才能解出真实身份。排障时如果试图从抓包里看到手机号方向就错了。现场有一种常见误判测试终端没有插卡或卡数据不完整发出来的SUCI里归属网络标识是乱填的AMF查不到归属网络注册被拒问题根源却在SIM卡数据上。5G-GUTI是网络分配的一次性临时标识它的价值是让下行寻呼和上行注册请求具备可路由性。Registration Accept里会分配一个新的5G-GUTIUE在后续注册会优先带GUTI。判断注册请求里带的是GUTI还是SUCI看NAS层里5GS registration request的mobile identity字段取值为GUTI或者SUCI。出现一种典型故障UE多次注册都带SUCI而不是GUTI说明UE始终没有在Accept里成功保存新的GUTI常见诱因是空口解密后Registration Accept的完整性校验失败UE把Accept丢弃了。抓包看N1消息不能只看有没有Accept还要看UE是否发了Registration Complete没发就说明依旧没有接受临时标识。4.2 S-NSSAI、DNN与QoS FlowPDU会话建立请求里的三个必读字段PDU会话建立请求比注册请求简单但三个字段决定成败S-NSSAI表示要走的网络切片DNN表示要连的数据网络QoS Flow则描述了这条会话的服务质量维度。很多核心网割接后的故障都是签约数据里没有包含某个S-NSSAI或DNN大小写与签约不一致导致PDU会话建立请求走到SMF后被拒。读这类包时先展开NAS层里的PDU session establishment request查看请求类型是initial request还是existing PDU session再看S-NSSAI里的SST和SD值最后看DNN。将这三个值与UDM签约数据对照一次排查就能定位是切片没签还是DNN拼错。QoS Flow的映射在PDU session establishment accept里下发给UEUE按这个映射把上行数据包打上QoS Flow ID标签。如果下行数据不通但信令流程走完了一个可疑点是gNB生成的DRB映射与核心网下发到UPF的QoS规则不一致这种问题在信令抓包里不会直接报错要靠对比N2和N3两边的QoS参数才能发现。所以读包时别只盯着NAS层N2消息里同样有QoS Flow Level参数要把N1和N2两边的QoS字段放在一起比对才有意义。这个习惯能帮你少走很多弯路。4.3 cause code不是黑匣子一张表把注册拒绝和PDU会话失败拆开信令流程解析的PDF里通常会附cause code清单但现场用的时候很多人只记得code 3是非法UE就以为万事大吉。事实上5GMM cause和5GSM cause分属NAS的两个子层5GMM cause用于注册、服务请求、去注册流程5GSM cause用于PDU会话流程。先分清是哪一层报出来的再查具体数值。注册拒绝里最常见的几个5GMM cause和PDU会话失败对应的5GSM cause可以先用一张表压住NAS层cause值含义常见触发位置5GMM#3Illegal UE非法UE归属网络永久拒绝该用户5GMM#6Illegal ME非法终端终端IMEI被禁止入网5GMM#75G服务不允许用户未签约5G或PLMN限制5GMM#11PLMN不允许PLMN选择或漫游配置问题5GMM#12Tracking area不允许TAC不在允许的TA list5GMM#22拥塞网络过载导致的临时拒绝5GSM#26资源不足PDU会话建立时资源分配失败5GSM#32PDU会话类型无效请求IPv6但策略只允许IPv45GSM#39DNN未签约或不支持SMF查询签约失败5GSM#42S-NSSAI不可用切片未签约或未配置排查时不要只记数字还要记住cause的出现位置。同一个cause在Authentication Reject和Registration Reject里含义不同判断归属先看NAS消息类型再看携带cause的那个IE。Wireshark的Info列会直接显示消息类型和cause数值比如Nas message: Registration reject (0x44) with 5GMM cause #7拿到这句话对照协议文档的cause表就能往下追。核心网的日志里通常写了具体拒绝原因例如no subscription data或slice not supported用信令cause反向查日志往往几分钟就能定位。最怕的是只看cause不管上下文把#7一律当成签约问题结果查了半天签约数据没问题实际是PLMN限制。4.4 从字段到实际故障三个可落地的验证技巧把IE读透之后要形成三个验证习惯。一是每次拿到注册被拒的包先在NAS层抽cause值再到核心网日志按时间戳搜同一条消息确认cause源头是UDM签约检查还是AMF本地策略。二是每次做PDU会话流程验证把请求里的S-NSSAI、DNN和签约数据导成一张对照表避免凭记忆判断。三是把GUTI分配当作注册流程完整性的验证点——一个没收到Registration Complete的流程即使Accept见过了也不能算注册成功。这三个习惯能覆盖大多数信令流程解析文档没写透的边界场景也是我每次给新人培训时反复强调的底线。5. 5G信令流程避坑指南注册被拒、PDU会话失败、抓不到包的五个典型坑5.1 抓包看得到RRC却看不到NAS明文现象空口信令日志里RRCSetupComplete正常继续展开NAS-PDU时里面是null或乱码找不到Registration Request的明文。原因空口在安全模式建立前是明文建立后NAS消息被加密做透传。如果在Security Mode Command之后还想读NAS明文抓包工具没有对应密钥就只能在抓包配置里放弃空口、改从N2接口抓。解决把抓包点从空口改到gNB与核心网之间的镜像口或使用测试终端的完整信令日志。这个现象不是核心网故障往往只是抓包点选错别在空口上加半天解密配置方向不对。5.2 所有注册都带SUCIGUTI分配没见过现象终端每次注册都发SUCIRegistration Accept也下发成功但后面的流程里仍重复走全量鉴权效率极低。原因UE没成功保存新的5G-GUTI常见诱因是接收到Accept后完整性校验失败UE等于把Accept丢弃。解决抓包里在Accept之后找Registration Complete。没有这条消息就说明终端侧没有接受网络侧分配的标识优先排查AMF安全模式是否成功完成以及空口加密算法是否被gNB正确透传。很多情况下问题不在核心网而在终端与gNB之间的安全上下文同步先看安全模式那一段。5.3 注册成功但PDU会话建立请求迟迟不触发现象注册流程全走完UE状态是已注册但等了几秒甚至十几秒抓包里始终没有PDU Session Establishment Request。原因PDU会话不是注册流程的必然结果UE上层应用没有发起联网请求或URSP规则里没有匹配的应用流量触发会话建立。解决先在UE侧确认是否有应用在请求数据业务再检查URSP规则里的匹配条件和默认DNN是否正确下发给UE。在核心网测试里用一台固定IP终端做Ping或HTTP请求能强制触发PDU会话建立这也是信令测试环境里的常规做法。5.4 Registration Reject带cause #7但签约数据明明有5G现象UE被拒绝NAS层看到5GMM cause #7核心网日志却说这个用户的签约里有5G服务。原因#7在不同厂商的设备上有歧义有些实现把它当作用户可用的服务不在当前PLMN限制内常见于PLMN问题或漫游配置异常而不是单纯的签约缺失。解决不要只看cause把UE当前注册的PLMN、请求的NSSAI和用户签约的三元组放在一起看。如果怀疑原因被厂商日志掩盖用另一个已知正常的SIM卡在同一位置注册对比结果能帮助判断是用户级还是网络级问题。这个case我至少遇到三次每次都是被厂商实现差异坑了一把。5.5 时延统计把重传包当有效流程包现象整条注册流程的时延统计显示注册请求到注册接受之间耗时3秒但终端日志显示实际耗时只有200毫秒。原因抓包里存在大量TCP或SCTP重传重传包被时延统计当成新信令包导致时间的起点对齐错误。解决在tshark统计前过滤掉重传包用tcp.analysis.retransmission 0或SCTP的重传标志过滤后再计算时延。另外要把时延计算的起点定为NAS层请求包的到达时刻而不是第一个SCTP分片包的到达时刻。这个坑在跨地域远程抓包时尤其常见网络抖动会把一堆重传包混进来不提前过滤统计结果毫无参考价值。6. 用小型核心网加模拟终端复现端到端信令流程一个可留作模板的验证套路6.1 没有真实基站也能拉一条完整注册信令接触不到商用5G基站时用开源核心网加模拟UE是常见做法。典型的组合是Open5GS配合UERANSIM这样的模拟终端程序在一台Linux主机上拉出注册、PDU会话建立、服务请求的完整信令流程抓包点直接选在模拟核心网的N2接口能看到完整的NGAP与NAS消息交互。搭建时要注意接口地址和切片参数的一致性否则模拟UE会卡在初始注册阶段。这类环境虽然不能完全替代真实空口但用来验证信令流程的完整性和配置正确性足够了。6.2 用tshark导出流程概览替代手工点包把模拟环境跑的注册流程抓下来后用一条命令就能得到完整的事件序列tshark -r 5g_reg.pcap -Y nas-5gs -T fields -e frame.number -e frame.time_relative -e nas_5gs.nas_msg_type -e _ws.col.Info查看输出时留意消息类型的顺序Registration request、Authentication request、Authentication response、Security mode command、Security mode complete、Registration accept、Registration complete。如果中间某条消息缺失对比本文第2章的七步流程能快速定位是模拟UE配置还是核心网切片配置的问题。这个导出命令本身就是后续做回归验证的模板比每次打开Wireshark手工点包可靠得多。6.3 把时延和cause code一起纳入回归清单我在做信令流程验证时有个习惯每次改完核心网配置不只看流程能否走通还固定记录两样东西——Registration Accept相对注册请求的时延以及PDU会话建立Accept的时延。时延突然变大往往意味着鉴权过程发生了重试或者切片选择走了一次兜底路径。这个习惯后来帮我挡下了好几次配置回退也让我意识到信令流程解析这份功夫最终要靠模板化的验证来沉淀。希望这套先看骨架、再看抓包、最后查cause的方法能帮到你真正用顺手了信令看板就不再是黑匣子而是一个到处都能下手的调试工具。本文还有配套的精品资源点击获取