51学通信

深度解析 3GPP TS 31.102：4.2.25 EFSMS & 4.2.28 EFSMSS (短信的存储与状态管理)

20分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。

深度解析 3GPP TS 31.102：4.2.25 EFSMS & 4.2.28 EFSMSS (短信的存储与状态管理)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.25 EFSMS (Short messages)”和“4.2.28 EFSMSS (SMS status)”的核心章节，旨在为读者深入剖析在智能手机时代依然不可或缺的短信功能，其背后USIM卡是如何通过EFSMS和EFSMSS这两个文件，构建起一个可靠的存储仓库和精细的状态管理机制的。

尽管即时通讯APP大行其道，但短信（Short Message Service, SMS）凭借其高触达率、无需安装、跨平台通用等特性，在验证码、官方通知、紧急通信等领域依然扮演着无法替代的角色。当我们发送或接收一条短信时，这些信息是如何被安全、可靠地存储和管理的呢？

虽然现代智能手机通常会将短信存储在手机的大容量闪存中，但3GPP标准从一开始就为USIM卡设计了一套完整的短信存储和管理机制。这套机制的核心，就是EFSMS（短信存储）和EFSMSS（短信状态）这两个文件。它们共同构成了一个标准化的、独立于手机的“短信保险箱”。

我们的主角“李想”，他收到了一条重要的银行验证码短信。这条短信首先被手机接收，然后根据一系列规则，可能会被存入USIM卡的EFSMS文件中。这个过程不仅是简单的“复制粘贴”，还涉及到一系列复杂的状态管理，以确保信息的完整性和后续操作（如状态报告）的准确性。

今天，我们将一起打开这个“短信保险箱”，深入探索EFSMS和EFSMSS的设计，理解它们是如何协同工作，为这个看似简单的百年业务保驾护航的。

1. 短信的“仓库”：4.2.25 EFSMS (Short messages)

EFSMS是USIM中专门用于存储短信内容的“仓库”。它是一个结构化的文件，每一条记录都对应着一条完整的短信。

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

This EF contains information in accordance with TS 23.040 comprising short messages (and associated parameters) which have either been received by the UE from the network, or are to be used as an UE originated message.

这段原文揭示了EFSMS的核心功能：

  1. 服务关联: 它的存在与EF_UST中的服务n°10（短信存储）相关联。

  2. 双向存储: EFSMS不仅可以存储接收到的短信，还可以存储待发送的短信（草稿）。

  3. 内容标准: 存储的内容和格式，严格遵循短信的技术实现规范 TS 23.040。

1.1 文件结构与记录剖析

EFSMS是一个线性固定文件，每一条记录都是一个独立的短信“集装箱”。

表 4.2.25-1: EFSMS 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F3C’ |

| Structure | Linear Fixed |

| Record length| 176 bytes |

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

记录内容 (176 bytes)

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

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

| 1 | Status (短信状态) | M | 1 byte |

| 2 to 176 | Remainder (剩余部分) | M | 175 bytes |

逐项解读：

  • Record length: 固定为176字节。这个长度是经过精心设计的，足以容纳一条标准的最大长度短信（140字节）及其所有相关的头部参数（如发送方地址、服务中心地址等）。

  • Access Conditions: 读写都受PIN保护，确保了短信内容的私密性。

1.1.1 灵魂的1字节：Status (短信状态)

每一条短信记录的第一个字节，是它的“灵魂”，定义了这条记录的当前状态。这个字节本身就是一个微型的状态机。

Coding:

b2 b1 Meaning

X 0 free space

X 1 used space

b3 b2 b1 Meaning

0 0 1 message received …; message read

0 1 1 message received …; message to be read

1 1 1 UE originating message; message to be sent

深度解析：

  • b1 (空间占用位):

    • b1=0: free space (空闲)。表示这条176字节的记录是空的，可以用来存储新短信。

    • b1=1: used space (已占用)。

  • b3, b2 (消息类型与状态位): 当b1=1时，这两位才有意义。

    • '001' (二进制): 表示一条已读的接收短信。

    • '011' (二进制): 表示一条未读的接收短信。

    • '111' (二进制): 表示一条待发送的用户编辑短信（草稿）。

场景化举例：

  1. 李想收到一条银行验证码，手机将其存入EFSMS的第5条记录。手机会将记录5的第一个字节更新为 '07' (十六进制，二进制...0000 0111)，其中b1=1(已占用), b2=1, b3=0(接收未读)。

  2. 李想点开阅读了这条短信。手机会再次更新记录5的第一个字节为 '03' (十六进制，二进制...0000 0011)，其中b1=1(已占用), b2=0, b3=0… 等等，这里有一个编码细节，根据规范，已读是001，未读是011，所以应该是从011(3)更新到001(1)。让我们重新整理状态：001 - 已读接收； 011 - 未读接收；111 - 待发。所以状态字节的值从 '03' 变为 '01'。 (注意：原文编码 b3 b2 b1 → 0 0 1 代表 read, 0 1 1 代表 to be read. 1 1 1 代表 to be sent。这里需要非常小心地对应比特位和数值。)

  3. 李想删除了这条短信。手机会将记录5的第一个字节更新为'00'（或其他任何b1=0的值），将其标记为空闲空间，等待存储下一条新短信。

