51学通信

深度解析 3GPP TS 31.102：4.2.83 EFPSISMS (分组域短信状态)

16分钟阅读

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

深度解析 3GPP TS 31.102：4.2.83 EFPSISMS (分组域短信状态)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.83 EFPSISMS (PSISMS an SMSoIP status)”的核心章节，旨在为读者深入剖析随着短信业务向全IP化演进，USIM卡是如何通过EFPSISMS这个精巧的“状态指示器”，来记录和管理通过PS域（分组交换）发送短信时的状态信息，从而确保这一传统业务在IP时代的可靠性。

在我们之前的探索中，EFCPSMS文件为我们揭示了短信发送路径从CS域向PS域演进的“偏好开关”。当手机根据EFCPSMS的指示，决定优先通过PS域发送短信时，一个新的问题随之而来：如何像CS短信那样，有效地追踪这些“IP化”短信的状态？例如，网络是否已成功接收？是否需要网络返回状态报告？

为了解决这个问题，并为后续更高级的“IP短信（SMSoIP）”提供一个标准化的状态记录机制，3GPP规范设计了EFPSISMS文件。

EFPSISMS，可以理解为 Packet Switched Indication for SMS，即“分组域短信指示”。它的核心使命，就是专门为通过PS域发送的短信，记录其特有的状态信息。它不像EFSMS那样存储短信的完整内容，而是像一个“补充状态标签”，与EFSMS中的短信记录一一对应。

1. “IP短信的状态标签”：EFPSISMS的核心价值

EFPSISMS的核心价值在于，它为USIM的短信管理体系，打上了一个关键的“IP化补丁”，使其能够原生支持和管理通过PS域发送的短信的状态，特别是与状态报告（Status Report）相关的请求。

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

This EF contains status information for mobile originated short messages to be sent via the PS domain.

这段原文揭示了EFPSISMS的关键特性：

  1. 服务关联: 它的存在与EF_UST中的服务n°67（SMS over PS support）紧密绑定。可以说，只要USIM支持PS域短信，就必须有EFPSISMS来管理其状态。

  2. 功能专一: 只存储MO（移动始发）短信在PS域的状态信息。

  3. 补充角色: 它不是一个独立的短信仓库，而是EFSMS的补充。

EFPSISMS与EFSMS的联动机制

EFPSISMS与EFSMS之间，存在着一种隐式的、基于记录号的一一对应关系。

EFPSISMS被设计为一个线性固定文件，其记录数（number of records）必须与EFSMS（短信仓库）的记录数完全相同。

这意味着：

  • EFPSISMS的第N条记录，是专门用来存储EFSMS第N条记录所对应短信的PS域状态的。

工作流程：通过PS域发送短信

  1. 准备发送: 我们的主角“李想”编写完一条短信，并勾选了“请求发送报告”。他的手机根据EFCPSMS的偏好，决定通过PS域发送。

  2. 写入EFSMS: 手机在EFSMS中找到一个空闲记录（例如，第12号记录），将短信的完整TPDU内容写入。同时，将该记录的状态字节标记为“待发送”。

  3. 写入EFPSISMS: 这是关键的一步。由于这次是通过PS域发送，并且请求了状态报告，手机会同时更新EFPSISMS的同样是第12号记录。它会将这条记录中的一个“状态报告请求标志位”置为1。

  4. 发送与状态更新:

    • 手机通过PS数据通道将短信发送出去。

    • 发送成功后，手机更新EFSMS第12号记录的状态为“已发送”。

    • 当网络返回状态报告后，手机会根据我们之前在EFSMSR章节学到的机制进行处理，并最终更新EFSMS的状态为“状态报告已收到”。

  5. 记录清除: 当李想删除EFSMS中的第12号短信时，手机在将其标记为空闲的同时，也应该一并清除EFPSISMS中第12号记录的内容（将其标记为空闲）。

通过这个流程，EFPSISMS就像是给每一条EFSMS记录贴上了一个“PS域专属”的附注标签，专门记录那些在CS域短信中不存在或不常见的状态信息。

2. 精简的“状态位集合”：EFPSISMS文件结构与编码剖析

EFPSISMS的设计极为精简，每一条记录只用了1个字节，来承载最核心的状态信息。

2.1 文件结构

表 4.2.83-1: EFPSISMS 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6FDD’ (注意：此处的ID ‘6FDD’与EFCPSMS和EFIMS的示例ID相同，再次表明ID在实际部署中是动态的，以EFDIR为准。此处我们关注功能) |

| Structure | Linear Fixed |

| Record length| 1 byte |

| Update activity| High |

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

记录内容 (1 byte)

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

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

| 1 | PSISMS Indicators (PSISMS指示器) | M | 1 byte |

关键特性解读：

  • Structure: Linear Fixed。这个结构是实现与EFSMS记录号一一对应的基础。

  • Record length: 1字节。每一条短信的PS域状态，都被高度浓缩在这8个比特位中。

  • Update activity: High。每次通过PS域发送短信，都可能需要更新这个文件。

  • Access Conditions: 读写都需要PIN权限，与EFSMS保持一致，共同保护短信相关的隐私信息。

2.2 编码的核心：1字节的指示器

Coding:

  • b1=0: Status Report for this SM-over-IP is not requested.
  • b1=1: Status Report for this SM-over-IP is requested.
  • b2=0: The record is free.
  • b2=1: The record is used.

Bits b3 to b8 are reserved for future use.

这个字节的编码非常清晰：

  • b2 (记录使用状态位):

    • b2=0: free (空闲)。表示对应的EFSMS记录中没有PS域相关的短信。

    • b2=1: used (已使用)。

  • b1 (状态报告请求位): 只有当b2=1时，此位才有意义。

    • b1=0: 未请求状态报告。

    • b1=1: 已请求状态报告。

