51学通信

深度解析 3GPP TS 23.540：5.2 MO SMS 流程 (移动始发短信全景)

19分钟阅读

好的，我们继续5G服务化短信的深度探索。这是系列文章的第七篇，我们将把目光从接收方转向发送方，深入剖析当小明从他的5G手机发出一条短信时，网络内部所经历的一场精密而高效的协作。

深度解析 3GPP TS 23.540：5.2 MO SMS 流程 (移动始发短信全景)

本文技术原理深度参考了3GPP TS 23.540 V18.4.0 (2024-06) Release 18规范中，关于“5.2 Procedure for SBI-based MO SMS”的核心章节，覆盖了 5.2.1 General、5.2.2 Procedure for Successful Mobile Originated short message transfer 和 5.2.3 Unsuccessful Mobile Originated short message transfer。本文旨在为读者完整呈现一条移动始发（MO）短信，从用户手机出发，到成功送达外部服务中心（SC）的完整旅程，并详解当这条旅程遭遇挫折时的失败处理机制。

到目前为止，我们所有的故事都围绕着小明如何“接收”短信展开。我们见证了MT（移动终止）短信在5G网络中的各种奇妙旅程，无论是成功还是失败。现在，是时候转换视角，看看当小明主动出击，成为信息的“发送者”时，会发生什么。

今天的故事场景非常生活化：小明收到了一条银行的营销短信，他觉得内容不错，便按照提示回复了“Y”进行确认。这条看似简单的“Y”，将触发一条完整的MO（移动始-发）短信流程。我们将跟随这条信息，穿越5G核心网，揭开它背后那套与MT流程镜像对称，却又独具特色的处理机制。

1. MO SMS 流程总览 (Section 5.2.1 General)

与MT流程的开篇类似，5.2.1章节首先为我们勾勒了MO SMS流程设计的核心理念和新引入的角色。

The procedure for SBI-based MO SMS is showed in Figure 5.2.2-1, which is based on MO SMS procedures in 3GPP TS 23.040 clause 10.2. Compared to procedures in 3GPP TS 23.040, new services are introduced in, including:

  • Niwmsc_SMService service provided by SMS-IWMSC.

This new service is registered in NRF, and can be invoked by service consumers.

深度解读：

  1. 血统一脉相承：再次强调，5G MO SMS的业务核心逻辑（如CP-ACK, RP-ACK等确认机制）依然遵循TS 23.040的经典定义。5G的创新在于承载和路由方式。

  2. 新服务的诞生：这里明确提出了MO流程中最重要的一个新服务——Niwmsc_SMService。这是由**SMS-IWMSC（短信互通移动交换中心）**提供的服务。

    • 角色定位：SMS-IWMSC是MO短信的“出境大门”。当一条短信需要从5G网络发送到外部的服务中心（SC）时，SMS-IWMSC就是最后一站。

    • 服务化体现：Niwmsc_SMService的引入，意味着“发送MO短信至外部”这个能力，被封装成了一个标准的、可被发现（通过NRF）和调用（通过SBI）的网络服务。这正是SBA思想的体现。

2. 成功的旅程：一条“Y”的诞生记 (Section 5.2.2)

小明回复“Y”后，点击发送按钮。Section 5.2.2 Procedure for Successful Mobile Originated short message transfer及其附图Figure 5.2.2-1为我们详细描绘了这条信息的旅程。

步骤 0 & 1: 起航！从手机到短信大脑

  1. SMS-IWMSC registers Niwmsc_SMService service in the NRF, during the NF registration procedure.
  1. MO SM message transfer from UE to SMSF through AMF follows the current procedure as defined in 3GPP TS 23.040.

深度解读：

  • （Step 0 - 准备工作） 在一切开始之前，网络中的所有SMS-IWMSC实例，都必须先向“114查号台”NRF注册，声明自己能提供Niwmsc_SMService服务。这是SBA架构的“常规操作”，确保服务可被发现。

  • （Step 1 - 第一站） 小明点击发送后，短信内容被打包在NAS信令中，通过无线接口上行至当前为他服务的AMF。AMF识别出这是一条上行短信，于是将它转发给了短信业务的“大脑”——SMSF。

    • 注意：从UE到SMSF的这一段，其底层机制（NAS Transport）复用了5G系统通用的上行信令传输流程，定义在TS 23.501/502中。

步骤 2: 寻路！寻找出境的大门

2a. …SMSF invokes the Nnrf_NFDiscovery to discover and select serving SMS-IWMSC with the parameters of SUPI and/or GPSI and/or location … and/or E.164 address of the SC.

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

深度解读：

  • （Step 2a） SMSF收到了小明的“Y”，它的任务是把这条信息送出网络。于是，它需要找到“出境大门”——SMS-IWMSC。

  • SMSF向NRF发起Nnrf_NFDiscovery服务调用，请求一个可用的SMS-IWMSC实例。

  • 智能的发现：值得注意的是，这次服务发现可以携带多种参数，例如用户的标识（SUPI/GPSI）、用户的位置（TAI, CGI）、甚至是目标SC的地址。NRF可以利用这些信息，进行更智能的选择。比如，选择一个地理位置上离SC更近的SMS-IWMSC，或者根据SC的类型选择一个专门处理金融业务的SMS-IWMSC。

  • （Step 2b） 如果NRF找不到支持SBI的SMS-IWMSC，SMSF会智能地回退到传统的MAP/Diameter协议，确保业务兼容性。

