51学通信

深度解析 3GPP TS 23.540：5.1 MT SMS 流程 (Part 1 - 成功的消息投递)

20分钟阅读

好的，遵照您的指令，这是系列文章的第三篇，我们将正式进入规范的核心——第五章，从移动终止（MT）短信的成功流程开始，进行深度拆解。由于5.1章节内容非常详尽，我们将分部分进行解读。

深度解析 3GPP TS 23.540：5.1 MT SMS 流程 (Part 1 - 成功的消息投递)

本文技术原理深度参考了3GPP TS 23.540 V18.4.0 (2024-06) Release 18规范中，关于“5.1 Procedure for SBI-based MT SMS”的核心章节，重点聚焦于 5.1.1 General、5.1.2 Successful Mobile Terminated short message transfer without SMS Router/ IP-SM-GW 和 5.1.3 Successful Mobile Terminated short message transfer via SMS Router。本文旨在为读者详细拆解5G网络中最核心、最常见的两条“短信高速公路”——即移动终止（MT）短信的成功投递路径。

在前面的文章中，我们已经共同绘制了5G服务化短信的宏伟蓝图。我们认识了乐团的各位演奏家（NF），也明白了它们之间沟通的语言（SBI）和航线（参考点）。现在，是时候欣赏它们的第一场正式演出了——一次完美的短信投递。

今天的故事，从我们的主角小明一个忙碌的早晨开始。他将先后收到两条重要的信息：一条是来自气象台的今日天气提醒，另一条是来自银行的信用卡消费确认。这两条短信看似平常，但它们在5G核心网内所走的路径却不尽相同，恰好完美地诠释了本章要讲解的两个核心成功流程。

1. MT SMS 流程总览 (Section 5.1.1 General)

在进入具体的流程细节之前，5.1.1章节首先为我们阐明了整个MT SMS流程设计的基本原则和关键前提。

The procedure is used to support the Mobile Terminated short message transfer for SBI-based interfaces as defined in clause 4.1, which is based on Short message mobile terminated procedure defined in clause 10.1 of 3GPP TS 23.040 and clauses 4.13.3.6, 4.13.3.7 and 4.13.3.8 of 3GPP TS 23.502.

深度解读：

这段话开宗明义，指出了5G MT SMS的“血统”。它并非凭空创造，而是站在了巨人的肩膀上：

  1. 业务核心源于TS 23.040：短信的内容、格式和基本的成功/失败逻辑，依然遵循那本从GSM时代流传下来的“短信圣经”。

  2. 承载方式源于TS 23.502：短信在“最后一公里”如何通过NAS信令在AMF和UE之间传输，其底层机制完全复用了5G系统通用的下行数据传输流程。

TS 23.540的核心创新在于，如何用SBA的理念将这两者“粘合”起来。

SMSF/SMS Router/IP-SM-GW should indicate whether it supports SMS_SBI or not. … UDM stores the “SBI support indication” indication and provides it to the SMS-GMSC during Routing Info retrieval. SMS-GMSC selects legacy or SBI based protocol based on the indication received during Routing Info retrieval.

深度解读：

这是整个服务化短信流程得以启动的**“总开关”。这里引入了一个至关重要的概念——“SBI support indication”（SBI支持指示）**。

  • 场景化理解：您可以把它想象成小明在运营商那里的用户档案上，有一个特殊的标签。当SMSF、SMS Router等现代化的短信网元在网络中注册时，它们会告诉UDM：“我是新来的，支持全新的SBI快递协议”。UDM就会在它所服务的用户档案上（比如小明的档案）打上这个“支持SBI”的标签。

  • 决策点：当SMS-GMSC收到一条给小明的短信，前去UDM“问路”时，UDM不仅会告诉它下一步该找谁，还会附带上这个标签。SMS-GMSC看到“支持SBI”的标签，就知道应该启动接下来我们要讲的这套全新的、基于API调用的流程。如果没看到这个标签，它就会“心领神会”，转而使用传统的MAP/Diameter协议，走老路子。

这个机制确保了网络的平滑演进和向后兼容，是新旧两套系统能否和谐共存的关键。