场景化举例（编码）：

回到李想通过PS域发送短信并请求回执的例子。

  1. 写入EFSMS第12号记录。

  2. 更新EFPSISMS第12号记录:

    • 因为要使用这条记录，所以b2=1。

    • 因为请求了状态报告，所以b1=1。

    • 因此，EFPSISMS第12号记录的1个字节被写入了二进制值 ...0000 0011，即十六进制的'03'。

当手机需要检查某条已发送短信（如第12条）是否曾请求过PS域的状态报告时，它只需直接读取EFPSISMS的第12号记录，检查其b1位即可，而无需去解析EFSMS中复杂的TPDU内容。

3. SMSoIP的“敲门砖”

规范的标题和编码描述中，都提到了“SM-over-IP”。EFPSISMS的设计，不仅仅是为了解决3G时代“SMS over PS”的问题，更是为4G/5G时代更纯粹的“SMS over IP (SMSoIP)”——即通过IMS发送短信——预留了状态管理的接口。

EFPSISMS中的“状态报告请求位”，可以直接被手机的IMS客户端用来决定，在构建发送SMSoIP的SIP MESSAGE信令时，是否要加入请求送达报告的相关头域。

EFPSISMS因此成为了连接传统SMS状态管理与现代IMS消息状态管理的“桥梁”。它使得USIM的短信管理体系，能够平滑地向上兼容全IP化的消息业务。

总结：为IP化短信量身定制的“状态便签”

EFPSISMS文件是USIM为适应短信业务IP化演进而设计的一个精巧的“补充模块”。它通过一个与主短信仓库（EFSMS）严格对应的状态文件，解决了在PS域和IP域下管理短信状态的特殊需求。

  • 实现了状态的专门化管理: 将PS域特有的状态信息（如状态报告请求）从通用的EFSMS记录中分离出来，使得EFSMS的核心状态字节可以保持简洁和通用，而EFPSISMS则可以专注于处理IP化带来的新需求。

  • 高效的一一对应机制: 通过强制EFPSISMS与EFSMS具有相同的记录数，并使用记录号进行隐式链接，实现了一种极为高效、低开销的“主-从”数据关联模型。

  • 前瞻性的设计: 在设计之初就考虑了对SM-over-IP的支持，使其不仅仅是一个服务于3G PS短信的“临时补丁”，而成为了USIM短信体系能够平滑演进到4G/5G IMS时代的关键一环。

对于李想而言，他可能只是在手机设置中看到了一个“通过PS域发送短信”的开关。但他不知道的是，当他启用这个开关后，他发送的每一条短信，其背后都有EFPSISMS这个小小的“状态便签”在被同步更新，精确地记录下它在IP世界中的“旅行”状态，确保了即使换了条“路”，回执和状态依然能被准确地追踪。

FAQ环节

Q1：EFPSISMS和EFSMS中的状态字节有什么区别？EFSMS自己不是已经有状态了吗？

A1：这是一个很好的问题，触及了设计的核心。EFSMS的状态字节（第一个字节）管理的是通用的、跨越CS和PS域的短信生命周期状态，如“未读”、“已读”、“待发”、“已发送”。而EFPSISMS则专注于记录PS域特有的、或者在PS域中需要被特别标识的状态。最典型的就是“是否请求状态报告”。虽然CS短信也可以请求状态报告（其信息包含在TPDU中），但为PS短信专门设立一个状态位，可以大大简化手机在决定发送路径和构建PDU时的逻辑。手机只需检查EFPSISMS的一个比特，而无需解析EFSMS的整个TPDU。

Q2：为什么EFPSISMS的记录长度只有1个字节？感觉能记录的信息太少了。

A2：这是“少即是多”的设计哲学。EFPSISMS的定位是一个高频更新的、轻量级的状态指示器，而不是一个信息仓库。将记录长度限制为1字节，可以最大限度地减少USIM的写入开销和存储占用。在这个1字节中，规范只定义了最核心的2个比特位（使用状态和报告请求），剩下的6个比特则作为“未来的弹药库”（RFU），可以在不改变文件结构的情况下，随时被启用以支持新的PS域短信特性。

Q3：如果我禁用了“通过PS域发送短信”，EFPSISMS文件还有用吗？

A3：如果你的手机完全只通过CS域发送短信，那么EFPSISMS文件将不会被手机更新或读取，处于“休眠”状态。但是，只要USIM卡的EF_UST中服务n°67被激活，这个文件就必须存在，以确保手机在任何时候（例如，用户突然开启PS域偏好）都能找到它并正确执行逻辑。

Q4：EFPSISMS和EFSMSR（短信状态报告存储）有什么关系？

A4：它们处理的是状态报告流程的不同环节。

  • EFPSISMS: 在短信发送前，记录“是否要请求”状态报告的意图。

  • EFSMSR: 在短信发送后，用于存储网络实际返回的状态报告的内容。

EFPSISMS是“申请表”，EFSMSR是“回执单”。

Q5：EFPSISMS中的ID 6FDD和EFCPSMS的ID一样，这是怎么回事？

A5：这是3GPP TS 31.102这份规范中一个长期存在的、众所周知的编辑错误。在规范的表格中，多个文件的示例Identifier被错误地写成了同一个值。在实际的USIM卡实现中，每一个文件都必须有一个唯一的文件标识符（File ID）。这个唯一的ID是由卡商在个人化阶段，根据EFDIR（目录文件）中的规划来分配的。因此，我们应该以每个文件有唯一ID为准，而不必纠结于规范示例中的这个笔误。我们解读的重点是每个文件独特的功能和结构。

关系图谱