首页 › deep-tech › 5G短消息：搭NAS信令便车的原理

5G短消息：搭NAS信令便车的原理

短信，这个诞生于1992年的"古董级"业务，在5G时代不但没有消亡，反而获得了一条全新的传输通道——SMS over NAS。本文将带你深入理解这条通道的设计哲学。

一、一个"老业务"的5G新问题

想象一下这个场景：你是一个5G运营商，刚刚建好了5G SA核心网，万事俱备。但这时候发现一个尴尬的事实——你的用户还在发短信，而你的5G核心网里，既没有2G/3G的电路域（CS Domain），也没有部署IMS。

短信往哪里送？

在4G时代，这个问题有两个标准答案：

方案 传输通道 依赖什么
SMS over SGs MME → MSC（经SGs接口） 需要2G/3G电路域的MSC
SMS over IP UE → IMS（经SIP MESSAGE） 需要IMS核心网

问题在于，5G SA核心网里既没有MME，也没有SGs接口。如果还想用SMS over SGs，就得回退到4G EPS，走EPS Fallback的思路——这太重了。如果走SMS over IP，就得部署全套IMS——很多小运营商觉得为了一个短信不值得。

于是3GPP在Release 15中给出了一个优雅的答案：SMS over NAS——把短信塞进NAS信令里，让AMF当"快递中转站"，再加一个新的网元SMSF来处理短信逻辑。

一个生活类比

理解SMS over NAS的最佳类比就是寄信时顺便托人带个口信：

二、架构全景：SMS over NAS的网络拓扑

2.1 参考架构

graph LR
    UE[📱 UE] -->|N1 NAS信令| AMF[AMF<br/>接入管理]
    AMF -->|N20 SMS信令| SMSF[SMSF<br/>短消息功能]
    SMSF -->|MAP/Diameter| SMSC[SMSC<br/>短信中心]
    SMSC -->|MAP| GMSC[SMS-GMSC<br/>短信网关]

    UDM[UDM<br/>用户数据] -.->|Nudm_SDM<br/>签约查询| AMF
    UDM -.->|Nudm_SDM<br/>短信路由| SMSF

    style SMSF fill:#ff9900,stroke:#333,color:#000
    style AMF fill:#4488ff,stroke:#333,color:#fff
    style UE fill:#44bb44,stroke:#333,color:#fff

在这个架构中，有几个关键角色：

网元 在SMS中的角色 类比
UE 短信的发送方/接收方 寄件人/收件人
AMF NAS信令锚点，转发SMS Payload 邮递员（不拆信，只转交）
SMSF 5GC新增网元，处理SMS逻辑 口信处理员
SMSC 传统短信中心，存储转发 邮局总局
UDM 存储SMS签约和路由信息 户口本

2.2 SMSF：5GC为短信量身打造的新网元

SMSF是5GC中唯一一个专门为SMS服务新定义的网元。它的核心能力包括：

  1. 签约校验：向UDM查询用户是否签约了NAS SMS服务
  2. 路由转换：把5G NAS格式的SMS转换为传统MAP/Diameter格式
  3. 计费采集：生成SMS CDR（Call Detail Record）
  4. 与SMSC对接：通过MAP或Diameter接口与现网SMSC互通
graph TB
    subgraph SMSF内部结构
        direction TB
        A[N20接口处理<br/>与AMF交互] --> B[SMS业务逻辑<br/>鉴权/路由/计费]
        B --> C[MAP/Diameter接口<br/>与SMSC交互]
        D[UDM接口<br/>签约查询] --> B
    end

    style A fill:#4488ff,color:#fff
    style B fill:#ff9900,color:#000
    style C fill:#44bb44,color:#fff
    style D fill:#9966cc,color:#fff

为什么需要SMSF，而不是让AMF直接处理？

这是典型的"单一职责"设计原则。AMF的核心职责是接入和移动性管理——注册、切换、寻呼，已经够复杂了。把SMS的处理逻辑（路由、格式转换、计费）独立出来给SMSF，既让AMF保持简洁，又让SMS的逻辑可以独立演进和扩展。

三、协议栈：短信如何在NAS中"搭便车"

3.1 协议层叠结构

理解SMS over NAS的关键在于理解协议栈的嵌套关系。下面从上到下逐层拆解：

