简介：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 口连接 gNB，gNB 通过 N2 口连接 AMF，通过 N3 口连接 UPF，AMF 又通过 N11 口找到 SMF，SMF 通过 N4 口控制 UPF。
这里最容易绕晕的地方是把 N2 和 N3 混着看。N2 承载的是控制面 NGAP 消息，N3 承载的是用户面 GTP-U 隧道，两者虽然都从 gNB 出发，但终点完全不同：N2 到 AMF，N3 到 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 消息里发给 gNB；gNB 解出 RRC，把 NAS 部分原封不动封装进 NGAP 消息发给 AMF；AMF 处理 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 和 JSON，5G 核心网的服务化接口（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 Command，UE 回 Security Mode Complete，之后空口消息才加密。所以在 RRCSetupComplete 阶段看到的 RRC 信令是明文，注册请求也是明文，再往后的 NAS 消息就要解密或者用核心网内部日志看了。这也是“基础信令讲解”里最常被忽略的一点。
3. NAS信令的读写：注册流程与鉴权参数怎么解
3.1 REGISTRATION REQUEST里几个必须认识的IE
拿到一条 REGISTRATION REQUEST，先看它的几个关键信元，而不是从头读到尾。第一个是 5G-GUTI 或 SUCI。UE 如果有上次注册的临时标识，就用 5G-GUTI，核心网可以根据它反查原来的 AMF，减少重新鉴权。没有 GUTI 时用 SUCI，也就是加密后的 SUPI，AMF 需要把它转发给 AUSF 做解密和鉴权。
第二个是 requested NSSAI，即 UE 想注册的网络切片列表。这里注意：NSSAI 的格式是 SST+SD，SST 占 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 移动性管理消息是 0x7E，5G 会话管理消息是 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 Command，UE 回 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、重配里的关键IE
RRC 层基础消息里，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 管理：最容易让人懵的两个 ID
NGAP 消息里有两套 UE 标识：AMF UE NGAP ID 和 RAN UE NGAP ID。前者是 AMF 分配的，后者是 gNB 分配的。两个 ID 在 Initial UE Message 建立关联后，后续所有消息都靠它们来唯一标识这个 UE。
排错时最烦的现象是日志里两条消息的 UE ID 对不上，比如 gNB 日志写 RAN UE NGAP ID = 12345，AMF 日志写 AMF UE NGAP ID = 67890。这不是错误，是正常现象，两者本来就是不同的值。容易踩坑的是在关联还未建立时，某些消息只有 RAN UE NGAP ID，某些只有 AMF UE NGAP ID，这时候要把它们配合 Initial UE Message 里的关联关系做映射，不能直接把 ID 当作对应标识来搜索。
5. 避坑指南：信令排查里常见的5个翻车现场
5.1 现象一：日志里全是NAS重传，但空口质量正常
排查注册慢或呼叫建立慢的问题时，经常看到 UE 反复发 REGISTRATION REQUEST，gNB 日志显示 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 Failure，cause 是 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 没启动成功或端口被占用。端口正常后，再启动模拟 gNB，gNB 会主动向 AMF 发起 SCTP 连接并发送 NG Setup Request，AMF 回 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 的链路配置。这个验证动作，能让你在十分钟内把注册流程的主要消息全部过一遍。最后，推荐给你的进阶习惯是：不要依赖任何单一粒度日志，上手跑一遍小核心网，对准特征码，再回到商用日志里找对应位置，基础信令才算真正入脑。实务中我把这套方法至少用于十来起现场故障定位，整体效率提升明显，希望帮到你。
本文还有配套的精品资源，点击获取