步骤 3 & 4: 交付！委托出关

  1. SMSF sends a Niwmsc_SMService_MoForwardSm service request to the URI of serving SMS-IWMSC… The payload body of the request shall contain the SM record to be sent, the Service Centre address, the callbackURI for MO SMS Delivery Report…
  1. MO SMS delivery procedure between SMS-IWMSC and SC is the same as the definition in step 4 of Figure 4.13.3.3-1 of 3GPP TS 23.502.

深度解读：

  • （Step 3） NRF返回了一个可用的SMS-IWMSC地址。SMSF立即调用其Niwmsc_SMService_MoForwardSm服务。这个API调用的请求体中，包含了所有必要的信息：

    • SM record to be sent: 短信的核心内容，即那个“Y”。

    • Service Centre address: 目标地址，即银行SC的地址。

    • callbackURI for MO SMS Delivery Report: 这是一个关键参数！SMSF告诉SMS-IWMSC：“当你收到银行的最终投递报告后，请通过这个URI地址通知我。” 这又是一个典型的异步回调机制，体现了SBA的灵活性。

  • （Step 4） SMS-IWMSC收到请求后，执行其核心功能。它负责将这条基于SBI的内部消息，转换成与外部SC通信所需的协议（可能是SMPP等行业标准协议），然后将“Y”成功发送给银行的SC。

步骤 5 & 6: 佳音！投递报告的回传

  1. SMS-IWMSC sends Niwmsc_SMService_MoForwardSm response to deliver the MO SMS delivery report to the URI of serving SMSF, which is obtained in step 3.
  1. MO SMS delivery report procedure between SMSF, AMF and UE is the same as the 3GPP TS 23.502.

深度解读：

  • （Step 5） 银行SC成功处理了小明的确认，并向SMS-IWMSC返回了一个成功的回执（Delivery Report）。SMS-IWMSC记起了SMSF在步骤3中留下的callbackURI，于是它向这个URI地址发送一个响应，将成功的投递报告回传给SMSF。

  • （Step 6） SMSF收到成功的投递报告后，如果小明的手机设置了要求接收MO投递报告，SMSF就会将这个“发送成功”的状态，通过AMF，以下行NAS信令的方式，通知给小明的手机。小明的手机上可能会出现一个“已送达”的提示。

至此，小明回复的“Y”，经历了一场完整的、基于服务化接口的MO短信之旅，成功完成了它的使命。

3. 崎岖的旅程：当“Y”迷失方向 (Section 5.2.3)

现在，我们假设一个不那么顺利的场景：当SMSF将小明的“Y”转发给SMS-IWMSC后，SMS-IWMSC在尝试联系银行SC时，发现银行的服务器宕机了，无法连接。

Section 5.2.3 Unsuccessful Mobile Originated short message transfer及其附图Figure 5.2.3-1和相关表格，为我们揭示了这套完善的错误处理机制。

步骤 4: 坏消息的传来

  1. SMS-IWMSC sends Niwmsc_SMService_MoForwardSm response with HTTP status code for application errors as defined in Table 5.3.2-1.

深度解读：

  • SMS-IWMSC在联系SC失败后（例如，连接超时），它不会无限期等待。它会立即向它的调用者——SMSF，发送一个带有明确错误原因的失败响应。

  • 错误码的艺术：这个失败响应使用了标准的HTTP状态码来传达错误类型，并且在消息体中可能包含更详细的应用层错误码。规范中的Table 5.3.2-1: Application errors对此进行了详细定义。

    • 400 Bad Request: 如果SMSF发送的请求格式有问题（如SMS_PAYLOAD_MISSING）。

    • 403 Forbidden: 如果是因为权限问题（如UNKNOWN_SERVICE_CENTRE_ADDRESS，USER_NOT_SERVICE_CENTER）。

    • 504 Gateway Timeout: 这正是我们模拟的场景——UNREACHABLE_SMS_SC，即下游网关（SC）超时。

步骤 5: 将失败告知源头

  1. Failure report from SMSF to UE, with the error cause code as defined in Table 5.3.2-2.

深度解读：

  • SMSF收到了来自SMS-IWMSC的504 Gateway Timeout错误响应。

  • SMSF的核心职责，是将这个网络侧的失败，翻译成UE（小明的手机）能够理解的失败原因，并通过AMF，以下行的RP-ERROR消息（一种在NAS层定义的短信错误报告）发送给小明的手机。

  • “翻译”的艺术：Table 5.3.2-2: Mapping between Application errors and Cause value就是这本“翻译词典”。

    • 它将来自SMS-IWMSC的HTTP层/应用层的错误，映射为TS 24.011中定义的、UE能够解析的RP-ERROR原因值。

    • 例如，UNREACHABLE_SMS_SC（504错误）会被映射为 Cause value = 38 (Network out of order)。

  • 最终，小明的手机会收到这个失败报告，并在屏幕上显示“发送失败”的提示，可能还会附带上网络故障的原因。