1.1.2 庞大的175字节：Remainder (短信实体)

记录中剩下的175个字节，用于存储短信的完整协议数据单元（PDU）。

Contents: This data item commences with the TS-Service-Centre-Address… The bytes immediately following … contain an appropriate short message TPDU as specified in TS 23.040…

这175字节的内容，完全遵循 TS 23.040 中定义的TPDU（Transport Protocol Data Unit）格式，它像一个“数据包裹”，里面包含了：

  • 服务中心地址 (Service Centre Address): 发送这条短信所经过的短信中心的号码。

  • 协议数据单元类型 (TPDU-Type): 标志位，定义了这是一条普通短信、状态报告还是其他类型的消息。

  • 发送方/接收方地址 (Originating/Destination Address): 对方的手机号码。

  • 协议标识符 (Protocol Identifier): 用于上层应用区分，如普通短信、SIM卡数据下载等。

  • 数据编码方案 (Data Coding Scheme): 定义了短信内容的编码格式（如7-bit ASCII, 8-bit 二进制, UCS2 Unicode）。

  • 消息体 (User Data): 短信的真正内容，最多160个7-bit字符（即140个8-bit字节）。

手机在存取EFSMS时，实际上是在对这个高度结构化的TPDU进行打包和解包。

2. 状态的追踪器：4.2.28 EFSMSS (短信状态)

EFSMS解决了短信“存哪里”的问题，而EFSMSS则解决了一个更精细的问题：“我发送的短信，对方收到了吗？”

当用户发送短信时，可以要求网络在短信成功送达后，返回一个“状态报告 (Status Report)”。EFSMSS就是专门用来存储这些状态报告，并与原始发送的短信进行关联的。

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

This EF contains status information relating to the short message service.

2.1 文件结构与核心字段

EFSMSS同样是一个线性固定文件，其设计目标是与EFSMS建立一一对应的关系。

表 4.2.28-1: EFSMSS 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F43’ |

| Structure | Linear Fixed |

| File size | 2+X bytes |

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

记录内容

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

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

| 1 | Last Used TP-MR | M | 1 byte |

| 2 | SMS “Memory Cap. Exceeded” Not. Flag | M | 1 byte |

| 3 to 2+X | RFU (Reserved for Future Use) | O | X bytes |

关键字段解读：

  • Last Used TP-MR (Last Used TP-Message-Reference):

    这是EFSMSS的核心。当手机发送一条短信时，它会为这条短信分配一个唯一的、在手机内部循环使用的引用号，称为TP-MR。这个引用号会包含在发送出去的短信PDU中。当网络返回关于这条短信的状态报告时，状态报告里会原封不动地带回这个TP-MR。

    EFSMSS的这个字段，就存储了最后一条成功发送的短信所使用的TP-MR值。

  • SMS “Memory Capacity Exceeded” Notification Flag:

    这是一个流量控制标志。如果手机的短信存储空间（无论是USIM还是手机内存）已满，无法再接收新短信，手机会设置这个标志位 (b1=0)。当存储空间被释放出来后（如用户删除了短信），手机会重置这个标志位 (b1=1)，并通过信令通知网络：“我又有地方了，可以继续发短信给我了。” 从而避免了在手机内存满期间丢失短信。

2.2 EFSMS 与 EFSMSS 的联动 - 状态报告的处理

EFSMS的“状态字节”中，有几个比特位是专门用于和状态报告联动的。

Coding: (Status byte of EFSMS)

b5 b4 b3 b2 b1 Meaning

X X 1 0 1 UE originating message; message sent to the network:

0 0 … Status report not requested

0 1 … Status report requested but not (yet) received;

1 0 … Status report requested, received but not stored in EF-SMSR;

1 1 … Status report requested, received and stored in EF-SMSR;

