<!-- title: 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的最佳类比就是**寄信时顺便托人带个口信**：

- 你和AMF之间本来就有一条NAS信令通道（就像你每天和邮递员见面）
- 现在你在信封里夹一张小纸条（SMS Payload），让邮递员帮你转交
- 邮递员（AMF）不拆信，只是把纸条转给专门处理口信的办事员（SMSF）
- 办事员（SMSF）再通过传统渠道把口信送到对方城市

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

### 2.1 参考架构

```mermaid
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互通

```mermaid
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和网络都支持这个能力，且用户有签约。这个信息在**注册流程**中交换。

```mermaid
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（手机发短信）

```mermaid
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: 显示"已发送"✅
```

**关键时序解读**：

- **步骤1-2**：UE构造RP-DATA消息（内含实际的短信内容），把它放进NAS Transport容器中，通过RRC发给gNB，gNB转发给AMF。AMF是NAS信令的终点——它拆开NAS外层，看到里面的RP-DATA，知道这是一条短信。
  
- **步骤3**：AMF通过N20接口（即Nsmsf_SMService_Uplink）把RP-DATA转发给SMSF。**AMF完全不解析RP消息内容**，它只是一个忠实的搬运工。

- **步骤4-5**：SMSF做两件事——先验证用户有没有权限发短信（查签约数据），然后把RP-DATA转换成传统MAP/Diameter格式发给SMSC。这一步是**协议转换的关键点**。

- **步骤6-8**：SMSC确认后，确认消息原路返回，最终UE收到RP-ACK，显示"已发送"。

### 4.3 MT-SMS（手机收短信）

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

```mermaid
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](https://blog.3g4g.co.uk/2020/09/two-types-of-sms-in-5g.html) — 5G中两种短信方案的对比分析
2. [SMS Overview in 5G Network - Moniem-Tech](https://moniem-tech.com/2024/10/27/sms-overview-in-5g-network/) — 5G网络短信架构全景介绍
3. [SMS in 5GC - Nick vs Networking](https://nickvsnetworking.com/sms-in-5gc/) — 5GC中SMS的Nsmsf服务接口详解
4. [5G核心网NAS短消息的实现 - CSDN](https://blog.csdn.net/gou12341234/article/details/148792244) — NAS短消息流程的中文技术解析
5. [Nokia Short Message Service Function](https://www.nokia.com/core-networks/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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)