51学通信

深度解析 3GPP TS 31.102：4.2.32 EFSMSR (短信状态报告)

17分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。由于规范中 4.2.30 EFEXT2 和 4.2.31 EFEXT3 是对电话本扩展功能的定义，其原理与我们之前在EFADN部分介绍的EFEXT1高度一致，主要是作为长号码存储的“接续文件”，在此合并简述，不再展开独立篇章。我们将直接进入下一个具有独立功能的文件。

深度解析 3GPP TS 31.102：4.2.32 EFSMSR (短信状态报告)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.32 EFSMSR (Short message status reports)”的核心章节，旨在为读者深入剖析在请求短信“已读回执”的背后，USIM卡是如何通过EFSMSR这个专用的“回执存储柜”，来精确匹配和保存网络返回的状态报告的。

在我们探讨EFSMS（短信存储）时，曾简要提及了短信状态报告（Status Report）的联动机制。当我们的主角“李想”发送一条重要短信（例如，一份合同确认信息）时，他不仅希望短信被成功“发送”到网络，更希望确切地知道这条短信是否已经成功“送达”对方的手机。为此，他在发送时勾选了“请求发送报告”选项。

网络在成功将短信投递给接收方后，会向李想的手机回送一条特殊类型的短信——状态报告。这条报告中包含了原始短信的“命运”信息：是成功送达、仍在尝试、已过期，还是因故失败。

那么，手机收到这条状态报告后，应该如何处理？如何将它与李想之前发送的那条特定短信精确地关联起来？并且，是否需要将这份重要的“回执”保存下来以备查证？

为了解决这个问题，3GPP规范设计了EFSMSR文件。

EFSMSR，全称 Short Message Status Reports，即“短信状态报告”。它的核心使命，就是作为USIM卡中一个专用的、用于存储收到的状态报告的“档案馆”。它通过一个巧妙的链接机制，将每一份“回执”与EFSMS中存储的原始“发件”精确地对应起来。

1. “回执档案馆”：EFSMSR的核心价值

EFSMSR的核心价值在于为短信发送的可靠性提供一个持久化的、可追溯的证据链。

If service n° 11 is “available”, this file shall be present.

This EF contains information in accordance with TS 23.040 comprising short message status reports which have been received by the UE from the network.

Each record is used to store the status report of a short message in a record of EFSMS. The first byte of each record is the link…

从原文中，我们可以提炼出EFSMSR的关键特性：

  1. 服务关联: 它的存在与EF_UST中的服务n°11相关联。这是一个可选服务。

  2. 专门用途: 文件只用于存储收到的状态报告。

  3. 链接机制: EFSMSR中的每一条记录，都通过其第一个字节 (SMS record identifier)，与EFSMS中的一条已发送短信记录建立链接关系。

EFSMSR的工作流程

让我们完整地看一下李想发送重要短信并接收回执的全过程：

  1. 发送与标记:

    • 李想发送短信，并请求状态报告。

    • 手机将这条待发送的短信存入EFSMS的第10号记录，并根据我们之前在EFSMS章节学到的知识，将该记录的状态字节标记为“已请求状态报告，等待接收”（例如，b5b4=01）。

    • 短信被成功发送到网络。手机更新记录10的状态为“已发送，等待状态报告”。

  2. 接收状态报告:

    • 网络将短信成功投递给接收方后，向李想的手机发送一条状态报告。

    • 李想的手机收到这条特殊短信。

  3. 存储与链接:

    • 手机解析状态报告，得知这是针对之前发送的第10号记录短信的回执。

    • 手机在EFSMSR中寻找一个空闲的记录（例如，第3号记录）。

    • 手机将EFSMSR第3号记录的第一个字节（SMS record identifier）写入'0A'（十六进制，代表十进制的10）。这个动作，就像是在这份“回执”上盖了一个章，写着“此回执对应发件箱第10号邮件”。

    • 手机将状态报告的完整TPDU内容，写入EFSMSR第3号记录的剩余部分。

  4. 更新原始邮件状态:

    • 为了完成闭环，手机会再次更新EFSMS中第10号记录的状态字节，将其标记为“状态报告已收到并存储”（例如，b5b4=11）。

    • 手机的UI界面上，这条已发送短信旁边可能会出现一个“双勾”或“已送达”的标识。