┌──────────────────────────────────┐
│         用户短信内容               │  ← "你好，今晚7点吃饭"
├──────────────────────────────────┤
│         TPDU (SMS-SUBMIT)        │  ← 短信传输层协议数据单元
├──────────────────────────────────┤
│         RP-DATA (MO)             │  ← 中继协议：UE ↔ SMSF
├──────────────────────────────────┤
│    NAS Transport (UL/DL)         │  ← NAS传输容器
├──────────────────────────────────┤
│         5GS NAS信令               │  ← NAS安全层（加密+完整性）
├──────────────────────────────────┤
│         RRC信令                   │  ← 无线资源控制
├──────────────────────────────────┤
│         L2 / L1                  │  ← 物理层传输
└──────────────────────────────────┘

这里有一个非常巧妙的设计：RP协议（Relay Protocol）被原封不动地保留了下来。RP协议从2G时代就在用，负责在终端和短信中心之间建立逻辑连接。5G所做的只是换了一个"运输工具"——从2G的DTAP信道、4G的SGsAP隧道，变成了5G的NAS Transport容器。

RP协议本身只有4种消息类型：

RP消息 方向 用途
RP-DATA (MO) UE → SMSF 移动台发起的短信
RP-DATA (MT) SMSF → UE 移动台终止的短信
RP-ACK 双向 确认收到
RP-ERROR 双向 传输失败

3.2 NAS Transport消息：关键的"快递箱"

NAS Transport是5G NAS中一个通用容器消息，它本身只做一件事：把上层协议的Payload从一个地方搬到另一个地方。SMS over NAS利用的就是这个搬运能力。

NAS Transport消息中的关键字段：

字段 说明
Payload Container Type 指示装的是什么（SMS = "5GS SMS"）
Payload Container 实际内容（RP消息）
Additional Information 路由辅助信息
PDU Session ID 可选，关联的会话（SMS不用）

四、完整信令流程：从发短信到对方收到

4.1 注册阶段：先"报名"

SMS over NAS的前提是UE和网络都支持这个能力，且用户有签约。这个信息在注册流程中交换。

sequenceDiagram
    participant UE as UE
    participant AMF as AMF
    participant UDM as UDM
    participant SMSF as SMSF

    UE->>AMF: Registration Request<br/>（含 "5GS NAS SMS supported" 指示）
    AMF->>UDM: Nudm_SDM_Get（查询SMS签约数据）
    UDM-->>AMF: 返回 SMS Subscription Data
    AMF->>SMSF: Nsmsf_SMService_Activate<br/>（激活该用户的SMS服务）
    SMSF-->>AMF: Activate Response
    AMF-->>UE: Registration Accept<br/>（含 "NAS SMS allowed" 指示）

几个关键点：

  1. UE发起：UE在Registration Request中通过"5GS NAS SMS supported"指示告诉AMF"我支持NAS短信"
  2. AMF查签约：AMF向UDM查用户是否签约了SMS over NAS
  3. AMF选SMSF：AMF根据配置或DNS查询选择合适的SMSF
  4. 激活SMS服务：AMF向选定的SMSF发起Activate，告知"这个用户现在在我的管辖下"
  5. 应答UE：Registration Accept中携带"NAS SMS allowed"指示

如果没有签约NAS SMS会怎样？

AMF在Registration Accept中不会包含SMS指示，后续UE发短信时就不能走NAS通道，只能尝试其他方式（如SMS over IP / IMS）。

4.2 MO-SMS（手机发短信）

sequenceDiagram
    participant UE as 📱 UE
    participant RAN as 📡 gNB
    participant AMF as 🔵 AMF
    participant SMSF as 🟠 SMSF
    participant SMSC as 📮 SMSC

    Note over UE: 用户点击"发送"

    UE->>RAN: RRC UL Information Transfer
    Note right of UE: NAS Transport(UL)<br/>Payload = RP-DATA(MO)<br/>内含 SMS-SUBMIT TPDU

    RAN->>AMF: N2 Uplink NAS Transport

    AMF->>SMSF: N20 SMS Submit Request
    Note right of AMF: 转发RP-DATA<br/>带上SUPI等用户标识

    SMSF->>SMSF: 验证签约<br/>检查发送权限

    SMSF->>SMSC: MAP_forwardSM<br/>（或Diameter等价消息）

    SMSC-->>SMSF: MAP_forwardSM ACK
    Note right of SMSC: SMSC已存储短信<br/>等待投递给接收方

    SMSF-->>AMF: N20 SMS Submit Report

    AMF->>RAN: N2 Downlink NAS Transport

    RAN-->>UE: RRC DL Information Transfer
    Note left of UE: NAS Transport(DL)<br/>Payload = RP-ACK(MO)

    Note over UE: 显示"已发送"✅

关键时序解读：

4.3 MT-SMS（手机收短信）

接收短信的流程稍微复杂一些，因为手机可能在空闲态（CM-IDLE），需要先唤醒。

