51学通信

深度解析 3GPP TS 31.102：4.2.56 EFMBDN & 4.2.57 EFMWIS (多媒体通信的精细化控制)

17分钟阅读

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

深度解析 3GPP TS 31.102：4.2.56 EFMBDN & 4.2.57 EFMWIS (多媒体通信的精细化控制)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.56 EFMBDN (Mailbox Dialling Numbers)”和“4.2.57 EFMWIS (Message Waiting Indication Status)”的核心章节，旨在为读者深入剖析在传统的语音信箱和新兴的多媒体消息业务中，USIM卡是如何通过这两个专门的文件，既为用户提供了便捷的“一键听取留言”入口，又实现了一个标准化的、跨业务的消息等待状态管理机制。

在我们之前的探索中，已经涵盖了语音通话、短信、数据连接等多种通信方式。然而，还有一类重要的异步通信服务——语音信箱 (Voicemail) 和各类多媒体消息（视频留言、彩信等）。当我们的主角“李想”因为开会而错过一个重要来电，对方给他留下了一段语音留言时，他的手机是如何知道有新留言，并且他又该如何便捷地去听取这段留言呢？

为了解决这两个核心问题——“如何去”和“有没有”——3GPP规范在USIM中设计了EFMBDN和EFMWIS这两个文件。

  • EFMBDN (Mailbox Dialling Numbers): “语音信箱拨号号码”，它解决了“如何去”的问题。它就像一个预存的快捷方式，专门用于存储拨打各类“信箱”的号码。

  • EFMWIS (Message Waiting Indication Status): “消息等待指示状态”，它解决了“有没有”的问题。它像一个“状态面板”，用一系列开关来记录不同类型的消息（语音、传真、邮件等）是否有新消息等待处理。

今天，我们将一同探索这对服务于异步消息业务的“搭档”，理解它们是如何协同工作，为用户提供一个清晰、便捷的留言管理体验的。

1. “一键听留言”：4.2.56 EFMBDN (语音信箱拨号号码)

EFMBDN的核心价值在于，为用户提供一个由运营商预置的、标准化的、用于访问各类消息信箱的号码簿。

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

This EF contains Mailbox Dialling Numbers and/or supplementary service control strings.

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

  1. 服务关联: 它的存在与EF_UST中的服务n°34相关联。

  2. 功能核心: 存储用于拨打**“信箱 (Mailbox)”**的号码。这个“信箱”是一个广义的概念，最常见的是语音信箱，但也可以是视频信箱、传真信箱等。

与EFSDN (业务拨号号码) 的区别：

EFSDN是一个通用的业务号码簿，可以存储任何运营商服务。而EFMBDN的定位更专一，只专注于存储与“信箱”类业务相关的号码。在手机UI上，EFMBDN中的号码通常会与拨号盘上的“1”键长按，或者专门的“语音信箱”按钮绑定，实现“一键拨入”。

EFMBDN文件结构与编码剖析

EFMBDN在结构上再次采用了我们已经非常熟悉的电话本记录格式，与EFADN, EFFDN, EFSDN一脉相承。

表 4.2.56-1: EFMBDN 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F4B’ |

| Structure | Linear Fixed |

| Record length| X+14 bytes |

| Update activity| Low |

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

关键特性解读：

  • Access Conditions: UPDATE权限是PIN。这意味着，虽然运营商通常会预置好语音信箱号码，但也允许用户在知道PIN码的情况下自行修改或添加。例如，如果李想更换了第三方语音信箱服务，他可以在手机设置中手动更改这个号码。

  • 记录结构复用: EFMBDN的记录结构（Alpha-tag, Number, TON/NPI等）与EFADN等文件高度一致，同样使用了独立的扩展文件EFEXT2来支持长号码。

场景化举例：

运营商在李想的USIM卡的EFMBDN文件中，预置了第一条记录：

  • Alpha ID: “语音信箱”

  • Dialling Number: BCD编码的12599