通过这个流程，EFSMSR不仅保存了回执本身，更重要的是，它通过SMS record identifier，建立了一条从“回执”到“发件”的清晰索引，使得整个投递过程变得可追溯。

2. “档案”的结构：EFSMSR文件结构与编码剖析

EFSMSR的设计专注于存储和链接两大功能。

2.1 文件结构

表 4.2.32-1: EFSMSR 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F47’ |

| Structure | Linear Fixed |

| Record length| 30 bytes |

| Update activity| Low |

| Access Conditions| READ: PIN, UPDATE: PIN, … |

记录内容 (30 bytes)

| 字节 | 描述 | M/O | 长度 |

| :--- | :--- | :--- | :--- |

| 1 | SMS record identifier (短信记录标识符) | M | 1 byte |

| 2 to 30 | SMS status report (短信状态报告) | M | 29 bytes |

逐项解读：

  • Record length: 30字节。这个长度足以容纳一个状态报告TPDU的核心内容。

  • SMS record identifier (1 byte): 这是实现链接的关键字段。

    Contents: - this data item identifies the corresponding SMS record in EFSMS, e.g. if this byte is coded ‘05’ then this status report corresponds to the short message in record #5 of EFSMS.

    Coding: - ‘00’- empty record; - ‘01’ to ‘FF’- record number of the corresponding SMS in EFSMS.

    • 它的值直接对应EFSMS文件中的记录号。'05'就代表链接到EFSMS的第5条记录。

    • '00'是一个特殊值，表示这条EFSMSR记录是空闲的。当手机需要删除一条状态报告时，只需将这个字节置为'00'即可。

  • SMS status report (29 bytes):

    Contents: - this data item contains the SMS-STATUS-REPORT TPDU as specified in TS 23.040…

    这部分存储了状态报告消息本身的TPDU。状态报告TPDU的结构与普通短信TPDU类似，但其“用户数据”部分承载的是关于原始短信的送达信息，例如：

    • Message Reference: 原始短信的TP-MR。

    • Recipient Address: 原始短信的接收方地址。

    • Status: 最关键的字段，用一个字节表示送达状态，如“成功送达”、“发送失败-内存不足”、“发送失败-网络错误”等。

    • Discharge Time: 短信中心将短信投递给接收方的时间戳。

3. EFSMSR与EFSMSS的对比与演进

在EFSMS章节中，我们提到了EFSMSS（短信状态），它也与状态报告有关。这两者是什么关系？

  • EFSMSS (宏观状态): 它不存储具体的状态报告内容。它只关心两件事：1) 整个短信服务的内存是否已满 (SMS "Memory Cap. Exceeded" Flag)；2) 最后一次发送的短信的引用号是什么 (Last Used TP-MR)。它是一个宏观的、服务级别的状态文件。

  • EFSMSR (微观记录): 它存储的是每一份收到的状态报告的完整内容，并且通过记录号与原始短信一一对应。它是一个微观的、记录级别的存档文件。

可以这样理解它们的演进关系：在早期的设计中，EFSMSR是处理状态报告的唯一标准方式。但后来发现，对于大多数普通用户，他们只需要在UI上看到一个“已送达”的提示即可，并不需要在USIM中永久保存每一份状态报告的详细技术PDU。因此，一个更轻量级的机制被引入：手机收到状态报告后，可以直接更新EFSMS中的状态字节来触发UI变化，而无需再占用EFSMSR的空间。

EFSMSR因此变成了一个“可选的、用于增强可靠性和可追溯性”的功能。当服务n°11被激活时，手机就应该遵循将状态报告存入EFSMSR的完整流程。如果未激活，手机则可以采用更简化的处理方式。

