RP Message Type Indicator

Description

The RP-MTI (RP Message Type Indicator) is a critical information element within the Relay Protocol (RP) layer, which operates as part of the SMS over IP (SMS-IP) architecture defined by 3GPP. The RP layer is responsible for the reliable transfer of short messages between a Short Message Service Centre (SMSC) and a Mobile Station (MS) or User Equipment (UE), particularly when the message traverses the IP-based IMS network. The RP-MTI is a mandatory field within the RP header, and its value dictates the format and interpretation of the entire RP message. It essentially acts as a command identifier, telling the receiving entity—such as an IP Short Message Gateway (IP-SM-GW) or the UE itself—how to process the associated payload.

Technically, the RP-MTI is a code point within the RP protocol data unit (PDU). When an entity constructs an RP message, it sets the RP-MTI to a predefined value corresponding to the message's purpose. For instance, an RP-MTI value may indicate an RP-DATA message, which carries the actual SMS user data (the text or binary content). Another value indicates an RP-ACK, which is a positive acknowledgment for a previously received RP-DATA. Conversely, an RP-ERROR message, indicated by its specific RP-MTI, signals a failure in processing a previous RP command. The receiving network node parses this field first to determine the subsequent parsing logic for the rest of the RP message, including the handling of other fields like RP-SMEA (the sender's address) and RP-UI (the user data payload).

Its role is foundational for session management and error handling in SMS delivery. In the IMS-based SMS architecture, the RP layer messages are encapsulated within SIP (Session Initiation Protocol) messages for transport. The IP-SM-GW performs interworking between the legacy MAP (Mobile Application Part)/SS7-based SMS signaling and the SIP-based IMS signaling. When the IP-SM-GW receives an SMS from the SMSC via MAP, it constructs an appropriate RP message (e.g., RP-DATA), sets the RP-MTI accordingly, and embeds it within a SIP MESSAGE request to be routed to the UE. The UE's IMS client extracts the RP message, reads the RP-MTI, and based on its value, either processes the SMS for display, generates an RP-ACK to send back via SIP, or handles an error condition. This ensures that the end-to-end SMS procedures, including delivery reports and failure notifications, function correctly over the packet-switched domain.

Purpose & Motivation

The RP-MTI was introduced to provide a structured and unambiguous mechanism for identifying different procedural messages within the Relay Protocol layer, which is essential for the interworking of traditional circuit-switched SMS with the IP Multimedia Subsystem (IMS). Prior to IMS-based SMS, SMS delivery relied heavily on the SS7 signaling network and the MAP protocol, where message types were implicitly understood within the context of MAP operations. However, with the migration to all-IP networks (the IP Multimedia Core Network Subsystem, or IMS), there was a need to transport SMS signaling transparently over SIP, a session control protocol not natively designed for SMS. The RP layer, and specifically the RP-MTI, was defined to preserve the stateful, command/response nature of SMS delivery within the stateless-oriented SIP messaging framework.

Its creation solved the problem of how to signal the intent of an SMS-related message between the network and the UE when using SIP as a transport. Without a clear indicator like the RP-MTI, a SIP entity would not be able to distinguish between a message carrying new SMS content, a delivery acknowledgment, or a failure report. This would break essential SMS features like delivery reports and retry mechanisms. The RP-MTI enables the IP-SM-GW and the UE to engage in the same logical RP dialogue that would occur in a circuit-switched network, but now encapsulated within SIP dialogues. This allows for the seamless convergence of messaging services, supporting the operator's transition to all-IP networks while maintaining backward compatibility with the vast existing SMS infrastructure and user expectations.