企业官网建设流程全解析

第一次打开5G信令跟踪界面的时候，满屏的NAS让我恍惚了很久——那时候我做存储运维的朋友天天把NAS挂嘴边，我还以为移动通信也要挂网络硬盘。后来跟着前辈做了大半年的5G接入流程，才彻底弄明白：在通信协议的世界里，NAS是Non-Access Stratum，非接入层，是终端和核心网之间的控制信令协议栈，跟硬盘没有半点关系。不少人对RRC、Massive MIMO头头是道，一到NAS就含含糊糊，尤其标题里还带着(SA)——为什么非要强调SA呢？我觉得有必要把这块“基础中的基础”认真梳理一遍。这篇文章只讲5G SA场景下的NAS，从它是什么、在哪一层、消息怎么封装、核心流程怎么走，到日志里怎么看、现场怎么排障，尽量一步到位。适合刚接触5G核心网、网优测试或者协议开发的读者参考。

1. 先分清：此NAS非彼NAS

1.1 “非接入层”到底在协议栈的哪一层

5G无线协议栈从空口往上，大体分成两层：接入层和非接入层。接入层包含RRC、PDCP、RLC、MAC、PHY这一串，负责一个小区的无线资源管理、调度和数据承载；非接入层则是在接入层之上，直接和核心网交互的一层。说白了，接入层管“怎么把数据通过无线方式传对地方”，非接入层管“终端和网络之间用什么规则办手续”。

我常用一个寄快递的例子来解释这个分工。你要寄一个包裹，快递员负责搬运、分拣、装车，这是接入层的事；你填写运单、保价、选择签收方式，这些约定写在单子上，快递员不关心内容，最终是快递公司后台系统按单子处理——这就是非接入层。基站就是这个快递员，它搬运NAS消息，但不拆开看；真正拆开处理NAS消息的，是核心网侧的控制面网元。

5G NAS协议主要由TS 24.501定义，里面又分成两大部分：5GMM，移动性管理；5GSM，会话管理。前者管注册、去注册、服务请求、寻呼这类和“人的身份与位置”相关的事，后者管PDU会话、QoS流这类和“数据通道”相关的事。这两个概念后面会反复用到，建议先记在脑子里。

1.2 (SA)不是随便加的：NSA与SA下NAS的差别

为什么标题一定要带(SA)？因为5G组网在落地时走了两条路：NSA和SA。

NSA，非独立组网，早期最常见。终端可能同时连着LTE和NR两个小区，但控制面锚点在LTE侧，核心网用4G的EPC或者5GC，终端在NAS层走的其实是4G时代定义的EMM/ESM流程。也就是说，注册、鉴权、会话建立的“核心逻辑”还是4G的，NR主要分担用户面数据。SA，独立组网，才是完整的5G端到端架构：终端通过gNB接入5G核心网，AMF承担移动性管理，NAS消息走的是5G定义的5GMM/5GSM。

这就解释了一个很奇怪的现象：很多测试报告里终端明明显示5G图标，但信令列表里清一色是LTE的RRC和EMM消息——那是NSA终端，真正的5G NAS要到SA环境下才看得到。所以，标题里的(SA)不是随手加的，它把讨论范围明确限定在“终端和5GC之间的NAS层行为”，而不是“任何挂着5G名字的接入流程”。这一点很容易被初学者忽略，却是后续所有排查的基础。

2. NAS消息在SA网络里的传输路径：一个“信封套信封”的过程

2.1 从终端到AMF，NAS消息被包了几层

理解NAS之前，先理解它在网络里怎么“跑”。这个路径不长，但每一层都有各自的封装和职责。

上行方向：UE在RRC连接建立完成后，把NAS消息放到RRC消息的dedicatedInfoNAS字段里发出去，最常见的容器是RRCSetupComplete。gNB收到这条RRC消息后，并不解析NAS内容，而是把里面的NAS PDU原封不动拿出来，再装进NGAP协议的消息里，比如InitialUEMessage或者UplinkNASTransport，通过N2接口送给AMF。AMF解开NGAP的封装，才真正开始处理NAS消息。

