Description
Message Waiting Indication (MWI) is a standardized supplementary service defined within the 3GPP framework, primarily for IP Multimedia Subsystem (IMS) and Circuit-Switched (CS) networks. Its core function is to inform a user equipment (UE) that a new message, such as a voicemail or a multimedia message, has been deposited in a network-based mailbox and is awaiting retrieval. The indication itself is a network-triggered notification, not the message content. Architecturally, MWI involves several network entities. The message depository (e.g., a voicemail server or Multimedia Messaging Service Centre - MMSC) detects a new message for a subscriber. It then signals this event, typically via the IP Multimedia Subsystem (IMS) or the CS core, to a service control function. In IMS, this often involves the Application Server (AS) hosting the MWI service. The AS is responsible for generating and managing the MWI subscription and notifications. The notification is then delivered to the user's UE using specific protocols. For IMS-based MWI, the UE subscribes to the MWI event package as defined in RFC 3842, using the SIP SUBSCRIBE method directed towards the MWI AS. The AS then sends SIP NOTIFY messages to the UE when the message-waiting status changes (e.g., new message arrived or all messages read). The NOTIFY message contains an XML body that details the message waiting status, such as the number of new and old messages. For CS networks, MWI can be indicated via mechanisms like a Feature Indication in call control signaling or specific tones. The UE, upon receiving a valid MWI notification, activates a local indicator (like an icon on the screen) to alert the user. The service is tightly integrated with other IMS services like Voice over LTE (VoLTE) and Rich Communication Services (RCS), ensuring a consistent messaging experience across different access networks. Security and privacy are maintained as the notification is part of the authenticated SIP dialog between the UE and the AS.
Purpose & Motivation
MWI was created to solve the fundamental user experience problem in telephony and messaging systems: a user had no way of knowing if they had received a new voicemail or message without manually checking their mailbox. This was inefficient and led to delayed message retrieval. In the era of basic mobile telephony, simple stutter dial tones on the line were sometimes used as a primitive MWI, but this was not standardized or reliable across networks and devices. The formal standardization of MWI within 3GPP, starting in Release 7 with IMS, provided a unified, interoperable mechanism. It addressed the limitations of proprietary vendor solutions, enabling seamless service roaming. The motivation was to enhance the value of network-based messaging services (voicemail, MMS) by making them proactive, thereby increasing their usage and utility. As networks evolved to all-IP architectures with IMS, MWI became a crucial component for service parity with legacy CS networks and for enabling advanced multimedia messaging scenarios. It ensures that users receive immediate, visual confirmation of waiting messages, integrating seamlessly with the phone's native interface, which is essential for modern communication services.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (9 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-7, normative work from Rel-15.
In Release 15, the Message Waiting Indication (MWI) function was newly introduced for use over the IP Multimedia Core Network (IM CN) subsystem. This release also specified support for including the Origination-Id in the INVITE and MESSAGE methods. Furthermore, it defined the interworking for the Connected subaddress Information Element carried within ISUP CON messages.
In Release 16, the primary new specification for the MWI (Message Waiting Indication) function clarified its interaction with other IMS supplementary services, particularly establishing that the Communication Waiting (CW) service has no impact on Communication Forwarding Unconditional (CFU) and that a forwarded communication can itself result in the invocation of the communication waiting service. Furthermore, it was specified that if the terminating party has activated the Anonymous Communication Rejection (ACR) service, then the ACR service shall take precedence over the Communication Waiting service.
In Release 18, the enhancement for Message Waiting Indication (MWI) introduced a specific **indication to the NAS layer for a Mobile Terminated (MT) call**. This provides a lower-layer notification to the device when a call is waiting, which is particularly useful for scenarios where the existing user interface might otherwise be unable to present new information to the user. This addition operates within the framework of the Communication Waiting (CW) service, ensuring the user can be informed of an incoming communication request when no resources are available.
- Indication to the NAS layer for an MT call TS 24.173CR0151
In Release 19, the MWI (Message Waiting Indication) function was enhanced with new capabilities for network-initiated data channel setup and for operation in a standalone data channel scenario. These updates provided more flexible and efficient mechanisms for delivering waiting indications to the user. Furthermore, support for data channel multiplexing capability negotiation and indication was introduced, optimizing resource usage for MWI and related services.
Explore further
Broader topics and technologies where MWI plays a role.
Defining Specifications
3GPP specifications that define or reference MWI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 22.173 vk00 | IMS Multimedia Telephony Service Definition | Rel-20 |
| TS 22.273 v1700 | IMS Multimedia Telephony with PSTN/ISDN Simulation | Rel-7 |
| TS 22.401 v1800 | Videotelephony Service Requirements for NGN | Rel-8 |
| TS 24.173 vj00 | Multimedia Telephony Service and Supplementary Services in IMS | Rel-19 |
| TS 24.186 vj60 | IMS Data Channel applications | Rel-19 |
| TS 24.196 vj00 | Enhanced Calling Name (eCNAM) Stage 3 Protocol | Rel-19 |
| TS 24.406 v810 | Message Waiting Indication (MWI) Protocol | Rel-8 |
| TS 24.606 vj00 | MWI Service Protocol Description | Rel-19 |
| TS 29.163 vj00 | Interworking between 3GPP IM CN and CS networks | Rel-19 |
| TS 29.165 vj10 | Inter-IMS Network to Network Interface (NNI) | Rel-19 |
| TS 29.364 vj10 | IMS AS Service Data Descriptions | Rel-19 |
| TS 29.864 v801 | Application Server Service Data Definition for IMS Telephony | Rel-8 |
| TS 32.275 vj00 | MMTel Charging Specification | Rel-19 |
| TS 32.850 ve00 | IMS Charging Correlation Methods Study | Rel-14 |