好的，我们继续解读TR 21.918的后续章节。
深度解析 3GPP TR 21.918：21.1 Enhancements on Service-based support for SMS in 5GC (5GC中基于服务的SMS支持增强)
本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“21.1 Enhancements on Service-based support for SMS in 5GC”的核心章节，旨在为读者深入剖析5G-Advanced如何通过解决协议“代沟”问题，确保传统而关键的短信业务（SMS）能够在现代化的、基于服务的5GC核心网架构中，实现更平滑、更可靠的互通与演进。
短信（SMS），作为通信领域的“活化石”，尽管面临着各类即时通讯App的冲击，但凭借其普遍性、可靠性和官方通知的权威性，至今仍在验证码、银行通知、紧急告警等场景中，扮演着不可或替代的角色。
随着5G核心网（5GC）全面转向基于服务的架构（Service-Based Architecture, SBA），几乎所有的核心网功能（NF）都演变成了通过RESTful API相互调用的“微服务”。Release 17为此定义了一套全新的、基于服务的短信架构（SMS_SBI），引入了SMSF（SMS功能）、SMS Router等新网元，旨在让短信业务也能融入这个现代化的SBA大家庭。
然而，理想很丰满，现实很骨感。新旧架构的更替，不可能一蹴而就。在漫长的过渡期内，全新的、支持SBI接口的5G SMSF，将不可避免地需要与大量依然使用传统Diameter或MAP协议的4G/3G/2G网元（如HSS, MSC）打交道。这种协议上的“代沟”，导致了Rel-17的SMS_SBI方案在实际部署中，遇到了一系列“水土不服”的互通性问题。
为了解决这些“历史遗留问题”，确保短信业务的平滑演进，3GPP在Release 18中启动了“eSMS_SBI”的增强项目。今天，我们的主角，是一位运营商核心网的集成测试工程师，小张。他最近的任务，就是测试新上线的5G SMSF，在与现网中海量的老旧网元进行互通时，能否正确地收发短信。让我们跟随小张的测试案例，深入21.1章节，看看5G-Advanced是如何为这位“老兵”——短信，在新时代铺平道路的。
1. 核心挑战：新老网元之间的“鸡同鸭讲”
小张遇到的第一个，也是最典型的问题，发生在移动终止（MT）短信的路由查询流程中。
场景: 一位4G用户，给一位5G用户发送了一条短信。这条短信首先到达了网络中的SMS-GMSC（短信网关MSC）。SMS-GMSC需要知道这位5G用户当前是由哪个AMF/SMSF在服务，以便将短信转发过去。于是，它需要向用户的“户籍所在地”——UDM/HSS，查询路由信息。
Rel-18 WID eSMS_SBI have solved incompatibility issues between SBI-based SMS and legacy SMS. In Rel-17, during SM MT delivery, when SMS-GMSC makes use of MAP or Diameter to retrieve RoutingInfoForSM from legacy UDM/HSS (i.e. UDM/HSS do not support SBI-based SMS), the response message is lack of SBI-support information of SMSF/IP-SM-GW/SMS Router, which may cause incompatibility problems.
这里的问题就出在了“查询”和“应答”的语言不通上：
- SMS-GMSC的“老派”语言: 现网中大量的SMS-GMSC，依然使用传统的MAP或Diameter协议，向UDM/HSS发送“查询路由信息（RoutingInfoForSM）”的请求。
- UDM/HSS的“新潮”应答（的缺失）: 用户的签约数据在5G UDM中。UDM知道该用户正由一个全新的、支持SBI接口的5G SMSF服务。但是，当UDM通过传统的MAP/Diameter协议来回应SMS-GMSC时，这个“老旧”的协议消息体中，根本没有字段来承载“我为你找到的下一个节点（SMSF），是一个只讲SBI（HTTP/2）语言的新朋友”这一关键信息。
- 沟通的“僵局”: SMS-GMSC收到的回复中，只看到了一个SMSF的地址，但它不知道该用什么“语言”去和这个SMSF沟通。它可能会默认使用自己熟悉的Diameter协议去尝试连接，结果自然是连接失败，短信发送失败。
2. 解决方案一：在“老协议”中加入“新方言”
为了打破这个僵局，Rel-18对传统的MAP和Diameter协议进行了“微创手术”，为它们增加了能够表达“SBI支持能力”的“新方言”。
In Rel-18, SBI-support-indications for SMSF/IP-SM-GW/SMS Router are added in the RoutingInfoForSM Retrieval Response message in TS 29.338, SBI-support-indications are also added in 3GPP specific AVP codes in TS 29.230.
- Diameter的增强 (TS 29.338): 在Diameter的
RoutingInfoForSM应答消息中，增加了一个新的AVP（属性值对），专门用来指示目标SMSF的SBI支持能力信息（例如，是否支持SBI，以及其SBI接口的FQDN地址）。 - MAP的增强 (TS 29.230等): 类似地，在MAP协议的相关消息中，也通过扩展参数，增加了传递SBI支持信息的能力。
测试验证: 小张重新进行了测试。现在，当老的SMS-GMSC通过Diameter向UDM/HSS查询时，收到的应答中，明确地包含了一个新的AVP：“目标SMSF支持SBI，其API接口地址是 smsf.prod.5gc.mnc01.mcc234.3gppnetwork.org”。SMS-GMSC在解析出这个信息后，就会“恍然大悟”，转而使用其内部新增的、支持HTTP/2的客户端模块，向这个SBI地址发起API调用，成功地将短信转发给了5G SMSF。问题解决！
3. 解决方案二：赋予GMSC“择优录取”的智慧
另一个问题是，如果UDM/HSS发现，目标SMSF既支持新的SBI接口，也同时支持老的Diameter接口（为了兼容性），它应该告诉SMS-GMSC使用哪个？
Rel-18 WID eSMS_SBI have added protocol selection mechanism for SMS-GMSC towards UDM/HSS during MT SM delivery. In Rel-17, SBI-based method is adopted by default, and no protocol selection is considered… It may cause problems when SMS-GMSC use SBI to get RoutingInfoForSM from legacy UDM/HSS. Rel-18 WID eSMS_SBI have added the protocol selection mechanism…
Rel-17的方案过于“激进”，默认总是优先使用SBI，这在与纯旧网络互通时会产生问题。Rel-18为此引入了更智能的协议选择机制。
- 能力对等原则: UDM/HSS在回应时，会同时提供目标节点支持的所有接口信息（SBI地址、Diameter地址等）。
- GMSC择优选择: SMS-GMSC在收到这些信息后，会根据自身的能力和本地配置的优先级策略，来选择使用哪个协议。例如：
- 如果GMSC自身也已经升级，支持SBI，它可能会优先选择使用更高效的SBI接口。
- 如果GMSC还是一个老旧的设备，它就只能选择使用自己唯一支持的Diameter接口。
这种“双向奔赴”的协议选择机制，确保了无论新老设备如何组合，总能找到一条双方都“听得懂”的通信路径，最大限度地保障了互联互通。
4. 规范的“对齐”与“扫尾”工作
除了解决核心的协议“代沟”问题，21.1章节还完成了一系列重要的“对齐”和“扫尾”工作，确保了标准的严谨性和一致性。
Rel-18 WID eSMS_SBI have made some alignment of stage 2 and stage 3 of SMS TSs. e.g. Table 5.3.2-1 of TS 23.540 defines Application errors for MO SM delivery response, HTTP status code of it only includes 403 and 504, but TS 29.579 includes 307/308/400/403/504. Errors like this have been fixed in Rel-18 WID eSMS_SBI.
- Stage 2 (架构) 与 Stage 3 (协议) 的对齐: 小张在测试中发现，Stage 2的架构规范（TS 23.540）中定义的某个流程的错误码，与Stage 3的OpenAPI接口规范（TS 29.579）中定义的HTTP状态码，存在不一致。例如，架构文档只说了有“禁止访问(403)”和“网关超时(504)”两种错误，但接口规范里还定义了“临时重定向(307/308)”等多种状态。
- Rel-18的修复: eSMS_SBI项目组仔细地审阅了所有相关的Stage 2和Stage 3规范，对这些不一致、不清晰的地方进行了全面的修订和对齐，确保了架构设计与协议实现之间的“言行一致”。
这项看似琐碎但至关重要的工作，极大地提升了标准的可读性和可实现性，为像小张这样的测试工程师，以及所有设备商的开发人员，扫清了理解和实现的障碍。
总结
3GPP TR 21.918的21.1章节，是一次典型的、面向“现实世界”的技术演进。它没有引入颠覆性的新功能，而是聚焦于解决新技术（基于服务的5G核心网）在落地过程中，与庞大的、异构的现网存量设备进行互通时，所遇到的最棘手、最现实的“协议代沟”问题。
- 通过在传统协议（Diameter/MAP）中扩展对SBI能力的指示，它为新老网元之间架起了一座“语言”沟通的桥梁。
- 通过引入智能的协议选择机制，它确保了无论网络如何演进，总能找到一条最合适的通信路径，保障了短信业务的连续性。
- 通过对Stage 2和Stage 3规范的全面对齐，它提升了标准的严谨性，降低了产业界实现和互通的成本。
对于小张而言，这些增强意味着他在测试中遇到的许多莫名其妙的互通失败问题，都将在新版本的软件中得到解决，大大提升了他的工作效率。
对于整个5G网络，eSMS_SBI的成功，为其他业务（如IMS语音）从传统协议向SBA架构的平滑演进，提供了一个宝贵的“样板工程”。它深刻地诠释了3GPP标准演进的一个重要哲学：既要勇于拥抱未来（SBA），也要务实地尊重历史（与传统协议的互通）。只有这样，通信网络这座宏伟的大厦，才能在一代代的演进中，既不断向上生长，又始终根基稳固。