下行方向刚好反过来：AMF把NAS消息放进NGAP消息里发给gNB，最典型的是DownlinkNASTransport；gNB把NAS PDU剥出来，重新装进RRC的DLInformationTransfer或者RRC重配置消息里，通过空口发给UE。如果AMF还在建立UE上下文的阶段，NAS消息也可能随InitialContextSetupRequest一起下来，所以日志里不一定每次都看到DownlinkNASTransport，但无论走哪条NGAP消息，识别点都是里面的NAS-PDU字段。

三层消息套在一起，就像一个“信封套信封”的过程：空口的RRC是外层信封，里面装着NGAP的封装信息，最核心的信才是NAS。基站能看到信封外的标签，但不会拆开信看内容；真正拆信的是UE和AMF。这个模型记牢了，后面大部分信令问题都能按层次切分。

2.2 5GMM与5GSM：为什么同一个NAS要分成两套班子

NAS内部的分工非常明确，这个分工也是5G“控制面和服务分离”思路的体现。

5GMM管的是“终端在网络里的身份和位置”，包括注册、更新、去注册、服务请求、寻呼响应。处理主体是AMF。5GSM管的是“终端和网络之间的数据会话”，包括PDU会话的建立、修改、释放、QoS配置。处理主体其实是SMF，AMF在这中间主要做转发——把5GSM消息当作需要转发的SM信息，通过N11接口递给SMF。

这个分工在现场排查时非常有用：如果UE一直注册不上，重点怀疑5GMM相关的环节，比如AMF、鉴权、安全算法、网络切片选择；如果注册是成功的，但业务起不来，再去查5GSM相关的环节，比如SMF、UPF、DNN、QoS流配置。把这两个域混在一起排查，很容易在错误方向浪费半天时间。

还有一个容易被忽略的点：5GSM消息并不是独立跑在空口上的，它由5GMM提供上下行NAS传输服务来承载。日志里看到一条UL NAS TRANSPORT，里面套着一个PDU Session Establishment Request，是非常常见的现象。如果不懂这条承载链，后续抓包解码很容易找错方向。

3. 注册、鉴权、PDU会话：SA网络里绕不开的三条NAS流程

3.1 注册流程的完整时序：从SUCI到5G-GUTI

SA组网下，UE开机入网的第一步是注册。把流程压缩到一个很经典的状态机里看，大概是这样的：

• UE发出Registration Request，里面携带SUCI（签约隐藏标识），或者在已有上下文时代带上次分配的5G-GUTI。
• AMF向AUSF/UDM要认证向量，UE收到Authentication Request后校验AUTN，返回Authentication Response。
• 认证通过后，AMF下发Security Mode Command，选定NAS完整性保护和加密算法，UE回Security Mode Complete。
• AMF再给UE回Registration Accept，里面包含新分配的5G-GUTI、TA List、允许的NSSAI列表等。
• UE回Registration Complete，用来确认自己已经拿到了新身份。

很多人容易漏掉的点：Registration Complete并不是“事务结束”的标志，而是一个“确认收到新身份”的动作。UE如果一直没收到Accept，它会按定时器重发Registration Request；如果分配的TA List太小，UE很快又会触发注册更新；如果周期性注册定时器到来，也会再走一次注册流程。这些看起来都是同一条流程，区别主要在Request里的cause值不同。

5G在身份标识上有一个重要改动：把IMSI换成了SUPI和SUCI的体系。UE先用网络下发的公钥把SUPI加密成SUCI，避免空口直接传永久身份被截获和追踪；AMF再配合UDM解密拿到真正的SUPI。这也是5G相对4G在隐私保护上的核心改进，属于NAS层身份机制的基本功，值得多花点时间理解。

提示：排查注册类问题，先看Registration Request里带的是SUCI还是5G-GUTI，再看Accept里分配的新GUTI和TA List。这两种消息配对一旦不齐，问题往往就出在缺失的那一侧。