2. 场景一：直达快递 - 无路由器的成功投递 (Section 5.1.2)

早晨7点，小明的手机“叮”地一声，收到一条来自气象台的天气预报。这是一个典型的、点对点的A2P（应用到个人）短信，它在网络中走的是最直接、最高效的路径。这完美对应了Section 5.1.2 Successful Mobile Terminated short message transfer without SMS Router/ IP-SM-GW所描述的流程。

我们来对照规范中的Figure 5.1.2-1: MT SMS over NAS without SMS Router/ IP-SM-GW，一步步追踪这条天气预报的旅程。

步骤 1 & 2: 消息抵达，开始问路

  1. MT SMS interaction between SC and SMS-GMSC follow the current procedure as defined in 3GPP TS 23.040.

2a. SMS-GMSC invokes the Nnrf_NFDiscovery to discover and select the UDM instance(s), supporting SMS SBI interfaces…

2b. If no UDM supporting SMS SBI could be discovered… SMS-GMSC shall quit the SBI-based procedure and fallback to legacy…

深度解读：

  1. （Step 1） 气象台的服务中心（SC）将短信发送到小明所在运营商的SMS-GMSC。这是旅程的起点。

  2. （Step 2a & 2b） SMS-GMSC作为“网关门卫”，手握小明的手机号，但它需要知道下一步该怎么走。它首先向网络的“114查号台”——NRF发起Nnrf_NFDiscovery服务调用，询问：“请给我找一个支持SBI短信业务的UDM”。如果NRF找不到这样的UDM，说明网络还不支持新流程，SMS-GMSC就会放弃并转用老办法（MAP/Diameter）。幸运的是，小明的5G网络很先进，NRF成功返回了一个可用的UDM地址。

步骤 3 & 4: 查询路由，获取指令

  1. SMS-GMSC invokes Nudm_UECM_SendRoutingInfoForSM (GPSI) to the UDM to get the routing information…
  1. The UDM shall check the registration/reachability flags… and responds to the SMS-GMSC… in this procedure the SMSF instance Id and the indication for SMSF SMS_SBI support are included in the response message.

深度解读：

  1. （Step 3） SMS-GMSC拿到了UDM的地址，立刻发起Nudm_UECM_SendRoutingInfoForSM服务调用，正式向“用户档案库”——UDM查询：“你好，我想给小明发短信，请告诉我他的短信路由信息。”

  2. （Step 4） UDM收到请求，立刻检索小明的档案。它发现小明当前处于开机注册状态，并且他正由一个ID为SMSF-instance-01的SMSF实例服务。同时，UDM在档案中看到了我们之前提到的“支持SBI”标签。于是，它将SMSF的实例ID/地址，以及“支持SBI”的指示，一并回复给SMS-GMSC。

步骤 5 & 6: 核心转发与最后一公里

  1. The SMS-GMSC forwards the SMS message to the SMSF… by invoking Nsmsf_SMService_MtForwardSm service operation.
  1. MT SMS over NAS procedure between SMSF, AMF and UE is same as the definition in step 4a to 6b of Figure 4.13.3.6-1 of 3GPP TS 23.502.

深度解读：

  1. （Step 5） SMS-GMSC现在有了明确的目标。它将天气预报的短信内容打包，调用了目标SMSF的Nsmsf_SMService_MtForwardSm服务，将短信精准地转发给了短信业务的“大脑”——SMSF。

  2. （Step 6） 这是投递的“最后一公里”。SMSF收到短信后，它并不直接和手机通信。它将短信内容通过SBI接口，交给了当前为小明服务的“信使”——AMF。AMF再利用其与小明手机之间早已建立的NAS信令通道，将这条天气预报送达到小明的手机屏幕上。

步骤 7 - 11: 投递报告与流程闭环

  1. The SMSF delivers the delivery report to SMS-GMSC by sending the Nsmsf_SMService_MtForwardSm response to the SMS-GMSC.
  1. The SMS-GMSC updates the SM-Delivery Report Status to UDM by invoking Nudm_SMReportStatus_Request.
  1. The SMS-GMSC delivers the delivery report to SC as defined in TS 23.040.