让我们通过李想发送一条请求状态报告的短信，来完整地看一下联动流程：

  1. 发送短信:

    • 李想编辑好短信，点击发送，并勾选了“发送报告”选项。

    • 手机在EFSMS中找到一个空闲记录（如记录8），将短信内容打包成TPDU写入。

    • 手机为这条短信分配一个TP-MR（如15）。

    • 手机将记录8的状态字节更新，标记为“待发送、已请求状态报告”，例如，状态字节的b5b4可能被设为01。

    • 手机将短信发送出去。

  2. 发送成功: 短信成功发送到短信中心后，手机会将记录8的状态字节更新为“已发送、等待状态报告”。

  3. 接收状态报告: 几秒钟后，网络发回一个状态报告，报告中包含了原始的TP-MR=15，并告知短信已成功送达对方手机。

  4. 状态更新:

    • 手机收到状态报告，解析出TP-MR=15。

    • 手机遍历EFSMS，寻找那条TP-MR为15的已发送短信（即记录8）。

    • 找到后，手机将记录8的状态字节再次更新，将b5b4设为11，表示“状态报告已收到并存储”。（注意：早期设计中，状态报告本身可能存在EF-SMSR文件，但EFSMSS的出现简化了流程）。

    • 手机UI上会显示一个“已送达”的勾号或提示。

通过EFSMS状态字节和EFSMSS中TP-MR的配合，手机得以精确地追踪每一条外发短信的“生命周期”，为用户提供了可靠的送达反馈。

总结：为基础业务构建的可靠基石

EFSMS和EFSMSS共同为短信这一基础但关键的业务，在USIM卡上构建了一套完整而可靠的后台支撑系统。

  • EFSMS：结构化的存储仓库。它通过标准化的176字节记录和精细的状态字节，不仅解决了短信的存储问题，还实现了对短信“生命周期”（未读、已读、待发、已发送等）的精细管理。

  • EFSMSS：简洁的状态追踪器。它通过记录关键的TP-MR和内存溢出标志，为状态报告的匹配和短信的流量控制提供了核心依据。

  • 高可靠性设计: 即使在手机频繁开关机、更换的场景下，存储在USIM中的短信和其状态也能得以保留，保证了信息的不丢失和状态的一致性。

尽管在李想的日常使用中，这些短信数据更多地被手机操作系统接管并存储在更大的手机闪存中，但USIM上这套标准化的EFSMS/EFSMSS机制，依然是所有手机短信功能实现的“参考设计”和“兼容性底线”。它确保了即使在最基础的功能手机上，短信服务也能可靠、稳定地运行，这正是3GPP标准生命力的体现。

FAQ环节

Q1：为什么EFSMS的记录长度是176字节，而不是短信内容上限的140字节？

A1：因为一条完整的短信PDU不仅包含用户数据（短信内容），还包含大量的“元数据”或头部信息。这176字节的设计，是为了容纳一个“最大可能”的短信PDU。其中包括：短信服务中心地址（最多12字节）、PDU类型及头部（约7字节）、发送方/接收方地址（最多12字节），以及用户数据本身（最多140字节的8位数据，或160个7位字符）。176字节为这些所有可能的部分都预留了充足的空间。

Q2：现代智能手机还会使用USIM卡来存短信吗？

A2：使用频率大大降低了。现代智能手机拥有GB级别的存储空间，通常会优先将短信存储在手机内部的数据库中，这样可以存储数万甚至数十万条短信，并提供更快的搜索和管理功能。但是，手机依然保留了读写USIM卡短信的能力。在某些特定情况下，如用户手动选择“从SIM卡导入联系人/短信”，或一些USAT增值业务需要直接与EFSMS交互时，这套机制依然会被激活。它可以被看作是一个“备份”或“兼容性”存储方案。

Q3：EFSMS和EFSMSS的状态信息有什么区别？

A3：它们管理的是不同层面的状态。EFSMS的状态字节管理的是单条短信本身的状态，如“未读”、“已读”、“待发”、“已发送”。而EFSMSS管理的是短信服务整体的状态，它不关心单条短信，只关心“最后一次发送用的引用号是什么？”以及“我的短信收件箱是不是满了？”。前者是微观管理，后者是宏观管理。

Q4：如果我发送了一条短信但没有请求状态报告，EFSMSS还有用吗？

A4：在这种情况下，EFSMSS中Last Used TP-MR字段依然会被手机更新为这条短信的TP-MR值。虽然你不会收到状态报告，但这个值仍然被记录下来了。它主要的作用是确保下一次发送短信时，手机能分配一个与最近一次不同的、新的TP-MR，避免引用号在短时间内重复而造成混淆。

Q5：EFSMSS和EF-SMSR（Short message status reports）是什么关系？

A5：这是一个规范演进的体现。在早期的规范中，EF-SMSR（服务n°11）被设计用来完整地存储收到的每一条状态报告的内容（TPDU）。而EFSMS的状态字节只提供一个简单的指示。后来发现，对于大多数应用场景，手机只需要知道“状态报告已收到”这个结果，而无需在USIM中保存报告的完整内容。因此，EFSMSS（作为服务n°10的一部分）被引入，通过更简单的Last Used TP-MR和EFSMS状态位的联动，简化了状态追踪。在现代USIM中，EF-SMSR的使用已变得非常少见。

关系图谱