3.2 安全模式：KNASint、KNASenc是如何出场的

注册流程里，鉴权和安全模式是最容易让人犯怵的一部分，但原理上并没有那么复杂。

5G的认证根子密钥是K，存在USIM和网络侧。通过5G AKA流程，UE和网络各自推算出KSEAF，再由KSEAF进一步导出KAMF，最后AMF从KAMF派生出NAS完整性保护密钥KNASint和NAS加密密钥KNASenc。这一连串推导对新手来说不用背具体函数，记住“根密钥不变，各级密钥逐级派生”就够了。

AMF下发Security Mode Command时，会明确通知UE接下来用哪套算法。完整性保护算法是NIA0/NIA1/NIA2/NIA3，加密算法是NEA0/NEA1/NEA2/NEA3。商用网络里通常会把NEA0和NIA0禁用——这两个算法代表不加密和不做完整性保护，一旦在SMC里看到它们被选中，基本可以断定网络侧配置出了问题。

从Security Mode Command这条消息开始，完整性保护就生效了；加密是否启用取决于协商出来的NEA算法。所以在日志里，SMC之前的NAS消息都是明文的，SMC之后如果解不出来，先检查解密参数和密钥是否匹配，而不是一上来怀疑空口质量。

3.3 PDU会话建立：5GSM消息在背后的联动方式

注册解决的是“终端入网”，但用户要上网，还得建PDU会话。PDU会话建立流程是5GSM的主场。

UE发起PDU Session Establishment Request，里面带PDU Session ID、请求的DNN、S-NSSAI、QoS要求等信息。AMF收到后，根据DNN和切片信息选择SMF，把SM部分转发给SMF。SMF协调UPF，配置N3和N4相关资源，同时让AMF通过N2接口向gNB发起PDU会话资源建立流程。gNB随后给UE配置无线承载，最后AMF再把PDU Session Establishment Accept下发给UE，里面通常包含分配好的IP地址、QoS规则等关键信息。

从NAS层角度看，5GSM消息在整个流程里既负责“请求-应答”，也会出现网络侧主动发起“命令-完成”的配对。比如网络侧主动修改PDU会话时，先下PDU Session Modification Command，UE回Modification Complete；释放时可能由UE发起Release Request，也可能由网络侧发起。这种“请求-接受”和“命令-完成”的对应关系如果不弄清楚，看协议日志时很容易把两条相似消息配错对，导致流程判断南辕北辙。

4. 打开信令日志：NAS消息头、Message Type和定位技巧

4.1 一条NAS消息从头看到尾，先看这三个字段

一条完整的5GMM NAS消息，开头几个字节基本决定了它的性质。第一个字节是扩展协议判别符，用来区分这是5GMM、5GSM还是其他消息族；第二个字节是安全报头类型，能看出这条消息有没有完整性保护、有没有加密；第三个字节是消息类型，直接决定这条消息是注册请求还是鉴权响应，或者PDU会话建立请求。

用生活类比就是：协议判别符像“部门代号”，安全报头像“密封等级”，消息类型像“公文标题”。一条消息是什么性质，开头就能看出大半，不需要一路读到结尾。后面跟着的IE则按消息类型逐个解析，比如Registration Request里的UE安全能力、请求的NSSAI、SUCI等，Authentication Request里的RAND和AUTN等。

带着这个习惯看日志，能快速摆脱“看哪条都像天书”的状态。信令分析工具里通常会把NAS消息直接解码成可读字段，但如果你不知道先看什么、后看什么，解出来的几十个字段反而会让你更晕。我的经验是：永远先读取消息类型，再定位流程节点，最后才看具体IE里的值和原因。

4.2 常用NAS消息对照表：看日志时快速认脸

在SA网络里，实际经常打交道的NAS消息并不算多。把它们的名字、归属和用途放在一张表里，现场翻起来很方便。

提示：消息类型的具体十六进制数值在不同协议版本里可能调整，排障时优先记消息名称和流程配对，别去死记硬背数值。真到要手工解码的时候，直接查TS 24.501的附录比脑子更可靠。

