你有没有想过:当你打开手机飞行模式再关闭,几秒后信号满格,这个过程中发生了什么?手机和谁"说"了什么?为什么基站只负责转发而不参与决策?答案藏在一条看不见的信令通道里——NAS(Non-Access Stratum,非接入层)。
想象一个跨国快递系统:
这就是NAS的设计哲学:手机与核心网之间的直接对话,基站只是邮递员。
与之相对的,是AS(Access Stratum,接入层)——手机和基站之间的直接对话,包括RRC、RLC、MAC等协议,处理的是无线连接管理。
┌─────────┐ ┌─────────┐
│ UE │◄──── NAS 信令 ────────►│ AMF │
│ (手机) │ (手机↔核心网直接对话) │ (核心网) │
└────┬────┘ └────▲────┘
│ │
│ AS 信令 AS 信令
│ (手机↔基站直接对话) │ (基站↔核心网)
│ │
▼ ▸
┌─────────┐ NGAP 信令 ┌─────────┐
│ gNB │◄───────────────────────►│ AMF │
│ (基站) │ (基站↔核心网对话) │ │
└─────────┘ └─────────┘
核心要点:NAS消息被"装"在RRC消息里,基站收到后不拆开看内容,直接通过NGAP消息转发给AMF。就像你用信封装了一封给朋友的信,交给快递员,快递员只管送,不拆信。
5G的NAS协议分为两个子层,各自管理不同的业务领域:
| 子层 | 全称 | 职责 | 类比 |
|---|---|---|---|
| 5GMM | 5G Mobility Management | 注册、认证、安全、去注册、寻呼响应 | 酒店前台:登记入住、身份验证、退房 |
| 5GSM | 5G Session Management | PDU会话建立/修改/释放、QoS流管理 | 酒店客房服务:开房、换房、退房 |
graph TD
A["NAS(非接入层)"] --> B["5GMM<br/>移动性管理"]
A --> C["5GSM<br/>会话管理"]
B --> B1["注册 Registration"]
B --> B2["认证 Authentication"]
B --> B3["安全模式 Security Mode"]
B --> B4["去注册 Deregistration"]
B --> B5["服务请求 Service Request"]
B --> B6["配置更新 Configuration Update"]
C --> C1["PDU会话建立"]
C --> C2["PDU会话修改"]
C --> C3["PDU会话释放"]
C --> C4["QoS流管理"]
style A fill:#1a73e8,color:#fff
style B fill:#34a853,color:#fff
style C fill:#ea4335,color:#fff
5GMM负责手机在网络中的"身份合法性"和"位置可达性"。核心功能包括:
注册(Registration)——相当于入住酒店 - 初始注册:手机开机后首次注册 - 移动性注册更新:手机移动到新的跟踪区 - 周期性注册更新:手机定期向网络报平安(类似酒店每天查房) - 紧急注册:无SIM卡时的紧急呼叫注册
认证与安全——前台核验身份证 - 网络验证手机身份(5G-AKA) - 协商加密和完整性保护密钥 - NAS安全模式控制
去注册(Deregistration)——退房 - 手机主动关机或飞行模式 - 网络强制去注册(如欠费)
5GSM管理手机的数据连接(PDU会话),相当于管你上网的"管道":
理解NAS状态机是掌握5G信令的核心。5GMM维护两套独立的状态:注册管理(RM)状态和连接管理(CM)状态。
| 状态 | 含义 | 类比 |
|---|---|---|
| RM-DEREGISTERED | 手机未在核心网注册 | 未入住酒店 |
| RM-REGISTERED | 手机已成功注册 | 已办理入住 |
| 状态 | 含义 | 类比 |
|---|---|---|
| CM-IDLE | 手机与AMF之间没有NAS信令连接 | 入住但人不在房间(外出) |
| CM-CONNECTED | 手机与AMF之间有NAS信令连接 | 入住且人在房间 |
stateDiagram-v2
[*] --> RM_DEREG : 手机开机
state "RM-DEREGISTERED" as RM_DEREG {
[*] --> CM_IDLE_1
state "CM-IDLE" as CM_IDLE_1
}
state "RM-REGISTERED" as RM_REG {
state "CM-IDLE" as CM_IDLE_2
state "CM-CONNECTED" as CM_CONN
[*] --> CM_IDLE_2
}
RM_DEREG --> RM_REG : 注册成功<br/>(Registration Accept)
RM_REG --> RM_DEREG : 去注册<br/>(Deregistration)
CM_IDLE_2 --> CM_CONN : Service Request<br/>(手机发起)
CM_IDLE_2 --> CM_CONN : 寻呼响应<br/>(网络发起)
CM_CONN --> CM_IDLE_2 : NAS连接释放<br/>(RRC释放/NGAP断开)
为什么分两套状态? 这是5G相对4G的重要改进。在4G中,EMM-REGISTERED和ECM-CONNECTED耦合较紧。5G将注册状态和连接状态分离后,手机可以处于"已注册但空闲"的状态——核心网知道你的存在,但不需要维持信令连接,大大节省了网络资源。
| 状态 | 含义 |
|---|---|
| PDU SESSION INACTIVE | 没有PDU会话,或者PDU会话已挂起 |
| PDU SESSION ACTIVE | PDU会话已建立,数据面通道可用 |
注意:5GSM的状态只在没有PDU会话建立时从INACTIVE到ACTIVE。一旦有PDU会话存在,它就处于ACTIVE状态,直到会话被释放。
NAS消息如何在无线网络上传输?答案是层层封装——就像俄罗斯套娃:
┌─────────────────────────────────────┐
│ NAS消息(最内层) │ ← UE与AMF的对话
│ ┌───────────────────────────────┐ │
│ │ RRC消息(第二层封装) │ │ ← UE与gNB的对话
│ │ ┌─────────────────────────┐ │ │
│ │ │ PDCP(加密+头压缩) │ │ │
│ │ │ ┌───────────────────┐ │ │ │
│ │ │ │ RLC(分段/重组) │ │ │ │
│ │ │ │ ┌───────────────┐ │ │ │ │
│ │ │ │ │ MAC(复用) │ │ │ │ │
│ │ │ │ │┌─────────────┐│ │ │ │ │
│ │ │ │ ││ PHY(空口传输)││ │ │ │ │
│ │ │ │ │└─────────────┘│ │ │ │ │
│ │ │ │ └───────────────┘ │ │ │ │
│ │ │ └───────────────────┘ │ │ │
│ │ └─────────────────────────┘ │ │
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘
下行方向反过来:AMF通过NGAP将NAS消息发给gNB,gNB封装在RRC消息(如DLInformationTransfer)中发给UE。
关键洞察:基站在这个过程中只是一个"透明转发器"。它知道有一条NAS消息要传递,但不知道NAS消息的具体内容(尤其安全模式建立后,NAS消息已被加密)。这种设计的好处是:
每条NAS消息都有一个固定的头部结构,理解它对于抓包分析至关重要:
┌──────────┬──────────┬──────────┬──────────────┐
│ Protocol │ Security │ Message │ Message │
│ Discrim. │ Header │ Type │ Body │
│ (4 bits) │ (var.) │ (1 byte) │ (var.) │
└──────────┴──────────┴──────────┴──────────────┘
Protocol Discriminator——协议鉴别符(4 bit)
| 值 | 含义 |
|---|---|
| 0b0111 | 5GMM消息 |
| 0b1110 | 5GSM消息 |
通过这4个bit,接收端就能知道这条NAS消息是给5GMM部门还是5GSM部门的。
Security Header Type——安全头类型
| 值 | 含义 |
|---|---|
| 0 | 无安全保护(明文) |
| 1 | 完整性保护 |
| 2 | 完整性保护 + 加密 |
| 3 | 完整性保护 + 加密(新5G NAS安全上下文) |
Message Type——消息类型(1字节)
| 5GMM消息类型 | 值 |
|---|---|
| Registration Request | 0x41 |
| Registration Accept | 0x42 |
| Deregistration Request | 0x45 |
| Service Request | 0x4C |
| Authentication Request | 0x56 |
| Security Mode Command | 0x59 |
| 5GSM消息类型 | 值 |
|---|---|
| PDU Session Establishment Request | 0xC1 |
| PDU Session Establishment Accept | 0xC2 |
| PDU Session Modification Request | 0xC5 |
| PDU Session Release Request | 0xD1 |
实战提示:用Wireshark抓包时,筛选NAS消息的过滤器是 nas-5gs。5GMM消息用 nas-5gs.mm,5GSM消息用 nas-5gs.sm。
手机开机后的初始注册,是NAS信令最完整、最典型的场景。以下逐条消息解析:
sequenceDiagram
participant UE as 手机(UE)
participant gNB as 基站(gNB)
participant AMF as 核心网(AMF)
Note over UE,AMF: 阶段一:RRC连接建立(AS层)
UE->>gNB: RRC Setup Request
gNB->>UE: RRC Setup
Note over UE,AMF: 阶段二:初始注册(NAS 5GMM)
UE->>gNB: RRC Setup Complete<br/>[NAS: Registration Request]
gNB->>AMF: NGAP: Initial UE Message<br/>[NAS: Registration Request]
Note over UE,AMF: 阶段三:认证(NAS 5GMM)
AMF->>gNB: NGAP: Downlink NAS Transport<br/>[NAS: Authentication Request]
gNB->>UE: RRC: DLInformationTransfer<br/>[NAS: Authentication Request]
UE->>gNB: RRC: ULInformationTransfer<br/>[NAS: Authentication Response]
gNB->>AMF: NGAP: Uplink NAS Transport<br/>[NAS: Authentication Response]
Note over UE,AMF: 阶段四:NAS安全模式(NAS 5GMM)
AMF->>gNB: NGAP: Downlink NAS Transport<br/>[NAS: Security Mode Command]
gNB->>UE: RRC: DLInformationTransfer<br/>[NAS: Security Mode Command]
UE->>gNB: RRC: ULInformationTransfer<br/>[NAS: Security Mode Complete]
gNB->>AMF: NGAP: Uplink NAS Transport<br/>[NAS: Security Mode Complete]
Note over UE,AMF: 阶段五:注册接受(NAS 5GMM)
AMF->>gNB: NGAP: Downlink NAS Transport<br/>[NAS: Registration Accept]
gNB->>UE: RRC: DLInformationTransfer<br/>[NAS: Registration Accept]
Note over UE,AMF: 阶段六:PDU会话建立(NAS 5GSM)
UE->>gNB: RRC: ULInformationTransfer<br/>[NAS: PDU Session Est. Request]
gNB->>AMF: NGAP: Uplink NAS Transport<br/>[NAS: PDU Session Est. Request]
AMF->>gNB: NGAP: Downlink NAS Transport<br/>[NAS: PDU Session Est. Accept]
gNB->>UE: RRC: DLInformationTransfer<br/>[NAS: PDU Session Est. Accept]
阶段一:RRC连接建立
这是AS层(接入层)的工作,不属于NAS,但NAS消息必须依赖RRC连接才能传输。手机先要和基站建立一条无线链路。
阶段二:初始注册请求
手机发出第一条NAS消息 Registration Request,关键信息包括:
为什么Registration Request没有安全保护? 因为此时手机和网络还没有协商安全上下文,所以这条消息是明文传输的。但手机会在消息中携带一个"Registration Request的完整性校验值"(MAC),用于后续验证。
阶段三:认证
网络向手机发送 Authentication Request,包含:
手机收到后,用SIM卡中的密钥计算 Authentication Response,返回 RES(响应值)。网络验证RES是否正确,从而确认手机身份。
$$RES^* = KDF(CK, IK, RAND)$$
其中KDF是密钥派生函数,CK和IK是SIM卡与网络共享的密钥。
阶段四:NAS安全模式
认证通过后,AMF发起 Security Mode Command,协商NAS层的安全参数:
从此以后,所有NAS消息都被加密和完整性保护。基站看到的是密文,只有手机和AMF能解密。
阶段五:注册接受
AMF发送 Registration Accept,关键信息包括:
阶段六:PDU会话建立
注册完成后,手机通过5GSM子层发起 PDU Session Establishment Request,建立到数据网络(如互联网)的连接。这条消息已经受到NAS安全保护。
NAS协议依赖一系列定时器来保障信令流程的可靠性。如果某条消息没有在规定时间内收到回复,定时器超时后会触发重传或错误处理。
| 定时器 | 触发条件 | 超时动作 |
|---|---|---|
| T3510 | 发送Registration Request | 重传注册请求(最多重试5次) |
| T3511 | 注册被拒绝后 | 等待后重新尝试注册 |
| T3512 | 注册成功 | 周期性注册更新(防止核心网"忘记"手机) |
| T3517 | 发送Service Request | 服务请求失败处理 |
| T3519 | 发送Deregistration Request | 去注册请求超时,本地释放 |
| T3521 | 发送Notification Response | 通知响应超时 |
| T3540 | 等待Configuration Update | 配置更新超时 |
最重要的定时器:T3512
T3512的值在Registration Accept中由网络下发给手机。典型值是54分钟(3240秒)。手机每54分钟发一次周期性注册更新,告诉核心网"我还活着"。如果核心网在几个T3512周期内没收到更新,就会认为手机已关机或离开覆盖区,将其标记为不可达。
调试陷阱:如果现网中手机频繁掉线,先查T3512是否配置合理。过短会导致信令风暴(大量手机同时做周期性更新),过长会导致核心网无法及时感知手机离线。
NAS和RRC虽然分属不同层,但它们紧密协作。理解它们的分工是调试信令问题的关键:
| 维度 | NAS(非接入层) | RRC(接入层) |
|---|---|---|
| 对话双方 | UE ↔ AMF | UE ↔ gNB |
| 传输介质 | 搭载在RRC消息中 | 直接通过空口 |
| 安全保护 | NAS层加密+完整性 | AS层加密(PDCP) |
| 关注什么 | 注册、认证、会话 | 无线承载、测量、切换 |
| 状态机 | RM/CM状态 | RRC_IDLE/INACTIVE/CONNECTED |
| 消息示例 | Registration Request | RRC Reconfiguration |
协作场景举例:
手机发起Service Request:NAS层发出Service Request,但底层需要RRC先建立连接。所以UE先发RRC Setup Request,等RRC连接建好后,才把NAS的Service Request封装在RRC消息中发出。
切换过程中:RRC层处理切换信令(如RRC Reconfiguration with sync),NAS层不参与。切换完成后,NAS层可能感知到TAI变化,触发移动性注册更新。
RRC连接释放:gNB发起RRC Release,UE进入RRC_IDLE。但NAS层的CM状态可能还是CONNECTED(需要等NGAP连接也释放后才变为CM-IDLE)。
调试关键:抓信令时,如果看到NAS消息收不到回复,先检查RRC连接是否正常建立。RRC断开了,NAS消息自然无法传输——这不是NAS的问题,是底层"路"断了。
| 对比维度 | 4G NAS | 5G NAS |
|---|---|---|
| 移动性管理 | EMM(EPS Mobility Management) | 5GMM |
| 会话管理 | ESM(EPS Session Management) | 5GSM |
| 注册类型 | Attach(附着) | Registration(注册) |
| 会话类型 | EPS Bearer | PDU Session + QoS Flow |
| 状态模型 | EMM-DEREGISTERED/REGISTERED ECM-IDLE/CONNECTED |
RM-DEREGISTERED/REGISTERED CM-IDLE/CONNECTED |
| 安全架构 | EPS安全上下文 | 5G安全上下文(增强隐私保护) |
| 核心网网元 | MME(合一网元) | AMF(移动性)+ SMF(会话) |
| 身份隐私 | IMSI可能明文传输 | SUCI加密传输(公钥加密) |
| 网络切片 | 不支持 | S-NSSAI |
最重要的演进:身份隐私保护
4G时代,手机在某些情况下会明文发送IMSI(国际移动用户标识),存在被窃听追踪的风险。5G引入了SUCI(Subscription Concealed Identifier)机制:手机用网络的公钥加密SUPI(5G的IMSI),生成SUCI。即使被窃听,攻击者也无法解密得到真实身份。
$$SUCI = Encrypted( SUPI, PK_{home_network} )$$
这是一个从"身份证号"到"加密信封"的质变。
在5G核心网调试中,NAS消息是最重要的线索来源:
| Cause Value | 含义 | 典型原因 |
|---|---|---|
| #3 | Illegal UE | SIM卡被拉黑 |
| #6 | Illegal ME | 手机IMEI被拉黑 |
| #7 | 5GS services not allowed | 用户未签约5G服务 |
| #11 | PLMN not allowed | 当前PLMN在禁用列表中 |
| #12 | Tracking area not allowed | 当前TA不在允许列表 |
| #15 | No suitable cells in tracking area | TA内无合适小区 |
| #22 | Congestion | 网络拥塞 |
| #27 | N1 mode not allowed | 非NAS N1模式不允许 |
陷阱1:NAS超时不一定是NAS问题
手机发出Registration Request后T3510超时,可能原因有: - RRC连接未建立成功(AS层问题) - gNB到AMF的NGAP连接故障(传输层问题) - AMF负载过高处理不过来(核心网问题) - NAS消息本身格式错误被AMF丢弃(终端问题
排查时要从底层往上查:PHY → MAC → RLC → RRC → NGAP → NAS。
陷阱2:5G-GUTI重分配不影响注册状态
网络通过Configuration Update Command给手机分配新的5G-GUTI,这只是换了"临时身份证",不影响RM-REGISTERED状态。有些工程师误以为这是重新注册,其实不是。
陷阱3:Service Request不是注册
手机在CM-IDLE状态下收到寻呼后发Service Request,这是CM状态从IDLE到CONNECTED的转换,不需要重新注册。RM状态始终是REGISTERED。
Q1: NAS和RRC都是控制面信令,它们有什么本质区别?
A: 最本质的区别是"对话对象"不同。NAS是手机与核心网(AMF)之间的直接对话,RRC是手机与基站之间的直接对话。NAS消息"搭便车"通过RRC传输,但基站不解读NAS内容。用实际例子说:NAS决定"你是谁、能干什么",RRC决定"用哪条无线链路传输"。
Q2: 为什么手机不直接和AMF通信,非要经过基站?
A: 因为手机和AMF之间没有直接的物理连接。无线信号只能到达附近的基站,基站通过有线网络(NG接口)连接核心网。NAS的设计巧妙之处在于:虽然物理上必须经过基站转发,但逻辑上手机和AMF是"端到端"对话的。这种"逻辑直连、物理中转"的设计,让核心网业务逻辑完全独立于无线接入技术。
Q3: NAS安全模式建立后,基站还能看到NAS消息内容吗?
A: 不能。NAS安全模式建立后,NAS消息体被加密,只有UE和AMF拥有解密密钥。基站只能看到NAS消息的安全头(用于路由),但看不到消息体。这与AS安全(PDCP加密)是独立的——NAS加密是端到端(UE↔AMF),AS加密是段到段(UE↔gNB)。
Q4: 4G的Attach和5G的Registration有什么关键区别?
A: 除了名称变化,最重要的区别有三个:(1)5G注册支持网络切片选择(携带Requested NSSAI);(2)5G注册过程增强了对用户身份的隐私保护(SUCI代替IMSI明文);(3)5G将注册(5GMM)和会话管理(5GSM)更清晰地分离到不同网元(AMF和SMF),4G中MME同时负责这两件事。
Q5: 周期性注册更新会不会造成信令风暴?
A: 如果T3512配置合理,不会。关键在于手机给每个手机加一个随机偏移量(jitter),避免所有手机在同一时刻发起注册。但如果网络发生大面积故障恢复后,大量手机同时重新注册,可能触发信令风暴。现网中需要设计信令拥塞控制机制(如AMF的过载控制功能),在极端情况下拒绝部分注册请求以保护网络。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生(微信ID: gprshome201101)维护,聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