总结：为可靠投递提供“铁证”

EFSMSR通过其专用的存储空间和与EFSMS的精巧链接机制，为短信这一异步通信方式的“送达”环节提供了强有力的闭环验证。

  • 提供了可追溯的证据: 存储了状态报告的完整PDU，为每一次关键通信的投递成功与否提供了可供查证的“电子回执”。

  • 实现了精确的匹配: 通过“SMS record identifier”，巧妙地解决了如何将异步返回的状态报告与数天前发送的某条特定短信关联起来的难题。

  • 增强了短信业务的可靠性: 为需要高可靠性确认的短信应用（如商业合同、法律通知）提供了底层的技术支撑。

对于李想而言，当他发送那条至关重要的合同确认短信后，手机上那个小小的“已送达”提示，背后可能就有一条完整的记录被安全地存档在EFSMSR中。这份存储在USIM卡深处的“数字回执”，为他的商业通信增加了一份沉甸甸的确定性。EFSMSR的存在，体现了3GPP标准在设计基础业务时，对端到端流程完整性和可靠性的严谨追求。

FAQ环节

Q1：如果我删除了EFSMS中的一条已发送短信，那么EFSMSR中对应的状态报告会怎么样？

A1：规范没有强制规定必须删除。此时，EFSMSR中那条状态报告的“SMS record identifier”指向了一个已经被标记为“free space”的EFSMS记录，这个链接就“悬空”了。手机的短信应用在设计时，通常会实现联动删除逻辑：当用户删除EFSMS中的一条短信时，应用会检查是否存在与之关联的EFSMSR记录，并将其也标记为“empty record”（即将其第一个字节置为'00'），以释放空间。

Q2：EFSMSR的空间是有限的，如果我请求的状态报告很多，存满了怎么办？

A2：当EFSMSR没有空闲记录（即所有记录的第一个字节都不是'00'）时，手机会执行“清除 (Purge)”操作。手机会遍历EFSMS，寻找那些已经收到了状态报告但其报告尚未被用户处理或已经过时的短信（例如，用户已经删除了原始短信）。然后，手机会找到这些短信在EFSMSR中对应的记录，并将它们删除（标记为空闲），从而为新的状态报告腾出空间。这是一种“垃圾回收”机制。

Q3：EFSMSR中的状态报告，和我在短信对话界面里看到的“已送达”提示，是一回事吗？

A3：EFSMSR中的状态报告是数据源，而“已送达”提示是UI表现。手机的短信应用在收到状态报告、将其存入EFSMSR并更新EFSMS状态后，就会在对话界面中，将对应短信的UI状态更新为“已送达”。所以，你看到的提示，是EFSMSR中存储的技术信息经过应用软件“翻译”后的结果。

Q4：为什么EFSMSR的UPDATE权限是PIN，而不是ADM？

A4：因为状态报告是作为一条特殊短信由网络下发给手机的，存储这个报告是手机的正常业务逻辑行为，理应由手机（在用户授权后）来执行。如果设为ADM，就意味着只有运营商才能写入状态报告，这在逻辑上是不通的，也无法实现实时的状态更新。将其设为PIN，既允许手机执行其正常功能，又保证了操作是在用户（机主）的授权下进行的。

Q5：现在还有必要使用EFSMSR吗？

A5：对于普通用户的日常短信，其必要性确实在降低，因为手机本地存储和更简单的状态指示已经足够。但EFSMSR在以下场景依然有其价值：1) 功能手机/非智能设备: 对于存储和处理能力有限的设备，遵循USIM这套标准化的存储机制是最简单可靠的实现方式。2) 高可靠性应用: 在一些企业或法律应用中，需要对通信过程进行存档和审计，USIM卡作为一个独立的、可信的存储介质，EFSMSR中存储的“电子回执”可以作为强有力的证据。3) USAT应用: 某些USAT应用可能需要解析状态报告的内容来触发下一步的业务逻辑，此时就需要读取EFSMSR的完整内容。

关系图谱