4.3 在三层日志里怎么快速找到NAS消息

NAS消息本身不会独立出现，它总是装在某条RRC或者NGAP消息里。所以看日志的第一步，是知道“去哪里找NAS”。

无线侧日志里，重点过滤RRCSetupComplete、RRCResumeComplete、RRCReestablishmentComplete这些消息，看里面的dedicatedInfoNAS字段；RRC的DLInformationTransfer里也会带下行NAS消息，这是空口最常见的外层信封。N2接口日志里，重点过滤InitialUEMessage、UplinkNASTransport、DownlinkNASTransport、InitialContextSetupRequest，有NAS PDU字样的消息都值得展开。核心网侧如果只有AMF的跟踪日志，还要看N11接口上的SM消息，才能把5GSM链路补齐。

很多新手只盯着空口那一段看，结果发现UE发了PDU Session Establishment Request，却找不到Accept，就以为是核心网没回。实际上Accept早就下来了，只是装在另一个NGAP消息里，或者是在RRC重配置消息里没被找到。把三层日志的过滤习惯练起来，这种“假缺消息”的问题会少很多。

5. 三个NAS层问题的实战排查复盘

5.1 注册卡在Security Mode Command之后，问题却在N2

某次排查遇到的现象非常典型：某款终端在SA小区上电后，信令列表显示UE发了Registration Request，网络回了Authentication Request，UE也正常回了Authentication Response；随后AMF下发Security Mode Command，UE回了SMC Complete，然后——没有然后了。Registration Accept始终没有出现，过了一会儿UE又从头开始注册。日志看起来就像“安全模式之后网络失联”。

我的排查思路是分三步走的。第一步，确认SMC里选的算法在不在UE上报的安全能力列表里。如果UE不支持AMF选的算法，UE会直接回Security Mode Reject，但这里没有Reject，说明算法本身没问题。第二步，看SMC Complete有没有被gNB成功转发到AMF。在N2接口日志里搜UplinkNASTransport，如果SMC Complete根本没有上行到AMF，问题就出在空口或者gNB转发。第三步，如果AMF确实收到了SMC Complete，注册流程要继续走，AMF通常会通过N2向gNB发起InitialContextSetupRequest来建立UE上下文；这条N2链路如果配置有误，AMF就下不去Registration Accept。

最终定位是AMF到gNB的N2用户面路径映射错误，InitialContextSetup在gNB侧失败，AMF只能干等。这个案例很能说明问题：注册流程看着是NAS层的节目单，但幕后的N2和NGAP资源才是真正搭台子的。NAS卡住时，优先去查NGAP上下文是否建立成功，往往比反复看NAS消息本身更快。

提示：注册流程里NAS是“面子”，N2和NGAP是“里子”。看到NAS流程中断，先不要急着怀疑NAS协议本身，看看NGAP链路和承载配置是否完整。

5.2 PDU会话被拒绝：先看5GSM cause，再看请求切片

另一个高频问题出现在业务建立阶段。现象是注册成功、状态栏显示5G，但业务打不开。日志里PDU Session Establishment Request后面直接跟着一个PDU Session Establishment Reject，里面带5GSM cause。

遇到这种消息，我的习惯是先看两个点。第一点是Reject里的cause值，5GSM cause能明显区分出DNN配置错误、切片不允许、QoS协商失败、资源不足等方向。第二点，回看UE发出的Request里带的S-NSSAI和DNN，是不是在Registration Accept允许的NSSAI范围内。如果UE请求的切片本身就没被允许，SMF拒绝它是顺理成章的事，终端改什么都白搭。

还有一种情况值得注意：PDU Session Establishment Accept已经下来了，但几秒后PDU会话又被释放掉。这种“先成功后失败”的模型，多数问题出在核心网侧，例如UPF到DNN的链路不可达，或者SMF和UPF之间的N4会话建立异常，而终端侧往往没有责任。排查时用“先切分问题域”的办法：UE侧看请求的切片和QoS，AMF和SMF侧看N11和N4，gNB侧看N2和无线承载，层层确认，比在一条NAS消息上反复纠结更有效。

