简介《5G信令流程解析》是一份面向通信工程、网络运维及5G技术学习者的精简PDF文档系统梳理5G网络从接入到数据传输的完整信令链路。资源仅1个PDF文件压缩包大小105KB便于快速查阅与移动学习。文档从信令流程概述入手重点讲解设备接入流程中的身份验证、鉴权与RRC连接建立明确SRB1未启用加密保护等细节随后依次展开会话建立、核心网激活、PDU会话建立以及数据传输流程并涵盖QoS协商与流量控制机制。同时总结5G信令流程复杂性、高效性、安全性三大特点以及兼容性、资源管理、安全威胁等现实挑战帮助读者理解信令交互如何支撑5G高速度、低时延和大连接特性。目前该资源已有254人学习适合希望快速建立5G信令整体框架并对照实际流程入门的读者。1. 5G信令这套黑匣子先明白为什么信令流程值得逐条拆做过核心网或无线优化的人都知道用户投诉“能收到信号但注册不上”“切换后业务断流”最后能定位问题的几乎全是信令。5G信令流程不像4G那样单一接口走到底UE、基站、AMF、SMF、UPF五方交互NAS、RRC、NGAP、HTTP/2层层嵌套。这份《5G信令流程解析.pdf》正好把注册、PDU会话建立、N2切换这几条最常用的消息链按顺序拆开每一步谁发谁收、携带什么参数、失败后谁重传都给了对照。适合刚接触5G核心网的信令新人也适合做网优想往核心网靠的人作为工具书查。下面按我拆这套资料的实际顺序把协议栈、典型流程和排错经验一次说透。2. 控制面三层与网元交互NAS、RRC、NGAP到底谁在说话5G信令最容易把人劝退的点是同一段流程里消息会在三个层面平行出现。比如一个注册请求UE先把它封装成NAS消息塞进RRC基站再把整个RRC容器原封不动包进NGAP的InitialUEMessage里。如果只抓一层会误以为消息丢了或流程断了。先把这三层分清楚后面所有流程都能对号入座。2.1 三层信令的分工NAS靠RRC和NGAP“搭车”NAS运行在UE和AMF之间走N1接口负责注册、鉴权、PDU会话管理这类“跟基站无关”的业务逻辑。RRC运行在UE和gNB之间负责无线资源管理它本身不关心NAS内容只把它当作透传容器。NGAP运行在gNB和AMF之间走N2接口负责上下文管理、资源建立、切换信令它也能携带NAS消息。简单记NAS是业务RRC和NGAP是两条“搭车通道”。抓包时有个实用判断如果你在空口侧抓的是SIP或NGAP带外的信令看到的消息名字大多是NGAP开头在Uu口看RRC消息时重点找携带的dedicatedNAS-Message字段。Wireshark里可以直接右键解码NAS但前提是RRC或NGAP的SCTP流能正确合并否则你会看到一堆“malformed”且NAS内容出不完整。我一般会同时开三个过滤视图信令面sctp port 38412、SBI面HTTP/2、用户面GTP-U三个视图对照时间戳看。2.2 核心网网元间的交互N2、N4、N11三类接口消息除了空口链路5G核心网内部还有一组“服务化接口”最常见的三类是gNB和AMF之间的N2NGAP、SMF和UPF之间的N4PFCP、AMF和SMF之间的N11HTTP/2JSON。这套资料把N2和N4的交互画成了左右对照的时序图这点非常实用因为很多排障最终会落在“N2正常、N4失败”两边消息链要对齐才能定位。N11这类服务化接口不是二进制定长报文而是HTTP/2承载的JSON消息。用Wireshark或抓包工具看时要确保TLS解密配置正确否则只能看到加密的HTTP/2帧头看不到namf和nsmf服务方法。多数开源5G核心网默认不加密SBI但商用环境会开TLS实际排查时常要跟运维要一份SAN证书私钥才能解出内容。这不是协议问题是抓包配置问题别误判成“核心网没发消息”。2.3 先认熟这组接口与典型消息下面这张接口表是按“抓包时最常去看的层次”列的不只是协议参考更是排查路径参考。排障时先判断问题发生在接口哪一段再去过滤对应消息。接口承载协议典型端口你关心的典型消息N1UE-AMFNASRRC容器内无独立端口Registration Request、PDU Session Establishment RequestUuUE-gNBRRC无独立端口RRCSetupComplete、RRCReconfigurationN2gNB-AMFSCTP/NGAP38412InitialUEMessage、PDU Session Resource Setup Request/Response、Handover RequiredN3gNB-UPFUDP/GTP-U2152用户面数据包、G-PDUN4SMF-UPFPFCP8805PFCP Session Establishment Request/ResponseN11AMF-SMFHTTP/2 JSON通常8080或自定Namf_Communication、Nsmf_PDUSession_CreateSMContext用这张表对照抓包第一步永远是确认自己看对了接口。我见过不止一次有人在N11上等NGAP消息等半天最后发现端口过滤打错了。先定接口再谈解码这是信令分析的基本纪律。3. 注册流程逐级拆解从Registration Request到Accept的消息链5G注册流程是信令分析里最先要做熟的部分。用户插卡开机、从4G重选到5G、跨AMF移动都会触发注册而几乎一半的“上不了网”问题都能在注册链上找到原因。拆这套PDF时我把注册分成五段看发起、AMF选择、鉴权安全、注册接受、注册完成。每一段都有对应的关键消息和常见失败点。3.1 注册请求到达AMFRRC和NGAP里的双层封装UE发起注册时先构造NAS的Registration Request里面带注册类型initial、mobility、periodic、5G-GUTI或SUCI、UE能力、PDU会话状态等。这条NAS被封装进RRC的RRCSetupComplete通过Uu口送给gNB。gNB并不会解析NAS内容它只读RRC里的selectedPLMN-Identity和registeredAMF信息然后根据TATracking Area和切片配置选一个AMF把整个NAS容器包进NGAP的InitialUEMessage再通过SCTP偶联发给AMF。这里有个实际排查中很重要的点UE注册请求里带的是5G-GUTI还是SUCI会直接决定后续要不要走完整鉴权流程。如果UE能提供有效GUTIAMF会优先尝试从原AMF取上下文走的是轻量流程如果是SUCIAMF必须找AUSF做鉴权。你看到包里有大量的Authentication Request先别急着怀疑配错很可能是UE每次都用SUCI注册——这通常意味着上一个AMF的GUTI没被接受或UE侧没有保存GUTI。# 抓注册请求只看N2口与NAS相关消息 tshark -r 5g_trace.pcapng -Y sctp.port38412 (ngap.type 16 || ngap.type 9) -T fields \ -e frame.time_epoch -e ngap.type -e nas_5gs.mm.registrationType -e nas_5gs.mm.ngKsi参数说明ngap.type 16是InitialUEMessage9是UplinkNASTransportnas_5gs.mm.registrationType直接给出0-2对应的initial/mobility/periodic。如果这个字段一直为0说明UE每次都是全新注册网络侧GUTI机制没生效。这段命令适合在拿到pcap后第一条执行先看注册发起形态再决定要不要深挖鉴权。3.2 鉴权与安全模式不只盯着“通过不通过”AMF决定要鉴权后会通过NAS下发Authentication Request里面有RAND和AUTN。UE侧的USIM算出RES并回Authentication Response网络侧由AUSF/UDM校验。很多初学者只看“有没有通过”忽略了两条字段ngKSI和SNN。ngKSI是安全上下文标识符功能上类似4G的KSIASME是后续完整性保护算法的基础SNN是服务网名称如果PLMN或MNC配置不一致这里会出现“MAC mismatch”导致鉴权失败。鉴权完成后还有一条经常被跳过的Security Mode Command。这条消息不携带用户业务数据但它一旦失败后续所有NAS消息都会被UE丢弃表现就是“注册请求发了、鉴权通过了、但AMF收不到注册完成”。看这条消息时重点确认完整性算法和加密算法协商结果商用网通常选NIA2/NEA2如果两端支持的算法列表交集为空就会死循环发SMC。这个在我经手的项目里出现过一次原因是UE侧只支持NIA0而网络侧强制NIA2。3.3 注册接受与注册完成把状态机落到代码AMF通过鉴权后会下发Registration Accept携带分配的新5G-GUTI、TA list、网络切片信息、默认QoS参数。UE收到后再回一条Registration Complete到这里注册流程才算闭环。如果你的抓包里Accept之后没有Complete问题往往不在核心网而在空口——完整性保护失败后UE会静默丢弃AcceptAMF那侧还傻等。# 注册流程状态机伪代码用来核对重叠抓包中的关键状态 reg_state IDLE while reg_state ! REGISTERED: if recv(Registration Request, reg_typeinitial): reg_state AUTH_REQUIRED elif recv(Authentication Response): reg_state SECURITY_SETUP elif recv(Security Mode Complete): reg_state REG_ACCEPT_PENDING elif recv(Registration Accept): reg_state REGISTERED break if timer_expired(T3513): # UE侧注册请求重传 reg_state UE_RETRY逻辑说明这段伪代码把UE侧注册流程压缩成五个状态T3513是UE等待Registration Accept的定时器默认约15秒超时即重发注册请求。AMF侧对重合的初始注册不会视为异常但如果反复出现UE_RETRY要重点排查AMF到UDM之间耗时而不是盯着空口。参数上reg_type决定是否要GUTI重映射计划注册还涉及AMF间迁移两者重传行为不同。4. PDU会话建立与切换信令用户面落地前最常出事的交互点注册只是“入网”真正让用户能上网的是PDU会话建立。PDU会话牵扯UE、AMF、SMF、UPF、gNB五个角色而N2切换又会在会话建立后任意时刻打断重建。这两个流程是信令里交互方最多的部分也是这份PDF里最值得反复看的两章。我拆的时候把每条消息的“字面作用”和“底层作用”分开记字面作用是流程走到哪一步底层作用是它更新了谁的上下文。4.1 PDU会话建立NAS请求与NGAP资源准备的接力UE发起PDU Session Establishment Request经N1送到AMF。AMF根据请求里的DNN和S-NSSAI选一个SMF通过N11调用Nsmf_PDUSession_CreateSMContext。SMF拿到请求后先做会话策略和计费决策再选UPF通过N4发起PFCP Session Establishment Request为会话分配核心网侧TEID与QoS规则。UPF准备完成后SMF回N11响应AMF再通过NGAP向gNB下发PDU Session Resource Setup Request里面带着UPF的N3地址、TEID、QoS Profile。到这里有个容易看漏的步骤gNB收到NGAP请求后还要在无线侧建立DRB承载并在响应PDU Session Resource Setup Response里带上gNB侧的N3地址和TEID。AMF把这条信息转给SMF由SMF下发N4的修改请求UPF开始转发数据。核心网和无线侧的资源建立不是同步完成的中间隔着AMF的一次转发。检查NGAP的Request没有对应Response时优先看gNB侧是否因无线资源不足拒绝再查SMF到UPF的PFCP心跳是否正常。# 从pcap里提取N2/NGAP中PDU会话建立的关键字段 tshark -r 5g_trace.pcapng -Y ngap.procedureCode 8 -T fields \ -e frame.time_epoch -e ngap.pDUSessionID -e ngap.sNSSAI.sST \ -e nas_5gs.sm.dnn -e ngap.transportLayerAddress参数说明ngap.procedureCode 8对应PDU Session Resource Setup类流程pDUSessionID用于关联同一条会话在N2和NAS侧的消息多会话并发时用它做分组主键transportLayerAddress是UPF或gNB侧的N3地址也就是实际转发的GTP-U目的IP。如果这条命令跑出来只有Request没有Response再用GTP-U过滤看N3方向有没有User Plane报文。4.2 N2切换源侧、目标侧与UPF的三方交互N2切换发生在gNB之间触发方式通常是覆盖或负载。源gNB根据UE测量上报构造Handover Required发给AMF携带目标gNB的ID和QoS信息。AMF选好目标AMF后回Handover Request给目标gNB目标gNB准备资源返回Handover Request Acknowledge。AMF再让源gNB向UE下发Handover CommandUE切到目标小区后发起随机接入目标gNB发Handover Success通知核心网。之后还有一个不起眼但关键的GTP路径更新SMF修改UPF的F-TEID让用户面数据包通过目标gNB转发。排查切换失败时我建议先看Handover Required里的targetID选得对不对。如果Target gNB ID和实际发起接入的小区不一致目标侧会以“Unknown Target ID”拒绝这个在NGAP错误里用信令过程代码翻得非常隐蔽。还有一种常见情况切换请求成功但切换完成后业务仍中断这时候问题不在切换流程而在N4会话修改——SMF没通知UPF更新隧道数据还在往源gNB送。看N4的PFCP Session Modification Request是否匹配得上GTP-U切换时间点。4.3 最容易读错的一组参数S-NSSAI、QFI、TEID这条值得单独拎出来因为这三个字段在PDU会话和切换的报文里几乎每次都出现但含义完全不同。S-NSSAI是网络切片标识分SST和SD两段SST是切片类型SD只在需要细分时出现。QFI是QoS Flow标识用于关联某条数据流与5QI一个PDU会话里可以有多条QFI。TEID是隧道端点标识GTP-U隧道两端各有一个TEID。信令分析时用S-NSSAI确认UE选网是否正确用QFI确认QoS规则是否下发用TEID确认N3隧道是否完整。参数属于哪条链路出错时的典型表现S-NSSAISST比SD更重要N1/N2/N11切片切片替换错误注册接受但PDU建立被拒QFIN2/N4/QoS规则数据能跑但5QI对不上无法保障时延TEIDUE侧/gNB侧/UPF侧各一个N3/N4隧道建了一半GTP-U报文回溯方向错F-TEID含IPv4TEIDN4/PFCPPFCP心跳正常但用户面数据不转发判断隧道是否完整有个土办法在GTP-U报文的GTP头里找到TEID再去NGAP或PFCP消息里反查同一个值是否出现在对方的传输层信息里。普遍做法是先在N4的Establish Request里记下UPF分配的TEID再去N2的Setup Response里找gNB分配的另一个TEID两个都对上了再去看用户面。5. 信令解包避坑清单抓不到、解不开、连不上的五个常见现象这份PDF里有一章专门整理了排查案例我用自己实际跟过的几个故障把常见现象、原因和解决方法列出来。每一条都是“先看到什么表象再查到哪层根因”的记录你在复现流程时大概率会踩到其中一两条。5.1 现象抓包里有NAS却没有对应的NGAP请求抓sip或N1口能看到NAS的Registration Request但切到N2口过滤NGAP一无所获。最初我以为是gNB没转发后来发现是对端IP过滤写错了。N2的SCTP偶联地址是gNB管理面的IP不是空口侧的传输IP如果按传输IP去过滤NGAP永远不会出现。解决在抓包里先找SCTP端口38412的包用(sctp.srcport38412 || sctp.dstport38412)先定位偶联再反查IP地址。5.2 现象注册一直超时T3513反复开关UE侧每15秒重发一次Registration RequestAMF侧也能收到但就是没有Accep。打开NAS解码看发现重发的请求里GUTI一直相同而AMF始终没有往下推安全模式指令。逐条对齐后发现是AMF选了错的切片实例——UE在请求里带了S-NSSAI而AMF做订阅数据校验时取不到切片直接挂起。解决先检查UDM里该用户的签约切片是否包含请求的SST/SD再看AMF的NSSF选择策略返回的是不是空集。5.3 现象PDU会话建立失败NGAP请求发出后没有响应AMF明明向gNB发了PDU Session Resource Setup RequestgNB侧却不回。到gNB日志一看原因是QoS Profile里的5QI被判为不受支持。不同厂商gNB对5QI的默认支持表不一样规范里没有强制所有QCI都有默认承载属性。解决把QFI对应的5QI换成都支持的数值并确认ARP优先级在gNB侧允许范围内。这里是信令成功但底层拒绝的典型不看gNB日志只盯NGAP会浪费时间。5.4 现象HTTP/2消息乱序逻辑链对不上同一个PDU会话的消息在Wireshark里分散在不同位置时间戳也是乱的。这种问题多发生在多路径抓包时一条SBI调用走了两个连接或者TLS会话没正确拼接。解决给HTTP/2过滤条件加上http2.streamid做排序同时确认TLS密钥配置正确不能用现成导出文件直接按时间顺序读对话。命令上用tshark -Y http2 json.value contains \smContextRef\先把同一会话的引用号筛出来。5.5 现象5G-GUTI解算不出归属AMFUE带5G-GUTI做注册但AMF日志显示“GUTI not found”甚至走成了全量鉴权。看GUAMI结构发现AMF Set ID和Region ID对不上——UE在网络间漫游时GUTI里的AMF Set ID按归属网络编码现在AMF集内没有同步UE上下文。解决在AMF上配置跨集上下文查询并开启N14接口的UE上下文传输否则每次GUTI注册都会回落到SUCI鉴权导致注册时延拉长。6. 进阶把消息时间戳变成定位工具信令分析做到后面判断的不再是“有没有这条消息”而是“每条消息迟到多久”。我习惯给每段流程计算几个关键时间差用它们做第一轮定位。时间区间计算方式指向的问题RRCSetupComplete到InitialUEMessage空口到N2口的搬迁耗时gNB转发调度是否阻塞InitialUEMessage到Authentication RequestAMF决策UDM取鉴权向量耗时UDM链路时延、N12响应速度PDU Session Resource Setup Request到Response无线资源准备耗时gNB侧DRB建立、QoS接纳PFCP Establishment Request到ResponseSMF到UPF往返N4链路时延、UPF负载在Python里可以按pcap的frame.time_epoch直接做差再过滤掉多个UE的并发请求把同一会话消息ID作为聚合键超过100毫秒的区间标出来。时间差过大比消息缺失更早暴露链路隐患。后来我形成了个习惯每次出具信令分析报告都强制把关键消息的时间戳间隔列成表附在后面不再只贴“流程正常”的结论。这套方法帮我在好几个项目里提前发现了UPF负载过高和gNB转发阻塞的问题也希望帮到你。本文还有配套的精品资源点击获取