当李想长按手机拨号盘上的“1”键时：

  1. 手机的拨号应用被设计为触发“拨打语音信箱”的动作。

  2. 手机自动读取EFMBDN文件的第一条记录。

  3. 手机提取出号码12599并发起呼叫。

  4. 李想就接通了自己的语音信箱，可以听取留言了。

2. “状态指示灯”：4.2.57 EFMWIS (消息等待指示状态)

EFMWIS是整个留言提醒机制的核心。它就像手机状态栏上那个小小的语音信箱图标背后的“数据源”，用一组比特位的亮灭，来精确地告知手机，当前有哪些类型的消息正在“排队等待”。

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

This EF contains the message waiting status.

EFMWIS的核心价值与工作机制

EFMWIS的核心价值在于提供一个标准化的、跨业务类型的“消息等待”状态存储机制。

工作机制：

  1. 网络通知: 当有新的语音留言存入李想的语音信箱时，网络会向他的手机发送一条特殊类型的短信（SMS-MWI, Message Waiting Indication）或者通过其他信令（如SIP NOTIFY消息）。这条通知中明确指出：“你有一条新的语音消息”。

  2. USIM更新: 手机接收到这个通知后，它要做的第一件事，就是更新EFMWIS文件。它会将文件中对应“语音消息 (Voice Mail)”的那个比特位置为1。同时，它可能还会更新该比特位关联的“新消息计数器”。

  3. UI联动: 手机的操作系统会监控EFMWIS文件的变化（或接收来自底层协议栈的相应事件）。一旦检测到“语音消息”位变为1，它会立即在手机的状态栏上点亮语音信箱图标，并在拨号应用上显示一个红点角标。

  4. 用户处理: 李想看到提示后，长按“1”键拨打EFMBDN中的号码，听取了留言并将其删除。

  5. 状态清除: 语音信箱系统检测到所有新留言都已被处理，会再次向李想的手机发送一条“状态更新”通知，告知“已无新语音消息”。

  6. USIM重置: 手机收到这条新通知后，会再次更新EFMWIS，将“语音消息”的比特位重置为0，并将计数器清零。

  7. UI图标熄灭: 状态栏上的语音信箱图标随之消失。

文件结构与编码剖析

EFMWIS是一个设计精巧的线性固定文件，每一条记录都代表一类消息的等待状态。

表 4.2.57-1: EFMWIS 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F4C’ |

| Structure | Linear Fixed |

| Record length| 4 bytes |

| Update activity| High |

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

记录内容 (4 bytes)

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

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

| 1 | Message Waiting Indication status (MWI状态) | M | 1 byte |

| 2 | Number of waiting messages (等待消息数量) | O | 1 byte |

| 3 | Number of new messages (新消息数量) | O | 1 byte |

| 4 | RFU | M | 1 byte |

关键字段解读：

  • MWI Status (1 byte): 这是状态字节，其比特位的含义在不同的记录中是不同的。

    Each record shall be associated with a message type.

    规范规定，EFMWIS的每一条记录都应关联一种消息类型。虽然规范本身没有强制规定记录号与消息类型的映射，但通常有一个事实上的标准：

    • 记录1: 语音信箱 (Voice Mail)

    • 记录2: 传真 (Fax)

    • 记录3: 电子邮件 (E-mail)

    • 记录4: 其他消息 (Other)

    • 记录5: 视频留言 (Videomail)

    状态字节的b1位就是“开关”：b1=1表示有该类型的新消息，b1=0表示没有。

  • Number of waiting/new messages (2 bytes):

    这两个字节分别用于存储“总的未读消息数”和“本次新收到的消息数”。这为手机UI提供了显示更丰富信息（如“您有3条新留言，共5条未读留言”）的能力。

场景化举例（深入编码）：

李想有2条未读的语音留言，此时又来了一条新的。

  1. 网络下发MWI通知。

  2. 手机读取EFMWIS的第一条记录（语音信箱记录）。

  3. 手机将这条4字节的记录更新为：

    • 字节1 (MWI Status): b1置为1，表示有新消息。值为'01'。

    • 字节2 (Waiting messages): 更新为3 (总共有3条未读了)。值为'03'。

    • 字节3 (New messages): 更新为1 (本次来了1条)。值为'01'。