5.3 同一个TA里反复注册：NSSAI对不上引发的“套娃”

还有一个很有意思的案例，UE在同一个TA里每隔一小段时间就重新发起Registration Request。网络侧有时回Accept，但Accept里的Allowed NSSAI和UE请求的NSSAI对不上，然后UE过一会儿又发起注册。整个过程就像套娃一样反复。

这种问题的根因通常在切片配置的对齐上。AMF配置了支持的S-NSSAI列表，UDM里签约的切片数据却和AMF支持的切片不一致；或者AMF没有配置标准SST映射表，导致UE请求的S-NSSAI在AMF侧映射不到允许的切片。此时UE虽然可以完成注册，但网络无法为它建立PDU会话，UE只能反复尝试注册，或者很快申请回落到LTE网络。

排查时我习惯对比三张表：UE请求的requested NSSAI、AMF返回的allowed NSSAI、UDM签约的切片数据。三张表只要有一张对不齐，切片流程就会出问题。NAS消息里的NSSAI字段看着只有几个字节，但背后牵扯AMF、UDM、SMF整个切片体系。基础概念越扎实，这种问题的定位速度就越快。

6. 状态机、定时器与实用排查小习惯

6.1 5GMM状态机与T3502、T3519

NAS层也会维护状态机。UE侧的5GMM主要在两个大状态之间切换：5GMM-DEREGISTERED和5GMM-REGISTERED。前者代表未注册，里面还有等待响应等过程状态；后者代表已注册，周期性更新和TA更新都在这个状态下触发。PDU会话侧则是5GSM状态，一个PDU Session ID对应一套会话状态，从INACTIVE到ACTIVE变化，中间还有建立中、修改中等过程。

排查“反复注册”一类问题，重点看两个定时器：T3502和T3519。T3502负责注册失败或拒绝后的退避重试，T3519负责周期性注册更新。如果网络侧下发的周期更新定时器时间很短，或者UE注册失败后按T3502反复尝试，信令列表里就会出现一串节奏固定的Registration Request。看到UE每隔固定秒数发同样的消息，先想想是不是定时器在驱动，而不是怀疑网络随机故障。

状态机和定时器不是纯粹的书本概念，它们在日志里的表现非常直观。能说出“这个UE现在处于5GMM-DEREGISTERED状态，正在按T3502重试”和只会说“UE一直在发注册请求”，完全是两个排查水平。前者能预判下一步网络会做什么，后者只能等日志刷新。

6.2 排查NAS的三个小习惯

最后分享三个我自己一直沿用的小习惯，虽然简单，但很实用。

第一个习惯是三层信令一起抓。RRC、NGAP、NAS三层都要留日志，只看NAS解出来的字段容易漏掉封装和转发环节的问题。第二个习惯是先看消息配对再看IE。无论注册还是PDU会话，先把“请求-响应”“命令-完成”配齐，缺哪个补哪个，缺掉的环节往往就是问题所在。第三个习惯是保存原始日志并标好时间线。排查结束后把原始跟踪文件留存，方便事后跟协议文档逐条核对；分析时按时间线说事，不要凭印象，这样和同事或者厂商沟通时也更有抓手。

带新人的时候我经常说一句话：NAS字段记不住没关系，会查文档、会抓关键消息配对，比死记硬背更有用。但至少要记得，打开日志第一件事是看消息头，第二件事是找Result或Cause，第三件事才是按时间线把三层消息串起来。这个顺序能帮你避开很多无效翻日志的弯路。

最后说一句个人体会的话：能快速报出“当前卡在Security Mode Command之后”的人，往往不是记了多少协议细节，而是脑子里有一张数据流转的图。把NAS放在RRC和NGAP的中间去理解，很多疑难问题都会慢慢变简单。希望这篇5G NAS(SA)的基础梳理，能帮你在日志面前少走几次弯路。