深度解读：

  1. （Step 7） 小明的手机成功接收短信后，会通过AMF向SMSF回复一个确认。SMSF在收到确认后，会向来时的路径——SMS-GMSC，发送一个包含“投递成功”状态的响应。

  2. （Step 8 & 9） （可选）SMS-GMSC可能会向UDM发起Nudm_SMReportStatus_Request调用，更新一下小明档案里的短信状态，告知“刚刚有一条短信已成功送达”。

  3. （Step 10 & 11） 最后，SMS-GMSC向最初的发送方——气象台的SC，发送最终的投递成功报告，整个流程完美闭环。

至此，一条天气预报短信，经历了一场由多个NF精密协作的、完全基于服务化接口的旅行，成功抵达了小明的手机。

3. 场景二：途经枢纽 - 通过SMS Router的成功投递 (Section 5.1.3)

上午9点，小明在咖啡店消费了一笔金额较大的款项，手机立刻收到了银行发来的信用卡消费确认短信。对于银行这类高安全、高优先级的业务，运营商可能会在网络中部署一个SMS Router，对所有进出的金融类短信进行统一的策略控制、日志记录或内容审计。

这条短信的旅程，就对应了Section 5.1.3 Successful Mobile Terminated short message transfer via SMS Router所描述的流程。我们对照Figure 5.1.3-1: MT SMS over NAS via SMS Router，看看它与场景一有何不同。

关键差异点：路由查询的“中转”

流程的前3步与场景一完全相同：SC到SMS-GMSC，SMS-GMSC发现并查询UDM。真正的变化发生在第4步。

  1. The UDM shall check the registration/reachability flags to determine the potential target nodes, e.g. SMSF. For MT SM transfer via SMS Router, the UDM shall invoke the Nrouter_SMService_RoutingInfo to provide the SMSF Instance Id to the SMS Router.
  1. UDM responds to the SMS-GMSC by sending Nudm_UECM_SendRoutingInfoForSM response, including SMS Router address…

深度解读（Step 4, 5, 6）：

  • 当UDM收到SMS-GMSC的路由查询请求后，它在小明的档案里发现，所有给小明的短信都配置了需要经过一个特定的SMS Router。

  • 于是，UDM并没有直接把SMSF的地址返回给SMS-GMSC。相反，它转身去调用了SMS Router的Nrouter_SMService_RoutingInfo服务，相当于UDM在“咨询”SMS Router：“我这有条给小明的短信，按策略你觉得该发给哪个SMSF？”

  • SMS Router执行完内部策略后，将目标SMSF的信息回复给UDM（Step 5）。

  • 最终，UDM再将SMS Router的地址回复给SMS-GMSC（Step 6）。

这个变化是核心！现在，SMS-GMSC拿到的“下一跳”地址，不再是最终目的地SMSF，而是中间的“路由枢纽”SMS Router。

关键差异点：消息转发的“两级跳”

7-8. The SMS-GMSC forwards the SMS message to the SMS Router, and then SMS Router forwards the SMS message to the SMSF. … SMS-GMSC … forwards the SMS message to the SMS Router by invoking Nrouter_SMService_MtForwardSm service operation. And then the SMS Router forwards the SMS message to the SMSF by invoking Nsmsf_SMService_MtForwardSm service operation.

深度解读（Step 7 & 8）：

消息的转发路径从之前的“一跳直达”变成了“两级跳”：

  1. 第一跳：SMS-GMSC将银行的消费提醒短信，通过调用Nrouter_SMService_MtForwardSm服务，发送给SMS Router。

  2. 第二跳：SMS Router在对短信进行了策略处理（如记录日志）后，再通过调用Nsmsf_SMService_MtForwardSm服务，将短信转发给最终的SMSF。

后续的步骤9（SMSF → AMF → UE）以及步骤10-15（投递报告的逐级返回）与场景一类似，只是报告的返回路径也同样需要经过SMS Router这个中间枢纽。

通过引入SMS Router，运营商的网络架构获得了更高的灵活性和控制力，可以在不改变核心网元（SMS-GMSC, SMSF）逻辑的情况下，动态地插入各种增值业务处理能力。