这套从网络侧HTTP错误到终端侧RP-ERROR的精细映射和翻译机制，确保了即便是失败，也能以一种标准化的、对用户友好的方式进行呈现，形成了完整的业务闭环。

【FAQ环节】

Q1：在MO SMS流程中，SMSF和SMS-IWMSC的核心分工是什么？为什么需要两个NF？

A1：这是SBA架构下职责分离的典型体现。

  • SMSF（短信服务功能）是面向用户侧的业务逻辑中心。它负责处理所有与UE直接相关的事务，如接收来自AMF的上行短信、处理UE的上下文、向UE下发投递报告等。它关心的是“我的用户”的短信收发。

  • SMS-IWMSC（短信互通移动交换中心）是面向外部网络的互通网关。它负责将内部的、基于SBI的短信消息，转换成与外部SC通信所需的各种协议（如SMPP），并处理与外部网络的连接和路由。它关心的是“如何与外部世界对话”。

这种分离使得网络内部的业务逻辑与外部的互通协议解耦，任何一方都可以独立演进，增加了架构的灵活性和健壮性。

Q2：在MO SMS的服务发现（步骤2）中，为什么可以使用位置信息来选择SMS-IWMSC？

A2：使用位置信息进行服务发现，是5G网络走向智能化和边缘化的一个体现。在某些场景下，这能带来显著的好处：

  1. 降低时延：如果运营商在全国有多个SMS-IWMSC实例，NRF可以选择一个地理位置上离目标SC最近的实例，从而减少消息在骨干网上的传输时延。

  2. 本地业务 breakout：对于一些本地化的应用（如本地政务通知平台），短信可以直接从本地的SMS-IWMSC出网，无需迂回到中央节点，提高了效率并降低了核心网的负荷。

  3. 遵循法规：某些国家或地区可能有数据主权的法规要求，本地用户产生的通信数据必须在本地处理和出网。基于位置的服务选择可以满足这类合规性要求。

Q3：什么是callbackURI？它在MO SMS流程中起到了什么关键作用？

A3：callbackURI是回调统一资源标识符，它是实现异步通信的关键机制。在MO SMS流程中：

  • 当SMSF将短信交给SMS-IWMSC时，它无法确定SMS-IWMSC需要多长时间才能从外部SC那里获得最终的投递报告（可能几秒，也可能几分钟）。

  • 如果SMSF采用同步等待的方式，会长时间占用连接和资源，效率低下。

  • 于是，SMSF在请求中提供了一个callbackURI，相当于告诉SMS-IWMSC：“事情交给你了，你先忙。办好了以后，往这个地址（URI）发个通知就行。”

  • 这样，SMSF就可以立即处理其他任务。当SMS-IWMSC收到投递报告后，它会主动向这个callbackURI发起一个HTTP请求，将结果通知给SMSF。这种“你办事，我放心，办完通知我”的异步模式，是现代分布式系统中提高系统吞吐量和解耦服务的重要手段。

Q4：为什么MO SMS的失败报告需要一个复杂的“翻译”过程（从HTTP错误码到RP-ERROR cause）？

A4：这个“翻译”过程是连接两个不同技术域的必要桥梁。

  • HTTP错误码是5G核心网内部SBA架构的“工作语言”。它遵循互联网RESTful API的设计规范，用于在NF之间传递错误状态。

  • RP-ERROR cause value是定义在空口协议（TS 24.011）中的“终端语言”。它是UE（手机）能够理解和解析的、用于表示短信层失败原因的一套标准化编码。

核心网内部的NF（如SMSF）需要扮演这个“翻译官”的角色，将它在网络侧听到的（HTTP错误），翻译成终端能听懂的（RP-ERROR），从而确保错误信息能够端到端地、无歧义地传递，最终以用户可见的方式呈现出来。

Q5：如果小明发送的MO短信成功送达SC，但由于SC自身原因处理失败了（比如小明回复的格式不对），小明会收到什么通知？

A5：这是一个很好的关于业务层失败和网络层失败区分的问题。

  • 我们本章讨论的Unsuccessful流程，主要指的是网络层面的投递失败（例如SC不可达）。在这种情况下，网络会给小明返回RP-ERROR。

  • 在您提出的场景中，网络层面是投递成功的。SMS-IWMSC会收到SC的成功接收确认，并回传给SMSF和UE一个成功的投递报告。

  • 然而，SC在解析短信内容后，发现了业务逻辑上的错误（格式不对）。此时，这是一个应用层/业务层的问题。SC应该通过另外一条MT短信来通知小明。例如，银行SC会发起一条新的MT短信，内容是：“尊敬的客户，您回复的指令格式有误，请重新输入。”这条短信会再次经历我们之前讨论的完整MT SMS流程，最终送达小明。

关系图谱