在4G LTE时代,短信可以通过CSFB回落到2G/3G电路域,或通过IMS(VoLTE)的SIP MESSAGE承载。但5G NR standalone部署场景下,既没有电路域可回落,也不一定部署了IMS。这就催生了SMS over NAS——一种纯控制面短信传输机制,仅依赖NAS信令连接即可完成收发,无需建立任何PDU会话。
3GPP在TS 23.501 Section 5.4中定义了SMSF(Short Message Service Function)这一新的网络功能,专门负责5G核心网中短信的路由、协议转换和订阅校验。SMSF通过SBI(Service-Based Interface)与AMF、UDM交互,同时通过MAP/Diameter与Legacy SMSC对接,构成了5G短信的完整控制面路径。
核心价值:运营商无需部署IMS即可在5G SA网络中提供短信服务,降低VoNR部署前的网络依赖。但代价是引入了SMSF这一额外网元和N20/N21两条新接口。
graph TB
UE[UE] -->|N1 NAS Transport| AMF[AMF]
AMF -->|Nsmsf_SMService<br/>N20/N21 SBI| SMSF[SMSF]
SMSF -->|Nudm_SDM<br/>Nudm_UECM| UDM[UDM]
SMSF -->|MAP/Diameter<br/>SGd/C| SMSC[SMSC]
SMSC --> SMS_GMSC[SMS-GMSC]
SMSC --> SMS_IWMSC[SMS-IWMSC]
style UE fill:#e1f5fe
style AMF fill:#fff3e0
style SMSF fill:#e8f5e9
style UDM fill:#fce4ec
style SMSC fill:#f3e5f5
关键接口定义(TS 23.501 Section 6.2.6 / TS 29.540):
| 接口 | 参考点 | 协议 | 功能 |
|---|---|---|---|
| AMF↔UE | N1 | NAS (TS 24.501) | 承载SMS的NAS Transport消息 |
| AMF↔SMSF | N20/N21 | HTTP/2 SBI | SMS激活/去激活/上下行短信传递 |
| SMSF↔UDM | N21 | HTTP/2 SBI | 订阅数据获取、SMSF地址注册 |
| SMSF↔SMSC | SGd/Map | MAP或Diameter | 与Legacy短信基础设施互通 |
SMS over NAS的完整生命周期分为三个阶段,每个阶段都有独立的信令流程和定时器约束:
stateDiagram-v2
[*] --> SMS_Registration: UE发起5G注册
SMS_Registration --> MO_SMS: UE发送上行短信
SMS_Registration --> MT_SMS: 网络下发下行短信
MO_SMS --> MO_SMS_Complete: RP-ACK确认
MT_SMS --> MT_SMS_Complete: RP-ACK确认
MO_SMS_Complete --> MO_SMS: 继续发送
MT_SMS_Complete --> MT_SMS: 继续接收
MO_SMS --> SMS_Deregistration: 去注册
MT_SMS --> SMS_Deregistration: 去注册
SMS_Deregistration --> [*]
note right of SMS_Registration
TS 23.502 Section 4.13.3.1
AMF选择SMSF并激活
end note
note right of MO_SMS
TS 23.502 Section 4.13.3.2
NAS Transport + CP/RP封装
end note
note right of MT_SMS
TS 23.502 Section 4.13.3.3
可能触发Paging
end note
SMS over NAS的激活并非独立过程,而是嵌入在5G Registration流程中。UE在Registration Request中通过5GS registration type IE指示支持SMS over NAS能力,AMF在完成通用注册后,额外执行SMS注册子流程。
sequenceDiagram
participant UE
participant RAN as gNB
participant AMF
participant UDM
participant SMSF
participant NRF
UE->>RAN: Registration Request<br/>(SMS supported indication)
RAN->>AMF: N2 Initial UE Message<br/>+ Registration Request
AMF->>AMF: 检查UE SMS能力指示
Note over AMF: 主注册流程(AUSF认证等)<br/>此处省略...
AMF->>UDM: Nudm_SDM_Get<br/>(Subscription Data)
UDM-->>AMF: SMS Subscription + SMSF Address
alt SMSF Address在订阅数据中
AMF->>AMF: 使用UDM返回的SMSF地址
else SMSF Address不在订阅数据中
AMF->>NRF: NF Discovery<br/>(nf-type=SMSF, PLMN)
NRF-->>AMF: SMSF实例列表
AMF->>AMF: 按拓扑/负载选择SMSF
end
AMF->>SMSF: Nsmsf_SMService_Activate<br/>(SUPI, Access Type, AMF Address)
SMSF->>UDM: Nudm_UECM_Registration<br/>(SMSF ID, SUPI)
UDM-->>SMSF: 200 OK
SMSF->>UDM: Nudm_SDM_Get<br/>(SMS Subscription Data)
UDM-->>SMSF: SMS Subscription Info
SMSF-->>AMF: 201 Created<br/>(smsfContextId)
AMF->>RAN: N2 Registration Accept<br/>+ NAS Registration Accept
RAN->>UE: Registration Accept<br/>(SMS allowed indication)
Registration Request中的SMS指示(TS 24.501 Section 8.2.6):
| IE名称 | 长度 | 编码值 | 含义 |
|---|---|---|---|
| 5GS registration type | 4 bits | bit 3=1 | SMS over NAS支持指示 |
| SMS supported indication | 1 octet | 0/1 | UE是否支持NAS短信 |
| Network slicing indication | - | - | 可能影响SMSF选择 |
Nsmsf_SMService_Activate请求体(TS 29.540 Section 5.1.2.2.1):
{
"supi": "imsi-460001234567890",
"gpsi": "msisdn-8613800138000",
"accessType": "3GPP_ACCESS",
"pei": "imei-460012345678901",
"smsfId": "smsf-5gc.mnc060.mcc460.3gppnetwork.org",
"amfId": "amf-5gc.mnc060.mcc460.3gppnetwork.org",
"guami": {
"plmnId": {"mcc": "460", "mnc": "06"},
"amfId": "80:00:01"
}
}
SMSF选择存在两种路径,这直接影响运营商的部署成本和信令开销:
| 选择方式 | 触发条件 | 优势 | 劣势 |
|---|---|---|---|
| UDM静态配置 | 订阅数据中包含SMSF地址 | 信令少、确定性高 | 不支持负载均衡、单点风险 |
| NRF动态发现 | 订阅数据中无SMSF地址 | 支持负载均衡、弹性扩展 | 额外NRF查询开销、延迟增加 |
运营商博弈点:小规模部署倾向UDM静态配置(运维简单),大规模部署需要NRF动态发现(支持多SMSF实例)。但NRF发现引入的额外RTT(约10-20ms)在高并发短信场景下会累积成显著延迟。
5G NAS短信的消息封装是三层嵌套结构,理解这个层次对抓包分析至关重要:
graph TD
A["NAS Transport Message<br/>(Uplink NAS Transport)"] --> B["Payload Container Type = 1 (SMS)"]
A --> C["Payload Container"]
C --> D["CP-DATA<br/>(TS 24.011 CP Layer)"]
D --> E["RP-DATA (MO)<br/>(TS 24.011 RP Layer)"]
E --> F["SMS-SUBMIT TPDU<br/>(TS 23.040)"]
F --> G["User Data<br/>(TS 23.038 编码)"]
style A fill:#e3f2fd
style D fill:#fff8e1
style E fill:#e8f5e9
style F fill:#fce4ec
sequenceDiagram
participant UE
participant RAN as gNB
participant AMF
participant SMSF
participant UDM
participant SMSC
rect rgb(240, 248, 255)
Note over UE,SMSC: 阶段A: UE → AMF (NAS层)
UE->>RAN: Uplink NAS Transport<br/>Payload Container Type=1(SMS)
Note right of UE: CP-DATA(RP-DATA)<br/>含SMS-SUBMIT TPDU
RAN->>AMF: N2 Uplink NAS Transport<br/>+ NAS PDU
end
rect rgb(255, 248, 240)
Note over AMF,SMSC: 阶段B: AMF → SMSF (SBI层)
AMF->>AMF: 查找UE SMS上下文<br/>获取smsfContextId
AMF->>SMSF: Nsmsf_SMService_UplinkSMS<br/>(smsfContextId, payloadContainer)
Note right of AMF: PUT /nsmsf-sms/v1/<br/>{smsfContextId}/uplink-sms
end
rect rgb(240, 255, 240)
Note over SMSF,SMSC: 阶段C: SMSF → SMSC (Legacy层)
SMSF->>SMSF: 验证SMS订阅状态<br/>解析RP-DATA提取TPDU
SMSF->>SMSC: MAP_FORWARD_SHORT_MSG<br/>或 Diameter MO-ForwardSMS
SMSC-->>SMSF: MAP_FORWARD_SHORT_MSG-ACK
end
rect rgb(255, 240, 245)
Note over UE,SMSC: 阶段D: 确认回传
SMSF-->>AMF: 200 OK<br/>(RP-ACK payload)
AMF->>RAN: N2 Downlink NAS Transport
RAN->>UE: Downlink NAS Transport<br/>CP-DATA(RP-ACK)
UE->>RAN: CP-ACK
RAN->>AMF: CP-ACK (NAS层确认)
end
Uplink NAS Transport消息结构(TS 24.501 Section 8.2.10):
| IE | 类型 | 长度 | 说明 |
|---|---|---|---|
| Extended protocol discriminator | Mandatory | 1 octet | 值=0x7E(5GS Mobility Management) |
| Security header type | Mandatory | 1 octet | 0=无保护, 1-3=完整性保护 |
| Spare half octet | Mandatory | 4 bits | 填充 |
| Uplink NAS Transport message identity | Mandatory | 1 octet | 消息类型=0x67 |
| Payload container type | Mandatory | 1 octet | 值=01h(SMS) |
| Payload container | Mandatory | 变长 | 包含CP-DATA |
| PDU session identity | Optional | 2 octets | SMS场景不使用 |
| Additional information | Optional | 变长 | 故障诊断信息 |
| 5GMM cause | Optional | 2 octets | 失败时携带原因值 |
RP-DATA (MO)关键字段(TS 24.011 Section 7.3.1):
| 字段 | 长度 | 说明 |
|---|---|---|
| Message Type | 1 octet | RP-DATA (MO) = 0x00 |
| Message Reference | 1 octet | UE分配的本地参考号(0-255循环) |
| RP-Originator Address | 变长 | 通常为空(SMSC已知UE地址) |
| RP-Destination Address | 变长 | 目标SMSC地址 |
| User Data | 变长 | 包含SMS-SUBMIT TPDU |
MO SMS过程中存在多层定时器嵌套,任何一个超时都会触发不同的回退策略:
| 定时器 | 协议层 | 取值范围 | 超时动作 |
|---|---|---|---|
| TR1M | CP层(TS 24.011) | 5.5-18秒 | 重发CP-DATA,最多重试3次 |
| TR2M | RP层(TS 24.011) | 12-36秒 | RP层错误报告 |
| T35xx | NAS层(TS 24.501) | 5-10秒 | NAS层传输失败通知 |
| SMSF内部 | SMSF实现 | 实现相关 | MAP/Diameter重试 |
博弈分析:TR1M必须小于TR2M,因为CP层重试必须在RP层超时之前完成。如果TR1M设置过短(如5.5秒),在AMF-SMSF接口延迟较高时会频繁触发无效重试;设置过长(18秒)则用户体验差。典型的运营商配置为TR1M=10秒,TR2M=30秒。
MT SMS比MO SMS复杂得多,因为需要处理UE处于CM-IDLE和CM-CONNECTED两种状态的不同路径:
sequenceDiagram
participant SMSC
participant SMS_GMSC as SMS-GMSC
participant UDM
participant SMSF
participant AMF
participant RAN as gNB
participant UE
rect rgb(255, 248, 240)
Note over SMSC,UDM: 路由解析阶段
SMSC->>SMS_GMSC: SMS-DELIVER
SMS_GMSC->>UDM: Nudm_SDM_Get<br/>(SMS Routing Info)
UDM-->>SMS_GMSC: SMSF Address + SUPI
SMS_GMSC->>SMSF: Forward MO-SMS<br/>(MAP/Diameter)
end
rect rgb(240, 248, 255)
Note over SMSF,UE: SMSF → AMF → UE
SMSF->>AMF: Namf_Communication<br/>_N1N2MessageTransfer<br/>(N1 SM Container = CP-DATA)
alt UE处于CM-CONNECTED
AMF->>RAN: N2 Downlink NAS Transport
RAN->>UE: Downlink NAS Transport<br/>(CP-DATA/RP-DATA)
else UE处于CM-IDLE
AMF->>RAN: N2 Paging<br/>(NAS SMS指示)
RAN->>UE: Paging
UE->>RAN: Service Request
RAN->>AMF: N2 Initial UE Message
AMF->>RAN: N2 Downlink NAS Transport
RAN->>UE: Downlink NAS Transport
end
end
rect rgb(240, 255, 240)
Note over UE,SMSC: 确认回传
UE->>RAN: Uplink NAS Transport<br/>(CP-DATA/RP-ACK)
RAN->>AMF: N2 Uplink NAS Transport
AMF->>SMSF: Nsmsf_SMService<br/>_UplinkSMS (RP-ACK)
SMSF->>SMSC: RP-ACK/ACK
end
当UE处于CM-IDLE状态时,MT SMS需要先通过Paging唤醒UE。这里存在一个关键的定时器博弈:
SMSF发送短信给AMF时,AMF需要决定是否立即发起Paging。如果UE长时间未响应Paging,SMS报文会在AMF中积压。3GPP定义了以下机制:
| 场景 | AMF行为 | 定时器约束 |
|---|---|---|
| UE在Paging后5秒内响应 | 正常下发MT SMS | 无额外约束 |
| UE未响应Paging | AMF通知SMSF下发失败 | 基于NAS定时器 |
| UE漫游到非3GPP接入 | 通过N3IWF尝试 | 需要SMS over NAS在非3GPP接入上激活 |
SMSF需要同时支持MAP和Diameter两种协议与SMSC互通(TS 29.540 Section 6):
| 协议 | 接口 | 适用场景 | 关键操作 |
|---|---|---|---|
| MAP | SGd | 传统2G/3G SMSC | MO-ForwardSM, MT-ForwardSM, ReportSM-DeliveryStatus |
| Diameter | SGd | 4G/5G SMSC | MO-ForwardSMS-Request, MT-ForwardSMS-Request |
| CAP | 无直接接口 | 智能短信业务 | 需经SMS Router中转 |
协议转换是SMSF的核心价值:将5G SBI(HTTP/2 JSON)与Legacy SS7/Diameter协议无缝对接,让运营商无需升级现有SMSC基础设施。
SMS去注册(TS 23.502 Section 4.13.3.1.4)在以下场景触发:
sequenceDiagram
participant Old_AMF as Old AMF
participant New_AMF as New AMF
participant SMSF
participant UDM
Note over Old_AMF: UE触发注册<br/>AMF变更
Old_AMF->>New_AMF: Namf_Communication<br/>_TransferMoData<br/>(UE Context + SMS Context)
New_AMF->>SMSF: Nsmsf_SMService_Activate<br/>(新AMF地址)
SMSF->>UDM: Nudm_UECM_Registration<br/>(更新AMF地址)
UDM-->>SMSF: 200 OK
SMSF-->>New_AMF: 201 Created
New_AMF->>Old_AMF: 通知旧AMF<br/>释放UE上下文
Old_AMF->>SMSF: Nsmsf_SMService_Deactivate<br/>(旧AMF关联)
博弈分析:AMF变更期间存在一个时间窗口,SMSF可能同时收到来自Old AMF和New AMF的请求。3GPP通过Nudm_UECM_Registration中的AMF地址更新来保证一致性——SMSF始终使用UDM中最新注册的AMF地址来下发MT SMS。
Nsmsf_SMService是SMSF暴露的核心SBI服务,包含四个服务操作:
| 操作 | HTTP方法 | URI模板 | 调用方 | 触发场景 |
|---|---|---|---|---|
| Activate | POST | /nsmsf-sms/v1/{ueId}/activate |
AMF | SMS Registration |
| Deactivate | POST | /nsmsf-sms/v1/{ueId}/deactivate |
AMF | SMS Deregistration |
| UplinkSMS | PUT | /nsmsf-sms/v1/{ueId}/uplink-sms |
AMF | MO SMS |
| DownlinkSMS | 由AMF暴露 | Namf服务 | SMSF | MT SMS |
注意:DownlinkSMS并非SMSF暴露的操作,而是SMSF调用AMF的Namf_Communication_N1N2MessageTransfer服务来下发短信。这是一个容易混淆的架构点——MT SMS的方向是SMSF→AMF→UE,但使用的是AMF暴露的接口。
{
"smsPayload": {
"payloadContainerType": "SMS",
"payloadContainer": "0x01...(hex encoded CP-DATA/RP-DATA)"
},
"accessType": "3GPP_ACCESS",
"additionalAccessInfo": {
"anNodeType": "GNB",
"anNodeAddress": "192.168.1.100"
}
}
| 检查点 | 工具 | 关键过滤条件 |
|---|---|---|
| NAS层SMS | Wireshark | nas-5gs.message_type == 0x67 (Uplink NAS Transport) |
| SBI层Activate | tcpdump | http2.headers.path contains "nsmsf-sms" |
| SBI层UplinkSMS | tcpdump | http.request.method == "PUT" && http2.headers.path contains "uplink" |
| MAP层 | Wireshark | tcap.dialogue_id && map.operationCode == 46 (MO-ForwardSM) |
| 故障现象 | 可能原因 | 排查步骤 |
|---|---|---|
| Registration Accept中无SMS指示 | UDM未配置SMS订阅 | 检查Nudm_SDM_Get响应中的smsManagementData |
| MO SMS卡在AMF | AMF未选择SMSF或Activate失败 | 检查AMF日志中NRF Discovery结果 |
| MO SMS发出但无RP-ACK | SMSF-SMSC MAP链路故障 | 检查SMSF到SMSC的SCCP/M3UA连接 |
| MT SMS未触发Paging | SMSF未找到AMF地址 | 检查Nudm_UECM中AMF地址是否过期 |
| CP-DATA重传超过3次 | 空口质量差或NAS安全上下文异常 | 检查5GMM Cause值和Security Header |
| ## 十、安全考量 |
SMS over NAS消息受NAS安全机制保护(TS 33.501 Section 6.4):
| 安全特性 | 机制 | 说明 |
|---|---|---|
| 完整性保护 | 5G-IA算法 | NAS Transport消息必须完整性保护 |
| 加密保护 | 5G-EA算法 | 可选,取决于运营商策略 |
| CP层安全 | 无额外保护 | CP-DATA/RP-DATA依赖NAS层安全 |
| SBI安全 | TLS + OAuth2 | AMF-SMSF之间HTTP/2双向认证 |
根据ResearchGate上关于SMSF Legacy接口安全的研究论文,SMSF的MAP/Diameter接口存在以下攻击面:
防护建议:在SMSF与SMSC之间部署Diameter Firewall,对MAP接口实施信令防火墙过滤。
| 维度 | SMS over NAS | SMS over IP |
|---|---|---|
| 核心规范 | TS 23.502 Section 4.13.3 | TS 23.502 Section 4.13.4 |
| 承载网络 | NAS控制面信令 | IMS用户面(SIP MESSAGE) |
| 是否需要PDU会话 | 否 | 是(IMS APN) |
| 是否需要IMS | 否 | 是 |
| 是否需要SMSF | 是 | 否(IMS AS处理) |
| 短信编码 | TPDU (TS 23.040) | SIP MESSAGE + MSRP/RCS |
| 延迟 | 低(纯控制面) | 较高(需建立IMS会话) |
| 部署成本 | 需部署SMSF | 需部署IMS全套 |
| 适用场景 | 5G SA无IMS | 已部署VoNR/VoLTE |
Q1: SMS over NAS和SMS over IMS可以同时激活吗? A: 可以。TS 23.501 Section 5.4允许UE同时支持两种短信方案。网络侧通过Registration Accept中的SMS指示告知UE使用哪种方案优先。实际运营中,通常SMS over NAS作为IMS未部署时的兜底方案。
Q2: SMSF需要为每个UE维护独立的SMS上下文吗? A: 是的。SMSF通过Nsmsf_SMService_Activate为每个UE创建独立的SMS上下文(smsfContextId),并在Nudm_UECM中注册其关联关系。这个上下文在Deactivate之前一直有效。
Q3: 5G长短信(Concatenated SMS)如何在NAS上传输? A: 与传统SMS相同,长短信在发送端被拆分为多个SMS-SUBMIT TPDU,每个TPDU通过独立的NAS Transport消息传输。接收端根据TPDU中的UDH(User Data Header)进行重组。3GPP未对NAS短信的分段数量做特殊限制。
Q4: SMSF故障时已激活的SMS会话如何处理? A: AMF通过NRF监控SMSF实例的健康状态。如果SMSF故障,AMF在收到新的MO SMS时会触发NRF重新发现可用的SMSF实例并重新执行Activate。但正在进行中的MO/MT SMS会丢失,需要UE上层应用重发。
Q5: 非3GPP接入(WiFi)支持SMS over NAS吗? A: Release 16开始支持。UE通过N3IWF接入时,同样可以通过NAS Transport消息传输SMS。AMF在Activate时会记录access type,支持3GPP和非3GPP双接入的SMS同时激活。
本文由「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 等场景全覆盖。