sequenceDiagram
    participant SMSC as 📮 SMSC
    participant SMSF as 🟠 SMSF
    participant AMF as 🔵 AMF
    participant RAN as 📡 gNB
    participant UE as 📱 UE

    Note over SMSC: 收到发给某用户的短信

    SMSC->>SMSF: MAP_deliverSM<br/>（通过SMS-GMSC路由）

    SMSF->>AMF: N20 SMS Deliver Request
    Note right of SMSF: 通过N1N2 Message Transfer<br/>请求AMF投递给UE

    alt UE在CM-IDLE状态
        AMF->>RAN: Paging（寻呼）
        RAN->>UE: 寻呼消息
        UE->>RAN: Service Request
        RAN->>AMF: N2 Initial UE Message
        Note right of AMF: UE进入CM-CONNECTED
    end

    AMF->>RAN: N2 Downlink NAS Transport
    Note right of AMF: NAS Transport(DL)<br/>Payload = RP-DATA(MT)<br/>内含 SMS-DELIVER TPDU

    RAN-->>UE: RRC DL Information Transfer

    Note over UE: 显示新短信通知 📩

    UE->>RAN: RRC UL Information Transfer
    Note right of UE: NAS Transport(UL)<br/>Payload = RP-ACK(MT)

    RAN->>AMF: N2 Uplink NAS Transport

    AMF-->>SMSF: N20 SMS Deliver Report

    SMSF-->>SMSC: MAP_deliverSM Response

空闲态接收短信的代价：

当UE处于CM-IDLE状态时，AMF必须先发起寻呼，让UE回到CM-CONNECTED状态才能投递NAS消息。这意味着收短信会触发一次寻呼+Service Request的完整流程。这在空口上增加了一些时延，但对于短信这种低频业务来说完全可以接受。

五、三种短信方案的深度对比

5.1 全景对比表

维度 SMS over NAS (5G) SMS over SGs (4G) SMS over IP (IMS)
传输层 NAS信令面 CS域信令面（经SGs） SIP over IP
需要IMS ❌ ❌ ✅
需要CS域 ❌ ✅（MSC） ❌
需要SMSF ✅ ❌ ❌
延迟 低（纯信令） 中（可能涉及回落） 依赖IP传输质量
可靠性 高（NAS安全保护） 高（CS域成熟） 依赖IMS注册状态
5G SA支持 ✅ 原生支持 ❌ 不支持 ✅ 通过IMS
适用场景 5G SA运营商 4G+2G/3G运营商 已部署IMS的运营商
对终端要求 支持5G NAS SMS 支持CSFB 支持IMS SMS
与语音耦合 无 与CSFB绑定 与VoLTE/VoNR绑定

5.2 为什么5G SA需要SMS over NAS？

一个常见的疑问是：都2026年了，谁还用短信？

答案比想象中重要得多：

  1. 验证码：银行、社交媒体、各类App广泛使用短信验证码。这是两步验证（2FA）的基石，短期内不会消失。
  2. 应急通知：地震预警、运营商通知等，短信是最可靠的广播手段。
  3. 物联网设备：很多IoT设备需要通过短信进行配置管理（如远程下发APN参数）。
  4. VoNR未普及：很多运营商的5G SA网络还未部署IMS，SMS over NAS是唯一的选择。
  5. 互联互通：短信可以跨运营商、跨国传递，这是OTT消息应用做不到的。

六、安全机制：NAS信令如何保护短信

SMS over NAS继承了5G NAS的完整安全体系：

安全特性 说明
加密 NAS消息体使用AES或SNOW 3G加密，短信内容在空口不可窥探
完整性保护 每条NAS消息附带MAC校验，防止篡改
防重放 NAS安全上下文中的计数器防止消息被重放
用户隐私 SUPI在空口被加密为SUCI，保护用户身份

这一点比传统的SMS over SGs要强得多——2G/3G的A5/1加密早就被证明不安全，而5G NAS加密是现代密码学级别的保护。

七、实战视角：工程师如何用这些知识

7.1 抓包定位SMS问题

当用户报告"发不出短信"时，典型的排查思路：

第一步：检查注册流程

在AMF侧查看Registration Accept消息，确认是否包含"NAS SMS allowed"指示。如果没有，问题出在签约或SMSF选择上。

第二步：检查MO-SMS流程

用Wireshark或tcpdump在N20接口抓包，看AMF是否向SMSF发送了N20 SMS Submit Request。如果AMF发出了但SMSF没有应答，说明SMSF有问题（可能是与SMSC的接口故障）。

第三步：检查MT-SMS流程