手机UI据此可以在角标上显示“1”，并在点开详情时显示“共3条未读”。

总结：为异步消息构建的“提醒”与“入口”

EFMBDN和EFMWIS这对文件，共同为USIM卡上的异步消息类业务，构建了一套完整的、从“状态提醒”到“便捷访问”的闭环解决方案。

  • EFMBDN：提供了“如何去”的便捷入口。它将复杂的服务号码抽象为一个简单的、可由手机UI（如长按“1”）直接调用的快捷方式，极大地提升了用户访问语音信箱等业务的便利性。

  • EFMWIS：提供了“有没有”的权威状态。它通过一个标准化的、跨业务类型的状态位和计数器，为手机提供了一个可靠的、用于驱动UI提醒（如图标、角标）的数据源，确保了用户不会错过任何重要留言。

  • 解耦与协同: 手机的UI表现（图标）与底层的信令通知（MWI短信）被解耦，EFMWIS作为中间的“状态机”起到了承上启下的作用。EFMBDN则与这个状态机协同，为用户提供了处理提醒的直接行动路径。

对于李想而言，状态栏上那个时而出现、时而消失的小小磁带图标，以及长按“1”就能接通留言信箱的便捷操作，其背后正是EFMBDN和EFMWIS这两个文件在与手机、网络进行着一场场精准、静默的“状态同步”和“号码指引”。

FAQ环节

Q1：EFMBDN和我的个人电话本（EFADN）有什么关系？我可以直接把语音信箱号码存在EFADN里吗？

A1：可以，但效果不同。你可以把语音信箱号码12599作为一个普通联系人存在EFADN里。但这样做，你将失去“一键拨入”的便利性。手机的长按“1”键、专门的语音信箱按钮等快捷操作，是硬编码为去读取EFMBDN的。EFMBDN是这个功能的标准化入口，而存在EFADN里只是一个普通的收藏。

Q2：EFMWIS的状态是谁来更新的？手机还是网络？

A2：EFMWIS的状态是由手机（ME）来更新的，但更新的触发信号来自于网络。网络通过下发MWI通知，告知手机“状态变了”。手机接收到这个“命令”后，负责执行将EFMWIS文件中的相应比特位置位或清零的“动作”。USIPM卡本身不直接与网络交互，它只响应来自手机的读写命令。

Q3：EFMWIS可以支持多少种消息类型？

A3：EFMWIS是一个线性固定文件，理论上，它有多少条记录，就可以支持多少种消息类型。规范本身没有限制记录的数量，这取决于运营商在个人化USIM卡时为该文件分配了多大的空间。通常预置5-6条记录（语音、传真、邮件、视频等）已经足以覆盖绝大多数常见业务。

Q4：为什么EFMBDN和EFMWIS的更新权限都是PIN，而不是ADM？

A4：这体现了功能的灵活性。

  • 对于EFMBDN，虽然运营商会预置一个号码，但用户可能使用第三方的语音信箱服务，标准需要提供一个让用户能自行修改号码的途径。

  • 对于EFMWIS，状态的更新是手机响应网络信令的正常操作，必须允许手机进行写操作。

使用PIN码作为保护，是在保证基本安全（确认是机主授权的操作）和提供必要灵活性之间取得的平衡。

Q5：在5G时代，IMS中也有语音信箱，这套机制还适用吗？

A5：这套机制的原理依然适用，但实现方式可能有所不同。在IMS网络中，消息等待的通知（MWI）更多地是通过SIP协议的NOTIFY消息来传递，而不是传统的MWI短信。手机的IMS客户端在收到NOTIFY消息后，依然可以去更新USIM卡中的EFMWIS文件，从而与手机的全局UI（如状态栏图标）进行联动。同样，拨打语音信箱也可能通过配置一个特定的SIP URI来实现，但手机依然可以将其与EFMBDN或长按“1”键进行绑定。EFMBDN和EFMWIS提供的是一个独立于底层网络技术（CS或IMS）的、标准化的上层业务逻辑接口，这正是其生命力所在。

关系图谱