【FAQ环节】

Q1：什么是“SBI support indication”？如果网络中同时存在支持和不支持SBI的短信网元，它如何确保业务正常？

A1：“SBI support indication” 是一个存储在UDM中的关键标识，用于指明一个用户当前所关联的短信功能节点（如SMSF、SMS Router）是否支持全新的服务化接口（SBI）。它的作用就像一个“协议能力标签”。当SMS-GMSC向UDM查询路由时，UDM会返回这个标签。SMS-GMSC根据这个标签来决定是使用基于HTTP/2的SBI流程（本章所述），还是回退（fallback）到基于MAP/Diameter的传统流程。这个机制是实现5G网络与旧网络平滑共存、互通和演进的关键，确保了无论用户在何种网络环境下，短信业务都能得到正确处理。

Q2：在无路由器的场景（5.1.2）和有路由器的场景（5.1.3）中，UDM的角色有何不同？

A2：UDM的角色发生了从“最终决策者”到“引导者+信息中继者”的转变。

  • 无路由器场景（5.1.2）：UDM直接查询并返回最终的路由目的地——SMSF的地址。它做出了最终的路由决策。

  • 有路由器场景（5.1.3）：UDM发现有路由策略介入，于是它不再直接决策。它先把路由问题“外包”给SMS Router去处理（调用Nrouter_SMService_RoutingInfo），拿到结果后，再把“下一跳”——SMS Router的地址返回给查询者SMS-GMSC。在这里，UDM更像一个引导员，它将请求引导至了正确的策略执行点。

Q3：引入SMS Router会给短信投递带来什么好处？会不会增加延迟？

A3：引入SMS Router主要带来以下好处：

  1. 策略集中控制：可以将复杂的路由策略（如黑白名单、内容过滤、消息分流、计费策略）集中在SMS Router上实现，而无需修改SMS-GMSC和SMSF，实现了业务逻辑和基础转发的分离。

  2. 业务灵活性：方便快速上线新的短信增值业务，只需在SMS Router上进行配置或开发即可。

  3. 简化网络：在大型网络中，可以减少SMS-GMSC与多个SMSF之间的连接复杂性，形成“星型”或“总线型”的拓扑。

当然，增加一个处理节点理论上会引入微小的处理延迟。但在高速的5G核心网内部，这种基于SBI的API调用所带来的延迟通常在毫秒级，对于用户体验几乎没有影响，而其带来的架构灵活性和业务价值远超这点开销。

Q4：在Figure 5.1.2-1中，为什么步骤8（SMS-GMSC向UDM报告状态）是可选的？

A4：步骤8 (Nudm_SMReportStatus_Request) 是可选的，因为短信的投递状态报告（Delivery Report, DR）的核心目的是通知始发方SC（如银行、应用）。只要最终的投递报告能成功返回给SC（步骤10），核心业务流程就算完成了。向UDM更新状态，更多的是为了在网络内部（特别是UDM这个数据中心）维护一份更完整的用户短信活动记录。这对于后续的运维、分析、排障或某些特殊业务可能有用，但并非每一次成功投递都必须执行的强制动作。运营商可以根据自己的运维需求和信令负荷考虑来决定是否开启这一功能。

Q5：整个MT SMS流程都基于SBI调用，这是否意味着所有通信都是无状态的？

A5：这是一个很好的问题。虽然SBI接口本身基于HTTP，提倡无状态（stateless）的交互，但在一个完整的业务**流程（Procedure）中，NF之间需要维护一个事务上下文（transaction context）来关联一系列的请求和响应。例如，在SMSF将短信投递给AMF后，它需要“记住”这个投递任务，以便在收到AMF的确认或失败通知后，能够生成正确的投递报告并将其返回给调用它的SMS-GMSC。同样，SMS-GMSC在转发短信后，也需要维持一个会话状态，等待来自SMSF/SMS Router的最终响应。因此，虽然单个API调用可以是无状态的，但实现整个业务流程的NF实例内部，是有状态（stateful）**的。

关系图谱