简介PPT 系统讲解 5G 基础信令体系适合通信工程师、网络优化人员及 5G 入门学习者快速建立知识框架。内容从 5G 相比 4G 的新特性切入覆盖控制面 UE 状态机、RRC 连接建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理与 EN-DC 双连接用户面则讲解新 QoS 机制、PDCP split 与 duplication、精简 RLC以及 SRB0/1/2/3 承载映射关系。同时还梳理了 5G 架构、空口协议和 LTE/NR 协议规范差异并总结了 Inactive 状态、On-demand SI、SUL、BWP、RNAU、Flow vs Bearer 等关键概念。资源为 1 个 pptx 文件压缩包 3.65MB目录层次清楚适合按章节快速查阅。目前已有 400 人学习。借助这份材料读者可以从信令整体到细节建立完整脉络为后续协议流程分析、信令排查和网优工作打下基础。1. 为什么先啃透5G基础信令一个“信号满格却上不了网”的现实场景插上5G卡手机显示满格可视频一直在转圈。网优拿着终端日志跑了一下午基站侧收到一堆RRC Setup Request核心网却迟迟看不到REGISTRATION REQUEST。问题出在哪不是覆盖不是频段是信令在某个节点上被丢弃或拒绝。5G基础信令正是把这类问题从“玄学”变成“可排查项”的那张地图——它不教你宏站怎么立、天线怎么调而是告诉你消息从手机到基站再到核心网每一步叫什么、长什么样、失败时回什么码。这篇笔记适合刚转5G的网优、开站调测的工程师、以及做协议栈或核心网测试的研发目标是让你拿到一份PPT题目也能建起整条信令面认知并在真实日志里找到定位路径。5G信令体系比4G多了一整层服务化架构接口从个位数胀到十几个但基础消息骨架仍然是UE发出请求gNB透传或映射AMF做移动性管理SMF做会话管理。所谓“基础”指的就是NAS、RRC、NGAP这三层消息以及注册、服务请求、PDU会话建立这三条主流程。先把这三层消息读熟再去碰切换、双连接、VoNR等进阶场景效率会高得多。2. 信令在哪些接口上跑网元、接口与协议栈速览2.1 先别急着背协议号把网元和接口画成一张图5G核心网和4G最大的区别是控制面引入了服务化架构网元之间从“点对点硬连接”变成了“注册到NRF按服务互相调用”。但对外和基站相关的接口仍然是点对点的理解基础信令只用盯住这个最小的环UE 通过空口 Uu 口连接 gNBgNB 通过 N2 口连接 AMF通过 N3 口连接 UPFAMF 又通过 N11 口找到 SMFSMF 通过 N4 口控制 UPF。这里最容易绕晕的地方是把 N2 和 N3 混着看。N2 承载的是控制面 NGAP 消息N3 承载的是用户面 GTP-U 隧道两者虽然都从 gNB 出发但终点完全不同N2 到 AMFN3 到 UPF。抓包时如果看到 GTP-U 的包那是用户面数据不是信令别在信令流程里去找它。网元清单不需要多基础信令只涉及四类角色UE、gNB、AMF、SMF/UPF。UPF 严格说属于用户面但 PDU 会话建立流程里有它一环所以也要知道它在这个流程里做什么——SMF 通过 N4 会话建立请求把包转发规则下发给它它不参与 NAS 消息。2.2 控制面和用户面分离信令只在控制面上跑5G 从架构上强制分离控制面和用户面。UE 发起的每条业务请求先走控制面完成认证、授权、会话建立随后用户面数据才通过 UPF 转发。这个设计带来的实际影响是信令排查只需要盯控制面消息用户面丢包、时延、乱序问题则要看 GTP-U 和 RTP/业务流两类问题用完全不同的日志工具。很多新手把“上不了网”一刀切归到信令问题结果在空口质量上排查了半天实际是 UPF 的转发规则没下发。控制面消息的路径是这样的UE 产生 NAS 消息封装在 RRC 消息里发给 gNBgNB 解出 RRC把 NAS 部分原封不动封装进 NGAP 消息发给 AMFAMF 处理 NAS再通过服务化接口调用 SMF。这条“原封不动透传”的规则很关键意味着 NAS 消息在 gNB 看来就是一个不透明容器。排查时可以在 gNB 日志、N2 抓包里看到完全相同的 NAS 十六进制一旦某一段对不上问题基本出在透传网关或封装格式上。2.3 协议栈分层NAS、RRC、NGAP各管什么现在把协议栈从下往上捋。空口侧PHY、MAC、RLC、PDCP、RRC。其中 RRC 负责连接管理、测量配置、安全激活承载的是一条条具体的“控制信令”PDCP 负责加密和完整性保护所以空口抓到 RRC 消息往往是密文解密需要拿到 gNB 侧的密钥材料。往核心网方向看N2 接口跑的是 NGAP传输层用 SCTP应用层还叠了一层 HTTP/2 和 JSON5G 核心网的服务化接口N1、N2 之外的 Namf、Nsmf 等也跑 HTTP/2。这意味着抓 NGAP 包时Wireshark 会先解析 SCTP 流再解析 NGAP 协议。如果 SCTP 流乱序或重组不了后面全是乱码那不是协议问题是抓包方式问题。NAS 层分两部分MM 子层管移动性即注册、去注册、服务请求、鉴权SM 子层管会话即 PDU 会话建立修改释放。RRC 和 NAS 的关系是NAS 是“业务逻辑”RRC 是“运输通道”。业务逻辑只关心我要注册、我要鉴权不关心空口质量好不好RRC 只关心连接能不能建起来、消息能不能可靠送到。2.4 一个注册流程在协议栈上的穿行顺序把理论落到实例注册流程是所有流程的地基。UE 开机后先做小区搜索和随机接入收到 RRC Setup 完成消息后在 RRCSetupComplete 里带上第一条 NAS 消息 REGISTRATION REQUEST。gNB 收到后向 AMF 发起 NGAP Initial UE Message把 NAS 塞进这个容器。AMF 收到后回 NGAP Initial Context Setup Request 或 Downlink NAS Transport把 REGISTRATION ACCEPT 装回去。这里有个重要的时间点安全激活发生在注册过程中间不是流程一开始。AMF 决定启用安全后会通过 gNB 下发 Security Mode CommandUE 回 Security Mode Complete之后空口消息才加密。所以在 RRCSetupComplete 阶段看到的 RRC 信令是明文注册请求也是明文再往后的 NAS 消息就要解密或者用核心网内部日志看了。这也是“基础信令讲解”里最常被忽略的一点。3. NAS信令的读写注册流程与鉴权参数怎么解3.1 REGISTRATION REQUEST里几个必须认识的IE拿到一条 REGISTRATION REQUEST先看它的几个关键信元而不是从头读到尾。第一个是 5G-GUTI 或 SUCI。UE 如果有上次注册的临时标识就用 5G-GUTI核心网可以根据它反查原来的 AMF减少重新鉴权。没有 GUTI 时用 SUCI也就是加密后的 SUPIAMF 需要把它转发给 AUSF 做解密和鉴权。第二个是 requested NSSAI即 UE 想注册的网络切片列表。这里注意NSSAI 的格式是 SSTSDSST 占 8 比特SD 占 24 比特。如果 UE 带了一个不存在的切片标识AMF 会回 registration reject with cause “slice not supported”这是 5G 时代新增且高频出现的失败原因。第三个是 5GMM capability 和 requested capabilities。UE 在这个 IE 里声明支持什么是否支持请求型 PDU 会话、是否支持 N1 模式、是否支持 MICO 模式。如果 UE 漏声明了某个能力核心网就不会给它下发相应特性。常见迷惑场景终端明明支持 VoNR注册消息里却没带 IMS voice over PS session supported导致核心网不给他做 IMS 域VoNR 完全起不来。3.2 用十六进制快速定位NAS消息类型NAS 消息是二进制编码开头几个字节有固定格式。Extended Protocol Discriminator 占第一个字节的高半字节5G 移动性管理消息是 0x7E5G 会话管理消息是 0x2E。第二个字节的比特 3 到比特 1 是 Security Header Type紧跟着的 Message Type 在第三个字节。用这个办法在日志里搜 7e 或 2e就能快速区分 MM 和 SM 消息族再对照消息类型表找到具体消息名。举例一条注册请求消息的前几个字节通常是7e 00 41 ...。0x41 是 REGISTRATION REQUEST 的消息类型码。而 PDU Session Establishment Request 是2e 01 c1 ...0xc1 是它的消息类型码。拿到这些特征码之后在基站日志或核心网日志里做字符串搜索比翻完整条消息快得多。提示别把 0x7e 和 0x2e 当成普适规则。它们只适用于 5G NAS 消息的协议鉴别符。4G 的 EMM 是 0x7e、ESM 是 0x2e部分场景一样但使用时要确认当前消息来自哪个制式别在 4G 日志里用 5G 规则去套。3.3 鉴权流程Authentication Request和Response的关键参数注册流程中必不可少的一步是鉴权。AMF 向 UE 下发 Authentication Request里面核心参数是 AUTN 和 RAND。AUTN 由 SQN、AMF、MAC 组成UE 端用共享密钥 K 和 RAND 计算期望的 MAC 和 SQN 做校验。如果 UE 认为 SQN 不同步超出范围它会回 Authentication Failure with cause “synch failure”并带上 AUTS 参数。AUSF 收到后可以据此重同步 SQN再发一次鉴权请求。这个场景在真实网络里很常见尤其是异地换卡、老卡新终端、HLR/HSS 数据不一致的时候。排查方法不是让用户换卡而是看核心网用户数据里的 SQN 和终端侧的 SQN 差多少。若相差过大重置签约数据里的 SQN 参数即可不需要重新写卡。很多工程项目把这个问题做成“换卡重发”实际是浪费了资源。鉴权成功后 AMF 发起 Security Mode CommandUE 回 Security Mode Complete。之后 NAS 消息带上了完整性保护和加密。注意Security Mode Complete 本身是明文还是密文不同厂家实现有差异。一般完整性保护已经打开所以内容未必可读这属于正常现象。3.4 服务请求流程与注册流程的区别注册流程解决的是“你是谁”的问题服务请求流程解决的是“你要传数据了”的问题。UE 在空闲态需要发数据或收数据时发起 Service Request核心网收到后通过 NGAP Initial Context Setup Request 让 gNB 为 UE 建立用户面资源。这个流程里常见问题UE 带了 uplink data status 字段说明有数据要发AMF 根据这个字段决定要不要激活用户面连接。如果 UE 没带这个字段AMF 可能不建立用户面导致应用层连接的 TCP 握手能完成但数据传输一直卡住。排查这类问题不要只盯 NAS要看 N2 上的 NGAP 消息里有没有建立 PDU Session Resource以及 N3 隧道有没有在 UPF 侧真正下发。4. RRC与NGAP接入和移动性里最容易翻车的信令点4.1 RRC Setup、重配里的关键IERRC 层基础消息里RRCSetup 是最常用的。gNB 发 RRCSetup 给 UE里面带 masterCellGroup 配置也就是 RLC 信道、MAC 配置、物理层配置、以及 SRB1 的配置。RRCSetupComplete 则是 UE 回给 gNB 的里面封装了 NAS 消息。RRCReconfiguration 是 RRC 层的重头戏它承载着切换命令、测量配置、DRB 建立等。RRCReconfigurationComplete 是 UE 回执如果不回gNB 会重发或者判定无线链路失败。排 RRC 问题时最重要的不是逐条读 IE而是先看 failure cause——消息里有 cause 字段可能是 radioNetwork、transport、protocol 三类。radioNetwork 里的 cause 值从 0 到 40 多每个编号查表即可不用背但其中 high 频的三个要熟radioNetwork: userInactivity、radioNetwork: radioConnectionWithUeLost、radioNetwork: unknownMibOrSib。4.2 RRC 消息的加密边界再强调一次RRC 消息不是全程明文。SRB1 在安全激活前是明文安全激活后加密SRB2 和 DRB 建立后全部加密。因此抓空口日志时能看到 RRCSetup、RRCSetupComplete 是明文RRCReconfiguration 也经常能看到但里面的关键配置已经被 cipher 了看到的是密文块。真正需要解 RRC 密文场景一般是切换失败分析或者 VoNR 语音质量问题需要拿到 gNB 侧的 PDCP 密钥或测试终端日志。普通工程排查不需要这一层看 RRC 建立流程本身已经足够定位 90% 的空口问题比如随机接入失败、资源不足、终端拒绝重配。不要为了看一个字段把终端日志的密钥体系全开投入产出比太低。4.3 NGAP 的初始上下文与 PDU 会话资源建立NGAP 作为 N2 接口信令核心消息有三条要熟Initial UE Message、Initial Context Setup Request、PDU Session Resource Setup Request。前两条对应 UE 接入和上下文建立第三条对应 PDU 会话建立。Initial UE Message 是 gNB 到 AMF 的第一条消息NAS 就存在它的NAS-PDUIE 里。这条消息同时还带 RAN UE ID、以及用户位置信息等。AMF 通过它获知 UE 要注册还是发数据再决定后续响应。Initial Context Setup Request 是 AMF 到 gNB 的消息里面带 Security Key、以及要让 gNB 建立的 PDU Session Resource 列表。gNB 收到后把这些信息映射成 RRC 连接重配UE 完成后回 RRC 重配完成gNB 再回 NGAP Initial Context Setup Response。整条链路如果哪一步断了对照这个消息和对应响应的 IE 缺失项就能定位。PDU Session Resource Setup Request 更细它里面有 PDU Session ID、S-NSSAI、QoS Flow 列表、以及 N3 隧道信息也就是 UPF 的 TEID 和地址。gNB 收到后本地为用户面建立 GTP-U 隧道并分配自己的 TEID然后把这个 TEID 回给 AMF最终一路传回 SMF。这一步是数据通路能否建立的关键。如果回包里的 TEID 是空的或者 UPF 侧收不到 gNB 的 GTP-U 包那问题通常出在 SMF 下发的转发规则或 UPF 路由上。4.4 NGAP 接口 ID 管理最容易让人懵的两个 IDNGAP 消息里有两套 UE 标识AMF UE NGAP ID 和 RAN UE NGAP ID。前者是 AMF 分配的后者是 gNB 分配的。两个 ID 在 Initial UE Message 建立关联后后续所有消息都靠它们来唯一标识这个 UE。排错时最烦的现象是日志里两条消息的 UE ID 对不上比如 gNB 日志写 RAN UE NGAP ID 12345AMF 日志写 AMF UE NGAP ID 67890。这不是错误是正常现象两者本来就是不同的值。容易踩坑的是在关联还未建立时某些消息只有 RAN UE NGAP ID某些只有 AMF UE NGAP ID这时候要把它们配合 Initial UE Message 里的关联关系做映射不能直接把 ID 当作对应标识来搜索。5. 避坑指南信令排查里常见的5个翻车现场5.1 现象一日志里全是NAS重传但空口质量正常排查注册慢或呼叫建立慢的问题时经常看到 UE 反复发 REGISTRATION REQUESTgNB 日志显示 RRC 一切正常重传的是 NAS 层。原因是 NAS 重传定时器 T3510 超时UE 没等到 REGISTRATION ACCEPT。排查顺序先看 AMF 有没有收到 Initial UE Message如果 AMF 根本没收到问题在 N2 链路或 gNB 到 AMF 的 SCTP 连接如果 AMF 收到了但没回 NAS问题在 AMF 侧处理逻辑或 AMF 到 UDM/AUSF 的服务化调用超时。解决时不要一上来就动空口参数T3510 超时通常有对端处理慢的根因调大定时器只是拖延问题。5.2 现象二RRC Reject 频繁但周围站点同样配置这个问题的典型特征是用户集中投诉某区域无法接入gNB 状态却显示小区正常。查 RRC Reject 的 cause通常是radioNetwork: not enough resources或者radioNetwork: congestion。实际原因往往不是物理资源真不够而是 gNB 的 RRC 连接数上限、CPU 过载保护、或某个 Specific Area 的高优先级业务保护策略把普通用户挤掉了。解决时先看小区最大连接数配置、再看准入控制策略、最后猜射频资源。按这个顺序排查避免一上来加 AAU 或扩载波费钱且无效。5.3 现象三PDU Session Establishment Reject 且 cause 是 insufficient resources当 UE 的注册、鉴权都成功但第一次请求 PDU 会话就被拒同时核心网日志里 cause 是“insufficient resources”时很多人直接怀疑 UPF 资源不够。但实际往往不是 UPF 硬件问题而是 SMF 给用户分配的 Qos Flow 与 UPF 侧已建规则冲突或者签约数据里的 APN/DNN 资源配置异常。解决路径先核对 UE 请求的 DNN 和 S-NSSAI 是否存在且已签约再检查 SMF 的 UPF 选择策略是否有可达的 UPF最后才去看 UPF 负载。很多翻车是因为新建了 DNN但 SMF 的 UPF 拓扑数据里没挂这个 DNN导致选择不到 UPF报错却是资源不足。5.4 现象四切换失败但两张日志对不齐排查切换失败时最容易踩的坑是时间戳不同步。gNB 日志用本地时间核心网日志用UTC两边差 8 小时导致无法把 RRC 重配和 NGAP Handover Required 对应起来。不要硬核对直接把两边时间统一成UTC再匹配。另外切换失败要看“源侧”和“目标侧”分开看。信令链路上有 Xn 切换和 N2 切换两种。Xn 切换看 RRC 重配和 Xn 接口消息N2 切换看 NGAP 的 Handover Required/Request。如果 N2 切换时 AMF 没有给目标 gNB 下发正确切片信息目标侧会回 Handover Failurecause 是 unknown or already allocated slice。这种问题出现在核心网切片签约数据不关空口的事。5.5 现象五抓包什么都看得到就是解不出NAS很多人喜欢在 N2 接口抓包然后满怀期待地解出 NAS 明文结果发现 Wireshark 只显示 NGAP 消息里有一串不透明的 NAS-PDU长度带[encrypted]标记。这不是抓包失败是安全激活后的正常加密。想解这条消息需要核心网的 NAS 密钥或者直接用 AMF 的日志看解密后的内容。另外SCTP 抓包如果出现大量重组错误多半是抓包丢包或网卡多队列导致乱序不是协议问题。抓包时要用-i any或者绑核并用 Wireshark 的sctp过滤器确认 stream 正常。血泪经验是抓 N2 接口前先和运维确认镜像口的位置很多人抓了半小时发现镜像口在一条无效链路上包全是镜像自己的流量。6. 进阶在本地用 OAI 跑一次注册并抓包验证你的理解6.1 不要在商用网元上实验先搭一个最小核心网基础信令最好是用一个小型开源 5G 核心网在本地跑通一遍。OpenAirInterface 是业界常见的开源 5G 核心网实现支持 AMF、SMF、UPF、AUSF、UDM、NRF 一个栈跑完。另一类可选是 free5GC它是标准 3GPP 流程实现默认提供 Web 界面查看注册用户。对学信令的人来说OAI 的日志更贴近协议细节free5GC 的界面更友好。在本地起一个最小核心网的通用做法是用一台 Ubuntu 虚拟机装好 OAI 核心网套件再用一个模拟 UE如 UERANSIM 的 UE 进程接上来。不需要真实基站UERANSIM 可以模拟 gNB 和 UE 之间的 RRC/NAS 交互二者自带的日志已经能看到完整信令。6.2 启动后先看这条命令输出确认 AMF 在等 N2核心网起来后AMF 日志里会持续打印等待 N2 建立的消息。这时可以看 AMF 的 ngap 进程状态确认 N2 SCTP 端口 38412 在监听。用这条命令确认ss -lntp | grep 38412输出中应能看到 LISTEN 状态的 IP 和端口。如果你看到的不是监听状态说明 AMF 没启动成功或端口被占用。端口正常后再启动模拟 gNBgNB 会主动向 AMF 发起 SCTP 连接并发送 NG Setup RequestAMF 回 NG Setup Response这说明 N2 链路已经打通。假设你在模拟 gNB 的日志里看到了 NGSetupResponse却没在 AMF 侧看到 UE 注册的后续信息可以考虑先用 tcpdump 在 AMF 节点抓包确认 SCTP 链路是否真的建立。注意 tcpdump 需要 root 权限抓包文件不要直接落在根目录外的大分区里避免磁盘撑满。6.3 抓包验证的关键过滤条件N2 接口抓包有两个最容易看的点一个是 NG Setup一个是注册流程。NG Setup 的包在 Wireshark 里用sctp ngap过滤能看到完整交互注册流程则用ngap.nAS_PDU过滤能看到每条 NGAP 消息里的 NAS-PDU IE。用 text 代码块展示一个离散消息示例Frame 22: InitialUEMessage ProtocolIE: id-RANuE-NGAP-ID ProtocolIE: id-NAS-PDU NAS-PDU: 7e0041...这条消息里的7e0041就是前面提过的 NAS 注册请求特征。看到它说明 NAS 已经从模拟 UE 一路透传到 AMF。如果这条消息里有 NAS-PDU 但 AMF 不回响应问题在 AMF 侧处理如果压根没有 InitialUEMessage问题在模拟 gNB 到 AMF 的链路配置。这个验证动作能让你在十分钟内把注册流程的主要消息全部过一遍。最后推荐给你的进阶习惯是不要依赖任何单一粒度日志上手跑一遍小核心网对准特征码再回到商用日志里找对应位置基础信令才算真正入脑。实务中我把这套方法至少用于十来起现场故障定位整体效率提升明显希望帮到你。本文还有配套的精品资源点击获取
5G基础信令从入门到排查：NAS/RRC/NGAP与注册流程精讲
简介PPT 系统讲解 5G 基础信令体系适合通信工程师、网络优化人员及 5G 入门学习者快速建立知识框架。内容从 5G 相比 4G 的新特性切入覆盖控制面 UE 状态机、RRC 连接建立/重配/重建/恢复/释放/RLF、统一接入控制、系统信息、寻呼、移动性管理与 EN-DC 双连接用户面则讲解新 QoS 机制、PDCP split 与 duplication、精简 RLC以及 SRB0/1/2/3 承载映射关系。同时还梳理了 5G 架构、空口协议和 LTE/NR 协议规范差异并总结了 Inactive 状态、On-demand SI、SUL、BWP、RNAU、Flow vs Bearer 等关键概念。资源为 1 个 pptx 文件压缩包 3.65MB目录层次清楚适合按章节快速查阅。目前已有 400 人学习。借助这份材料读者可以从信令整体到细节建立完整脉络为后续协议流程分析、信令排查和网优工作打下基础。1. 为什么先啃透5G基础信令一个“信号满格却上不了网”的现实场景插上5G卡手机显示满格可视频一直在转圈。网优拿着终端日志跑了一下午基站侧收到一堆RRC Setup Request核心网却迟迟看不到REGISTRATION REQUEST。问题出在哪不是覆盖不是频段是信令在某个节点上被丢弃或拒绝。5G基础信令正是把这类问题从“玄学”变成“可排查项”的那张地图——它不教你宏站怎么立、天线怎么调而是告诉你消息从手机到基站再到核心网每一步叫什么、长什么样、失败时回什么码。这篇笔记适合刚转5G的网优、开站调测的工程师、以及做协议栈或核心网测试的研发目标是让你拿到一份PPT题目也能建起整条信令面认知并在真实日志里找到定位路径。5G信令体系比4G多了一整层服务化架构接口从个位数胀到十几个但基础消息骨架仍然是UE发出请求gNB透传或映射AMF做移动性管理SMF做会话管理。所谓“基础”指的就是NAS、RRC、NGAP这三层消息以及注册、服务请求、PDU会话建立这三条主流程。先把这三层消息读熟再去碰切换、双连接、VoNR等进阶场景效率会高得多。2. 信令在哪些接口上跑网元、接口与协议栈速览2.1 先别急着背协议号把网元和接口画成一张图5G核心网和4G最大的区别是控制面引入了服务化架构网元之间从“点对点硬连接”变成了“注册到NRF按服务互相调用”。但对外和基站相关的接口仍然是点对点的理解基础信令只用盯住这个最小的环UE 通过空口 Uu 口连接 gNBgNB 通过 N2 口连接 AMF通过 N3 口连接 UPFAMF 又通过 N11 口找到 SMFSMF 通过 N4 口控制 UPF。这里最容易绕晕的地方是把 N2 和 N3 混着看。N2 承载的是控制面 NGAP 消息N3 承载的是用户面 GTP-U 隧道两者虽然都从 gNB 出发但终点完全不同N2 到 AMFN3 到 UPF。抓包时如果看到 GTP-U 的包那是用户面数据不是信令别在信令流程里去找它。网元清单不需要多基础信令只涉及四类角色UE、gNB、AMF、SMF/UPF。UPF 严格说属于用户面但 PDU 会话建立流程里有它一环所以也要知道它在这个流程里做什么——SMF 通过 N4 会话建立请求把包转发规则下发给它它不参与 NAS 消息。2.2 控制面和用户面分离信令只在控制面上跑5G 从架构上强制分离控制面和用户面。UE 发起的每条业务请求先走控制面完成认证、授权、会话建立随后用户面数据才通过 UPF 转发。这个设计带来的实际影响是信令排查只需要盯控制面消息用户面丢包、时延、乱序问题则要看 GTP-U 和 RTP/业务流两类问题用完全不同的日志工具。很多新手把“上不了网”一刀切归到信令问题结果在空口质量上排查了半天实际是 UPF 的转发规则没下发。控制面消息的路径是这样的UE 产生 NAS 消息封装在 RRC 消息里发给 gNBgNB 解出 RRC把 NAS 部分原封不动封装进 NGAP 消息发给 AMFAMF 处理 NAS再通过服务化接口调用 SMF。这条“原封不动透传”的规则很关键意味着 NAS 消息在 gNB 看来就是一个不透明容器。排查时可以在 gNB 日志、N2 抓包里看到完全相同的 NAS 十六进制一旦某一段对不上问题基本出在透传网关或封装格式上。2.3 协议栈分层NAS、RRC、NGAP各管什么现在把协议栈从下往上捋。空口侧PHY、MAC、RLC、PDCP、RRC。其中 RRC 负责连接管理、测量配置、安全激活承载的是一条条具体的“控制信令”PDCP 负责加密和完整性保护所以空口抓到 RRC 消息往往是密文解密需要拿到 gNB 侧的密钥材料。往核心网方向看N2 接口跑的是 NGAP传输层用 SCTP应用层还叠了一层 HTTP/2 和 JSON5G 核心网的服务化接口N1、N2 之外的 Namf、Nsmf 等也跑 HTTP/2。这意味着抓 NGAP 包时Wireshark 会先解析 SCTP 流再解析 NGAP 协议。如果 SCTP 流乱序或重组不了后面全是乱码那不是协议问题是抓包方式问题。NAS 层分两部分MM 子层管移动性即注册、去注册、服务请求、鉴权SM 子层管会话即 PDU 会话建立修改释放。RRC 和 NAS 的关系是NAS 是“业务逻辑”RRC 是“运输通道”。业务逻辑只关心我要注册、我要鉴权不关心空口质量好不好RRC 只关心连接能不能建起来、消息能不能可靠送到。2.4 一个注册流程在协议栈上的穿行顺序把理论落到实例注册流程是所有流程的地基。UE 开机后先做小区搜索和随机接入收到 RRC Setup 完成消息后在 RRCSetupComplete 里带上第一条 NAS 消息 REGISTRATION REQUEST。gNB 收到后向 AMF 发起 NGAP Initial UE Message把 NAS 塞进这个容器。AMF 收到后回 NGAP Initial Context Setup Request 或 Downlink NAS Transport把 REGISTRATION ACCEPT 装回去。这里有个重要的时间点安全激活发生在注册过程中间不是流程一开始。AMF 决定启用安全后会通过 gNB 下发 Security Mode CommandUE 回 Security Mode Complete之后空口消息才加密。所以在 RRCSetupComplete 阶段看到的 RRC 信令是明文注册请求也是明文再往后的 NAS 消息就要解密或者用核心网内部日志看了。这也是“基础信令讲解”里最常被忽略的一点。3. NAS信令的读写注册流程与鉴权参数怎么解3.1 REGISTRATION REQUEST里几个必须认识的IE拿到一条 REGISTRATION REQUEST先看它的几个关键信元而不是从头读到尾。第一个是 5G-GUTI 或 SUCI。UE 如果有上次注册的临时标识就用 5G-GUTI核心网可以根据它反查原来的 AMF减少重新鉴权。没有 GUTI 时用 SUCI也就是加密后的 SUPIAMF 需要把它转发给 AUSF 做解密和鉴权。第二个是 requested NSSAI即 UE 想注册的网络切片列表。这里注意NSSAI 的格式是 SSTSDSST 占 8 比特SD 占 24 比特。如果 UE 带了一个不存在的切片标识AMF 会回 registration reject with cause “slice not supported”这是 5G 时代新增且高频出现的失败原因。第三个是 5GMM capability 和 requested capabilities。UE 在这个 IE 里声明支持什么是否支持请求型 PDU 会话、是否支持 N1 模式、是否支持 MICO 模式。如果 UE 漏声明了某个能力核心网就不会给它下发相应特性。常见迷惑场景终端明明支持 VoNR注册消息里却没带 IMS voice over PS session supported导致核心网不给他做 IMS 域VoNR 完全起不来。3.2 用十六进制快速定位NAS消息类型NAS 消息是二进制编码开头几个字节有固定格式。Extended Protocol Discriminator 占第一个字节的高半字节5G 移动性管理消息是 0x7E5G 会话管理消息是 0x2E。第二个字节的比特 3 到比特 1 是 Security Header Type紧跟着的 Message Type 在第三个字节。用这个办法在日志里搜 7e 或 2e就能快速区分 MM 和 SM 消息族再对照消息类型表找到具体消息名。举例一条注册请求消息的前几个字节通常是7e 00 41 ...。0x41 是 REGISTRATION REQUEST 的消息类型码。而 PDU Session Establishment Request 是2e 01 c1 ...0xc1 是它的消息类型码。拿到这些特征码之后在基站日志或核心网日志里做字符串搜索比翻完整条消息快得多。提示别把 0x7e 和 0x2e 当成普适规则。它们只适用于 5G NAS 消息的协议鉴别符。4G 的 EMM 是 0x7e、ESM 是 0x2e部分场景一样但使用时要确认当前消息来自哪个制式别在 4G 日志里用 5G 规则去套。3.3 鉴权流程Authentication Request和Response的关键参数注册流程中必不可少的一步是鉴权。AMF 向 UE 下发 Authentication Request里面核心参数是 AUTN 和 RAND。AUTN 由 SQN、AMF、MAC 组成UE 端用共享密钥 K 和 RAND 计算期望的 MAC 和 SQN 做校验。如果 UE 认为 SQN 不同步超出范围它会回 Authentication Failure with cause “synch failure”并带上 AUTS 参数。AUSF 收到后可以据此重同步 SQN再发一次鉴权请求。这个场景在真实网络里很常见尤其是异地换卡、老卡新终端、HLR/HSS 数据不一致的时候。排查方法不是让用户换卡而是看核心网用户数据里的 SQN 和终端侧的 SQN 差多少。若相差过大重置签约数据里的 SQN 参数即可不需要重新写卡。很多工程项目把这个问题做成“换卡重发”实际是浪费了资源。鉴权成功后 AMF 发起 Security Mode CommandUE 回 Security Mode Complete。之后 NAS 消息带上了完整性保护和加密。注意Security Mode Complete 本身是明文还是密文不同厂家实现有差异。一般完整性保护已经打开所以内容未必可读这属于正常现象。3.4 服务请求流程与注册流程的区别注册流程解决的是“你是谁”的问题服务请求流程解决的是“你要传数据了”的问题。UE 在空闲态需要发数据或收数据时发起 Service Request核心网收到后通过 NGAP Initial Context Setup Request 让 gNB 为 UE 建立用户面资源。这个流程里常见问题UE 带了 uplink data status 字段说明有数据要发AMF 根据这个字段决定要不要激活用户面连接。如果 UE 没带这个字段AMF 可能不建立用户面导致应用层连接的 TCP 握手能完成但数据传输一直卡住。排查这类问题不要只盯 NAS要看 N2 上的 NGAP 消息里有没有建立 PDU Session Resource以及 N3 隧道有没有在 UPF 侧真正下发。4. RRC与NGAP接入和移动性里最容易翻车的信令点4.1 RRC Setup、重配里的关键IERRC 层基础消息里RRCSetup 是最常用的。gNB 发 RRCSetup 给 UE里面带 masterCellGroup 配置也就是 RLC 信道、MAC 配置、物理层配置、以及 SRB1 的配置。RRCSetupComplete 则是 UE 回给 gNB 的里面封装了 NAS 消息。RRCReconfiguration 是 RRC 层的重头戏它承载着切换命令、测量配置、DRB 建立等。RRCReconfigurationComplete 是 UE 回执如果不回gNB 会重发或者判定无线链路失败。排 RRC 问题时最重要的不是逐条读 IE而是先看 failure cause——消息里有 cause 字段可能是 radioNetwork、transport、protocol 三类。radioNetwork 里的 cause 值从 0 到 40 多每个编号查表即可不用背但其中 high 频的三个要熟radioNetwork: userInactivity、radioNetwork: radioConnectionWithUeLost、radioNetwork: unknownMibOrSib。4.2 RRC 消息的加密边界再强调一次RRC 消息不是全程明文。SRB1 在安全激活前是明文安全激活后加密SRB2 和 DRB 建立后全部加密。因此抓空口日志时能看到 RRCSetup、RRCSetupComplete 是明文RRCReconfiguration 也经常能看到但里面的关键配置已经被 cipher 了看到的是密文块。真正需要解 RRC 密文场景一般是切换失败分析或者 VoNR 语音质量问题需要拿到 gNB 侧的 PDCP 密钥或测试终端日志。普通工程排查不需要这一层看 RRC 建立流程本身已经足够定位 90% 的空口问题比如随机接入失败、资源不足、终端拒绝重配。不要为了看一个字段把终端日志的密钥体系全开投入产出比太低。4.3 NGAP 的初始上下文与 PDU 会话资源建立NGAP 作为 N2 接口信令核心消息有三条要熟Initial UE Message、Initial Context Setup Request、PDU Session Resource Setup Request。前两条对应 UE 接入和上下文建立第三条对应 PDU 会话建立。Initial UE Message 是 gNB 到 AMF 的第一条消息NAS 就存在它的NAS-PDUIE 里。这条消息同时还带 RAN UE ID、以及用户位置信息等。AMF 通过它获知 UE 要注册还是发数据再决定后续响应。Initial Context Setup Request 是 AMF 到 gNB 的消息里面带 Security Key、以及要让 gNB 建立的 PDU Session Resource 列表。gNB 收到后把这些信息映射成 RRC 连接重配UE 完成后回 RRC 重配完成gNB 再回 NGAP Initial Context Setup Response。整条链路如果哪一步断了对照这个消息和对应响应的 IE 缺失项就能定位。PDU Session Resource Setup Request 更细它里面有 PDU Session ID、S-NSSAI、QoS Flow 列表、以及 N3 隧道信息也就是 UPF 的 TEID 和地址。gNB 收到后本地为用户面建立 GTP-U 隧道并分配自己的 TEID然后把这个 TEID 回给 AMF最终一路传回 SMF。这一步是数据通路能否建立的关键。如果回包里的 TEID 是空的或者 UPF 侧收不到 gNB 的 GTP-U 包那问题通常出在 SMF 下发的转发规则或 UPF 路由上。4.4 NGAP 接口 ID 管理最容易让人懵的两个 IDNGAP 消息里有两套 UE 标识AMF UE NGAP ID 和 RAN UE NGAP ID。前者是 AMF 分配的后者是 gNB 分配的。两个 ID 在 Initial UE Message 建立关联后后续所有消息都靠它们来唯一标识这个 UE。排错时最烦的现象是日志里两条消息的 UE ID 对不上比如 gNB 日志写 RAN UE NGAP ID 12345AMF 日志写 AMF UE NGAP ID 67890。这不是错误是正常现象两者本来就是不同的值。容易踩坑的是在关联还未建立时某些消息只有 RAN UE NGAP ID某些只有 AMF UE NGAP ID这时候要把它们配合 Initial UE Message 里的关联关系做映射不能直接把 ID 当作对应标识来搜索。5. 避坑指南信令排查里常见的5个翻车现场5.1 现象一日志里全是NAS重传但空口质量正常排查注册慢或呼叫建立慢的问题时经常看到 UE 反复发 REGISTRATION REQUESTgNB 日志显示 RRC 一切正常重传的是 NAS 层。原因是 NAS 重传定时器 T3510 超时UE 没等到 REGISTRATION ACCEPT。排查顺序先看 AMF 有没有收到 Initial UE Message如果 AMF 根本没收到问题在 N2 链路或 gNB 到 AMF 的 SCTP 连接如果 AMF 收到了但没回 NAS问题在 AMF 侧处理逻辑或 AMF 到 UDM/AUSF 的服务化调用超时。解决时不要一上来就动空口参数T3510 超时通常有对端处理慢的根因调大定时器只是拖延问题。5.2 现象二RRC Reject 频繁但周围站点同样配置这个问题的典型特征是用户集中投诉某区域无法接入gNB 状态却显示小区正常。查 RRC Reject 的 cause通常是radioNetwork: not enough resources或者radioNetwork: congestion。实际原因往往不是物理资源真不够而是 gNB 的 RRC 连接数上限、CPU 过载保护、或某个 Specific Area 的高优先级业务保护策略把普通用户挤掉了。解决时先看小区最大连接数配置、再看准入控制策略、最后猜射频资源。按这个顺序排查避免一上来加 AAU 或扩载波费钱且无效。5.3 现象三PDU Session Establishment Reject 且 cause 是 insufficient resources当 UE 的注册、鉴权都成功但第一次请求 PDU 会话就被拒同时核心网日志里 cause 是“insufficient resources”时很多人直接怀疑 UPF 资源不够。但实际往往不是 UPF 硬件问题而是 SMF 给用户分配的 Qos Flow 与 UPF 侧已建规则冲突或者签约数据里的 APN/DNN 资源配置异常。解决路径先核对 UE 请求的 DNN 和 S-NSSAI 是否存在且已签约再检查 SMF 的 UPF 选择策略是否有可达的 UPF最后才去看 UPF 负载。很多翻车是因为新建了 DNN但 SMF 的 UPF 拓扑数据里没挂这个 DNN导致选择不到 UPF报错却是资源不足。5.4 现象四切换失败但两张日志对不齐排查切换失败时最容易踩的坑是时间戳不同步。gNB 日志用本地时间核心网日志用UTC两边差 8 小时导致无法把 RRC 重配和 NGAP Handover Required 对应起来。不要硬核对直接把两边时间统一成UTC再匹配。另外切换失败要看“源侧”和“目标侧”分开看。信令链路上有 Xn 切换和 N2 切换两种。Xn 切换看 RRC 重配和 Xn 接口消息N2 切换看 NGAP 的 Handover Required/Request。如果 N2 切换时 AMF 没有给目标 gNB 下发正确切片信息目标侧会回 Handover Failurecause 是 unknown or already allocated slice。这种问题出现在核心网切片签约数据不关空口的事。5.5 现象五抓包什么都看得到就是解不出NAS很多人喜欢在 N2 接口抓包然后满怀期待地解出 NAS 明文结果发现 Wireshark 只显示 NGAP 消息里有一串不透明的 NAS-PDU长度带[encrypted]标记。这不是抓包失败是安全激活后的正常加密。想解这条消息需要核心网的 NAS 密钥或者直接用 AMF 的日志看解密后的内容。另外SCTP 抓包如果出现大量重组错误多半是抓包丢包或网卡多队列导致乱序不是协议问题。抓包时要用-i any或者绑核并用 Wireshark 的sctp过滤器确认 stream 正常。血泪经验是抓 N2 接口前先和运维确认镜像口的位置很多人抓了半小时发现镜像口在一条无效链路上包全是镜像自己的流量。6. 进阶在本地用 OAI 跑一次注册并抓包验证你的理解6.1 不要在商用网元上实验先搭一个最小核心网基础信令最好是用一个小型开源 5G 核心网在本地跑通一遍。OpenAirInterface 是业界常见的开源 5G 核心网实现支持 AMF、SMF、UPF、AUSF、UDM、NRF 一个栈跑完。另一类可选是 free5GC它是标准 3GPP 流程实现默认提供 Web 界面查看注册用户。对学信令的人来说OAI 的日志更贴近协议细节free5GC 的界面更友好。在本地起一个最小核心网的通用做法是用一台 Ubuntu 虚拟机装好 OAI 核心网套件再用一个模拟 UE如 UERANSIM 的 UE 进程接上来。不需要真实基站UERANSIM 可以模拟 gNB 和 UE 之间的 RRC/NAS 交互二者自带的日志已经能看到完整信令。6.2 启动后先看这条命令输出确认 AMF 在等 N2核心网起来后AMF 日志里会持续打印等待 N2 建立的消息。这时可以看 AMF 的 ngap 进程状态确认 N2 SCTP 端口 38412 在监听。用这条命令确认ss -lntp | grep 38412输出中应能看到 LISTEN 状态的 IP 和端口。如果你看到的不是监听状态说明 AMF 没启动成功或端口被占用。端口正常后再启动模拟 gNBgNB 会主动向 AMF 发起 SCTP 连接并发送 NG Setup RequestAMF 回 NG Setup Response这说明 N2 链路已经打通。假设你在模拟 gNB 的日志里看到了 NGSetupResponse却没在 AMF 侧看到 UE 注册的后续信息可以考虑先用 tcpdump 在 AMF 节点抓包确认 SCTP 链路是否真的建立。注意 tcpdump 需要 root 权限抓包文件不要直接落在根目录外的大分区里避免磁盘撑满。6.3 抓包验证的关键过滤条件N2 接口抓包有两个最容易看的点一个是 NG Setup一个是注册流程。NG Setup 的包在 Wireshark 里用sctp ngap过滤能看到完整交互注册流程则用ngap.nAS_PDU过滤能看到每条 NGAP 消息里的 NAS-PDU IE。用 text 代码块展示一个离散消息示例Frame 22: InitialUEMessage ProtocolIE: id-RANuE-NGAP-ID ProtocolIE: id-NAS-PDU NAS-PDU: 7e0041...这条消息里的7e0041就是前面提过的 NAS 注册请求特征。看到它说明 NAS 已经从模拟 UE 一路透传到 AMF。如果这条消息里有 NAS-PDU 但 AMF 不回响应问题在 AMF 侧处理如果压根没有 InitialUEMessage问题在模拟 gNB 到 AMF 的链路配置。这个验证动作能让你在十分钟内把注册流程的主要消息全部过一遍。最后推荐给你的进阶习惯是不要依赖任何单一粒度日志上手跑一遍小核心网对准特征码再回到商用日志里找对应位置基础信令才算真正入脑。实务中我把这套方法至少用于十来起现场故障定位整体效率提升明显希望帮到你。本文还有配套的精品资源点击获取