如果用户收不到短信，检查SMSF是否向AMF发送了N20 SMS Deliver Request。如果SMSF没发，问题可能在SMSC到SMSF之间。

7.2 常见故障模式

故障现象 可能原因 排查点
发送失败，UE收到RP-ERROR 用户未签约SMS over NAS UDM签约数据
发送无响应（超时） SMSF不可达或SMSC接口故障 N20接口抓包
能发不能收 SMSF未向AMF激活该用户 检查Activate流程
收短信触发回落到4G 终端不支持SMS over NAS 终端能力检查
短信内容乱码 编码协商失败 TPDU中的DCS字段

7.3 一个典型的调试陷阱

陷阱：UE显示"已发送"但对方没收到。

很多工程师看到UE收到RP-ACK就认为短信已经成功送达了——实际上RP-ACK只意味着SMSC收到了这条短信，不代表接收方已经收到。SMSC收到后会尝试投递给接收方，如果接收方关机，SMSC会暂存并在用户开机后重试。所以"已发送"的准确含义是"SMSC已入库"，而不是"对方已阅"。

八、设计哲学：为什么选NAS信令而不是新开一条通道？

回顾整个SMS over NAS的设计，有几个深层次的"为什么"值得思考：

为什么不新建一个SMS专用的无线承载？

因为短信的数据量极小（一条SMS最多140字节），为它专门建立一个无线承载（DRB）太浪费了。NAS信令连接本来就在，搭个便车最经济。

为什么不用PDU Session传短信（像上网数据一样）？

PDU Session需要先建立会话、分配IP地址、建立GTP隧道——整个流程至少增加5-6条信令。对于140字节的短信来说，这个开销完全不合理。而且，有些物联网终端根本没有PDU Session，但需要收短信（比如远程配置）。

为什么需要SMSF这个新网元？

因为AMF和SMSC之间说着不同的"语言"——AMF只懂5G NAS和SBI（Service Based Interface），SMSC只懂MAP/Diameter。需要一个"翻译官"在中间做协议转换。把翻译功能独立为SMSF，遵循了5GC的服务化架构（SBA）理念——每个NF只做一件事，做好一件事。

常见问题

Q1: SMS over NAS和SMS over IP可以同时使用吗？

A: 可以共存但不能同时用于同一条短信。终端可以同时注册IMS（用于语音和SMS over IP）和NAS SMS。通常运营商配置优先级——如果IMS可用，优先走SMS over IP（因为它走用户面，对信令面负载更小）；如果IMS不可用，回退到SMS over NAS。这种"双保险"机制提高了短信的可靠性。

Q2: SMS over NAS支持短信Concatenation（长短信拼接）吗？

A: 支持。长短信在TPDU层被分割成多个片段（使用UDH中的Concatenation IE），每个片段独立通过RP-DATA和NAS Transport传输。接收端在TPDU层完成重组。这个过程对NAS层完全透明——NAS只管搬运，不管内容。

Q3: 5G NSA（非独立组网）能用SMS over NAS吗？

A: 5G NSA（Option 3/3a/3x）的UE注册在EPC中，由MME管理，因此使用的是4G的SMS方案（SMS over SGs或SMS over IP）。只有5G SA（Stand Alone）的UE注册在5GC中，由AMF管理，才能使用SMS over NAS。这是NSA和SA的一个重要区别。

Q4: SMSF是必选网元吗？运营商不部署SMSF会怎样？

A: SMSF只在运营商提供SMS over NAS服务时才需要。如果运营商只提供SMS over IP（通过IMS），则不需要部署SMSF。但如果运营商有5G SA网络且需要提供短信服务（验证码、应急通知等），就必须部署SMSF或等效的解决方案。

Q5: SMS over NAS的时延大概是多少？

A: 典型的端到端时延在1-3秒范围内（UE发出到对端UE收到RP-ACK确认）。其中NAS信令传输约100-300ms，SMSF处理约100-200ms，SMSC存储转发约500ms-1s，寻呼唤醒（如果接收方空闲态）约200-500ms。相比SMS over SGs（可能涉及回落时延），NAS方式更快更稳定。

参考来源

  1. Two Types of SMS in 5G - 3G4G Blog — 5G中两种短信方案的对比分析
  2. SMS Overview in 5G Network - Moniem-Tech — 5G网络短信架构全景介绍
  3. SMS in 5GC - Nick vs Networking — 5GC中SMS的Nsmsf服务接口详解
  4. 5G核心网NAS短消息的实现 - CSDN — NAS短消息流程的中文技术解析
  5. Nokia Short Message Service Function — Nokia SMSF产品说明与架构参考

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章