The User Data Header (UDH) is an optional binary structure within the TP-User-Data (TP-UD) field of Short Message Service (SMS) Transfer Protocol Data Units (TPDUs), such as SMS-DELIVER and SMS-SUBMIT, as specified in 3GPP TS 23.040.[1] It is indicated by setting the TP-User-Data-Header-Indicator (TP-UDHI) bit in the TPDU and precedes the actual user data to provide control information and metadata for processing the message.[1] The UDH enables enhanced SMS functionalities beyond basic text delivery, including message segmentation and reassembly, without forming part of the visible message content.[1]
The structure of the UDH is defined by a User Data Header Length (UDHL) octet, which specifies the total length of the header in octets (excluding the UDHL itself), followed by one or more Information Elements (IEs) that can appear in any order.[1] Each IE comprises an IE Identifier (IEI) octet to denote its type, an IE Data Length (IEDL) octet indicating the length of the associated data, and the variable-length IE Data (IED) containing the specific information.[1] The overall length of the TP-UD field, including the UDH and user data, is adjusted based on the data coding scheme (e.g., 7-bit, 8-bit, or UCS2 encoding), ensuring compatibility with GSM, UMTS, LTE, and 5G networks.[1]
Key uses of the UDH include facilitating concatenated short messages by linking parts via reference numbers and sequence indicators, allowing a single long message (up to approximately 1,530 characters) to be split and reassembled.[1] It also supports application port addressing to route messages directly to specific ports on the recipient device, enabling interactions with applications like push notifications or simple games.[1] Additionally, the UDH accommodates Enhanced Messaging Service (EMS) features, such as text formatting (e.g., bold or italic), embedded images, animations, and sounds, as well as special indications like voicemail alerts or SMSC control parameters.[1] These capabilities, defined since the original GSM 03.40 standard and evolved through 3GPP releases, remain integral to global SMS infrastructure for both consumer and enterprise applications.[1]
Fundamentals
Definition and Purpose
The Short Message Service (SMS) is a store-and-forward text messaging service that enables the transfer of short messages between mobile stations and external entities in GSM, UMTS, LTE, and 5G networks via a Short Message Service Center (SMSC).[2]
The User Data Header (UDH), also known as the TP-User-Data-Header, is a binary metadata structure positioned at the beginning of the TP-User-Data field within an SMS Transfer Protocol Data Unit (TPDU) in GSM/3GPP networks.[2] It is defined in 3GPP TS 23.040 and is present only when the TP-User-Data-Header-Indicator (TP-UDHI) bit is set to 1 in the TPDU, signaling to receiving entities that the initial octets of the user data contain this header rather than message content.[2]
The primary purpose of the UDH is to convey control information and metadata for advanced SMS processing, such as message segmentation for longer content, formatting for enhanced features like EMS (Enhanced Message Service), or specific routing instructions, without modifying the underlying SMS text protocol.[2] This allows SMS networks to support functionalities beyond basic text delivery while maintaining compatibility with legacy systems. However, including the UDH reduces the available payload for user content by consuming initial octets; for example, in 7-bit default alphabet mode, the maximum capacity drops from 140 octets (equivalent to 160 characters) to 134 octets (approximately 153 characters) when a typical 6-octet UDH is used.[2]
A representative example is the UDH for a concatenated SMS segment, which uses a 6-octet structure (UDHL octet set to 05 in hexadecimal, followed by information elements for concatenation identifier 00, data length 03, and three data octets specifying a reference number, total parts, and sequence number).[2] This header instructs the receiving device to collect and reassemble multiple segments using the shared reference number, skipping the UDH octets entirely so they are not interpreted as part of the text message.[2]
Historical Development
The User Data Header (UDH) was introduced as part of the Short Message Service (SMS) specifications in the early 1990s within the Global System for Mobile Communications (GSM) framework, specifically in the ETSI GSM 03.40 standard, which defined the technical realization of point-to-point SMS.[3] This initial formulation enabled the inclusion of optional header information in SMS user data to support features like application port addressing, laying the groundwork for enhanced message processing beyond basic text; the full UDH structure, including TP-UDHI, appeared in version 5.0.0 (December 1995).[4] Developed under the European Telecommunications Standards Institute (ETSI), the UDH facilitated early SMS enhancements aimed at Europe-wide paging and interoperability, aligning with the broader GSM Phase 2 specifications that emphasized digital mobile communication standardization.[5]
Adoption of UDH occurred alongside the rollout of 2G GSM networks, with the first commercial GSM deployment in Finland in 1991 and the inaugural SMS transmission in 1992, marking the practical integration of UDH into operational mobile systems.[3] By the mid-1990s, as GSM expanded globally under ETSI and International Telecommunication Union (ITU) influence, UDH became essential for ensuring SMS interoperability across diverse networks, supporting binary and structured data formats that transcended simple alphanumeric messaging.[6]
With the formation of the 3rd Generation Partnership Project (3GPP) in 1998, the GSM 03.40 specification evolved into 3GPP TS 23.040, undergoing iterative updates to accommodate advancing mobile technologies.[7] A key milestone came in Release 4 (2001), which introduced enhancements for the Enhanced Messaging Service (EMS), leveraging UDH to embed simple multimedia elements like bitmaps and melodies within SMS, thereby extending its utility for richer content delivery.[8] In 3G Universal Mobile Telecommunications System (UMTS) networks, standardized under 3GPP Release 99 (1999–2000), UDH saw expansions for robust binary data support, enabling more efficient handling of non-text payloads in higher-bandwidth environments while maintaining compatibility with 2G infrastructure.[9]
UDH played a pivotal role in the precursors to Multimedia Messaging Service (MMS) during 1999–2002, where it was used in SMS-based gateways for port addressing to MMS centers, allowing early interoperability between SMS and emerging multimedia systems before full MMS protocols were widespread. As mobile networks progressed to 4G Long-Term Evolution (LTE) in 3GPP Release 8 (2008) and 5G New Radio in Release 15 (2018), UDH persisted through backward compatibility provisions in TS 23.040, ensuring seamless SMS support over IP-based cores and legacy fallbacks, with refinements in Releases 16–18 (up to 2024) for integration with modern services like Rich Communication Services (RCS).[10] As of 2025, UDH remains relevant for global SMS interoperability through backward compatibility in evolving 3GPP releases, despite the decline of plain SMS in favor of advanced messaging.
Technical Structure
The User Data Header (UDH) in the Short Message Service (SMS) is a binary structure that precedes the user data payload within the TP-User-Data (TP-UD) field of an SMS Transfer Protocol Data Unit (TPDU). It provides a mechanism to include additional control information without altering the core user data, enabling features such as message concatenation and special formatting. The UDH is indicated by the TP-UDHI flag in the SMS PDU header, which signals receiving entities to parse the initial octets of TP-UD as header elements rather than payload.[11]
The UDH begins with a single octet known as the User Data Header Length (UDHL), which specifies the total length of the remaining UDH in octets, excluding the UDHL octet itself. The UDHL value ranges from 0 to 139, ensuring the entire UDH (UDHL + 1 octets) fits within the maximum 140-octet limit of the TP-UD field for 8-bit data. Following the UDHL are one or more Information Elements (IEs), each structured as a triplet: a 1-octet IE Identifier (IEI) defining the IE type, a 1-octet IE Data Length (IEDL) indicating the length of the subsequent IE Data in octets, and the variable-length IE Data itself. This modular design allows multiple IEs to be concatenated without fixed positioning, with the total UDH length determined by the UDHL.[11]
The general octet-by-octet format of the UDH is outlined below:
| Octet Position | Component | Description | Size (Octets) |
|---|
| 1 | UDHL | Length of UDH excluding UDHL (0-139 octets) | 1 |
| 2 | IEI (first IE) | Identifier for the first Information Element (e.g., 0x00 for concatenation) | 1 |
| 3 | IEDL (first IE) | Length of data for the first IE (0 or more octets) | 1 |
| 4 to (3+IEDL) | IE Data (first IE) | Variable data specific to the IE type | Variable |
| Subsequent | Additional IEs | Repeating IEI + IEDL + Data triplets as needed | Variable |
Integration with SMS Protocol
The User Data Header (UDH) integrates into the Short Message Service (SMS) protocol through the Transfer Protocol Data Unit (TPDU) as defined in 3GPP TS 23.040, enabling enhanced features while maintaining backward compatibility with standard SMS delivery. The presence of the UDH is signaled by setting the TP-User-Data-Header-Indicator (TP-UDHI) bit to 1; this bit occupies position 6 in the TP-Message-Type-Indicator (TP-MTI)/UDHI octet, which is the first octet of SMS-SUBMIT, SMS-DELIVER, and related TPDU types.[11] When TP-UDHI is set, the receiving entity interprets the initial portion of the TP-User Data (TP-UD) field as the UDH rather than part of the message payload, shifting the user data interpretation accordingly.
The UDH is placed at the beginning of the TP-UD field, prepending the actual short message content. The TP-User-Data-Length (TP-UDL) parameter specifies the total length of the TP-UD in octets (or septets for 7-bit encoding), encompassing both the UDH and the user data; for instance, in 8-bit binary mode, the maximum TP-UD length is 140 octets, with the UDH consuming the first UDHL + 1 octets, where UDHL denotes the UDH length in octets.[11] This placement ensures the UDH is processed before the message body during delivery from the Short Message Service Center (SMSC) to the mobile station (MS). The Data Coding Scheme (DCS) octet in the TPDU further supports this integration by indicating 8-bit data mode (e.g., DCS value 0x04 for uncompressed 8-bit data), which is required for UDH elements containing binary information elements.
During the SMS delivery process, both the SMSC and the recipient handset must support UDH handling to correctly interpret and apply its features, such as message reassembly or formatting; if the recipient device lacks UDH support, it typically falls back to treating the entire TP-UD as plain text, potentially displaying the UDH octets as garbled characters unless mitigated by a leading carriage return in the user data.[11] The integration operates in both point-to-point modes (via SMS-DELIVER and SMS-SUBMIT TPDUs) and cell broadcast modes, though cell broadcast support for UDH is more limited and depends on the broadcast channel configuration. In 5GS, UDH is supported via the SMS Function (SMSF) as per 3GPP TS 23.040 Release 19 (2025).[11]
Error handling for UDH in the SMS protocol emphasizes robustness: if TP-UDHI is set to 1 but the UDH is malformed (e.g., invalid UDHL or unrecognized information elements), the receiving entity discards the message and may generate an SMS-DELIVER-REPORT or equivalent diagnostic to the SMSC, citing causes like "unspecified error" to prevent delivery of corrupted content.[11] This mechanism, outlined in the protocol's relay layer procedures, ensures that only valid messages are forwarded, with reserved or malformed UDH elements skipped during parsing where possible.
Concatenation and Segmentation
The User Data Header (UDH) facilitates the concatenation of short messages in SMS to overcome the 140-octet limit of a single SMS Transfer Protocol Data Unit (TPDU), allowing longer messages to be split into multiple segments for transmission and reassembly at the receiving entity.[12] Two specific Information Elements (IEs) within the UDH are defined for this purpose: IEI 00 for an 8-bit reference number and IEI 08 for a 16-bit reference number.[12] These IEs enable the segments to be uniquely identified and ordered, ensuring proper reconstruction of the original message.[12]
The structure of the concatenation IE begins with the UDHL field (1 octet), specifying the length of the UDH excluding itself, followed by the IE itself. For IEI 00, the IEI octet is set to 00, followed by a 1-octet length field (fixed at 03), a 1-octet reference number (0-255), a 1-octet total segments field (1-255), and a 1-octet segment number (1-255); this results in a 5-octet IE and UDHL=05.[12] For IEI 08, the IEI octet is 08, followed by a 1-octet length field (fixed at 04), a 2-octet reference number (0-65535), a 1-octet total segments field (1-255), and a 1-octet segment number (1-255); this yields a 6-octet IE and UDHL=06.[12] The reference number remains constant across all segments of a message, while the segment number increments sequentially from 1 to the total segments value.[12] The 16-bit reference in IEI 08 supports larger sequences and reduces the likelihood of overlaps in high-volume messaging compared to the 8-bit variant.[12]
| IE Type | Field | Octets | Description | Range |
|---|
| 8-bit (IEI=00) | IEI | 1 | Identifier for 8-bit reference concatenation | 00 |
| 8-bit (IEI=00) | IEDL | 1 | Length of data (fixed) | 03 |
| 8-bit (IEI=00) | Reference Number | 1 | Unique message identifier (constant per message) | 0-255 |
| 8-bit (IEI=00) | Total Segments | 1 | Number of segments in the message | 1-255 |
| 8-bit (IEI=00) | Segment Number | 1 | Position of this segment | 1-255 |
| 16-bit (IEI=08) | IEI | 1 | Identifier for 16-bit reference concatenation | 08 |
| 16-bit (IEI=08) | IEDL | 1 | Length of data (fixed) | 04 |
| 16-bit (IEI=08) | Reference Number | 2 | Unique message identifier (constant per message) | 0-65535 |
| 16-bit (IEI=08) | Total Segments | 1 | Number of segments in the message | 1-255 |
| 16-bit (IEI=08) | Segment Number | 1 | Position of this segment | 1-255 |
Special Message Features
The Special Message Features within the User Data Header (UDH) support the Enhanced Messaging Service (EMS) by allowing the embedding of simple multimedia elements, such as sounds, animations, pictures, and text formatting, directly into SMS messages without requiring full MMS infrastructure. These features utilize specific Information Element Identifiers (IEIs) to denote the type of enhancement, enabling receivers to render non-text content alongside the message body. Defined in early versions of the SMS protocol and carried forward, these elements prioritize lightweight implementations suitable for basic mobile devices, with data formats limited to black-and-white bitmaps for visuals and monophonic melodies (iMelody format) for audio.[12]
Predefined sounds are indicated by IEI 0x0B, with IEDL=0x02 and two data octets: the first specifying the position (00 for beginning, FF for end, or a value indicating location in the text), and the second the sound number (01-0A for predefined tones, e.g., 01 for beep, 02 for short ring; higher values up to 0xFF for device-specific). User-defined sounds use IEI 0x0C, with variable IEDL (>=0x02) and data including position octet followed by iMelody-encoded melody data (up to 130 octets total).[12]
Animations are handled by IEI 0x0D for predefined animations, with IEDL=0x02 and data: position + animation number (01-0A for fixed sequences like smiley or heart, up to 0xFF). Small animations use IEI 0x0F (IEDL variable, position + bitmap data for 8x8 or similar), while large animations use IEI 0x0E (up to 32x32 pixels, multi-frame). Pictures are specified via IEI 0x10 for large (up to 72x28 pixels, black-and-white bitmap), IEI 0x11 for small (8x8 or 16x16), and IEI 0x12 for variable-sized (with 2 octets for horizontal/vertical dimensions followed by pixel data, up to 128 octets).[12]
Text formatting elements use IEI 0x0A, with IEDL=0x03 or 0x04: data includes start position (1 octet), length (1 octet), formatting mode (1 octet, bits for bold, italic, underline, alignment), and optional color (1 octet). This applies styles to specified portions of the message text. Object distribution for EMS, using IEI 0x8E, facilitates linking and sharing of embedded objects (e.g., vCard contacts), with IEDL=0x02 and data specifying distribution attributes (e.g., forwardable, replaceable).[12]
Multiple IEIs can be chained within a single UDH to combine effects, such as a predefined sound (IEI 0x0B) with text formatting (IEI 0x0A) and a small animation (IEI 0x0F), provided the total UDH length does not exceed available user data space (typically up to 140 octets). This chaining supports EMS object linking, where objects are referenced across elements for cohesive rendering, as specified in 3GPP TS 23.040. Compatibility relies on device support, with unsupported IEIs ignored to ensure fallback to plain text.[12]
| IEI (Hex) | Category | Example | Data Length (IEDL) | Notes |
|---|
| 0x0B | Predefined Sounds | Position + sound 0x01 (beep) | 0x02 | Fixed tones; sound_id 01-0A predefined |
| 0x0C | User-Defined Sounds | Position + iMelody data | Variable (>=0x02, up to 0x82) | Custom melodies, up to 130 octets |
| 0x0D | Predefined Animations | Position + anim 0x01 (smiley) | 0x02 | 2-4 frame sequences; anim_id 01-0A |
| 0x0F / 0x0E | Small / Large Animations | Position + bitmap frames | Variable (up to 0x80) | 8x8 to 32x32 pixels, multi-frame |
| 0x10 / 0x11 / 0x12 | Large / Small / Variable Pictures | Dimensions + pixel data | Variable (up to 0x80) | Black-and-white bitmaps, up to 72x28 |
| 0x0A | Text Formatting | Start, length, mode [, color] | 0x03 or 0x04 | Bold, italic, underline, alignment |
| 0x8E | Object Distribution (EMS objects) | Distribution attributes | 0x02 | Metadata for vCard/vCalendar sharing/linking |
Application Port Addressing
Application port addressing in the User Data Header (UDH) of Short Message Service (SMS) enables the routing of messages to specific applications on receiving devices by specifying port numbers, facilitating services such as notifications and triggers without relying on phone numbers alone. This mechanism uses dedicated Information Elements (IEs) to encode port information, allowing transparent handling by the transport layer while identifying application entities through the combination of destination address (TP-DA) or originator address (TP-OA) and the port.
The 8-bit application port addressing scheme is identified by IEI 04 and consists of IEDL=0x02 followed by two octets: one for the destination port (coded as 0-255) and one for the originating port (0-255). This IE is non-repeatable and categorized as SMS Control. For broader addressing needs, the 16-bit scheme uses IEI 05, comprising IEDL=0x04 and four octets: two for the destination port (0-65535) and two for the originating port. This format supports up to 65,536 unique ports, making it suitable for complex applications like MMS notifications or device triggers, and is also non-repeatable with SMS Control designation.[12]
Port numbering follows structured ranges to minimize conflicts and ensure interoperability. Well-known ports include 0x0000 (0 decimal) for the default SMS application and 0x0800 (2048 decimal) associated with MMS-related services within the IANA UDP/TCP range (0-15999). Ports 16000-16999 are allocated for SMS-specific applications without 3GPP assignment, though this range carries a risk of conflicting implementations if not coordinated. Higher ranges, such as 49152-65535, are reserved by 3GPP for specific uses like non-IP PDN triggers, requiring formal allocation to avoid overlaps.[12]
A practical example involves using IEI 05 in the UDH to specify port 9200 (0x23F0 hex) for a WAP Push message, which can trigger an MMS download on the receiving device without user intervention by directing the content to the appropriate application handler.[14] This setup encodes the destination port as 0x23F0 followed by the originating port, enabling seamless integration with services like over-the-air provisioning or multimedia retrieval.[14]
Port addressing introduces security considerations, including potential conflicts in unallocated ranges that could lead to misrouted messages, and historical risks of arbitrary code execution if applications fail to validate incoming port-triggered payloads. In early implementations, SMS ports exposed vulnerabilities allowing remote exploitation for data theft or code injection, particularly in Android apps using open ports for inter-process communication.[15] These risks, such as buffer overflows or improper permission handling, were mitigated in modern handsets post-2010 through stricter sandboxing, port validation, and OS-level restrictions on SMS-triggered actions.[15][16]
Extensions of application port addressing support advanced features like reply-charging mechanisms and various indication types as defined in 3GPP specifications. Reply-charging uses port addressing in conjunction with SMS to request cost-bearing replies for services, while indication types leverage ports for signaling message waiting states, priorities, or deletions in voicemail and multimedia scenarios.[12]
Applications and Extensions
Use in SMS Concatenation
The User Data Header (UDH) facilitates SMS concatenation by enabling the transmission of messages longer than the standard 140-octet limit through segmentation and reassembly. In the workflow, the sending mobile station or application splits the message into multiple segments, each not exceeding 140 octets, and prepends a UDH to every segment containing a unique reference number (8-bit or 16-bit), the total number of segments (up to 255), and the sequence position of the current segment (from 1 to the total).[2] These segments are transmitted independently via separate SMS-SUBMIT PDUs, with the TP-UDHI bit set to indicate the presence of the UDH. At the receiving end, the mobile station or service center collects segments matching the reference number and originating address, then reassembles them in sequence order before presenting the complete message to the user.[2]
This mechanism significantly extends message capacity, allowing up to approximately 1,530 characters in 7-bit GSM encoding across 10 segments (153 characters per segment after accounting for the 6-octet UDH overhead).[17] It is particularly valuable for applications requiring detailed notifications, such as banking alerts or one-time password (OTP) confirmations that include contextual instructions, where brevity alone may not suffice for user comprehension and compliance.[18] By overcoming the 160-character single-SMS constraint, concatenation supports more informative communications without forcing truncation or multiple unrelated messages.
Despite its utility, reassembly poses challenges, including potential out-of-order delivery due to independent segment routing through the service center, which lacks sequencing guarantees.[2] If segments arrive out of sequence or if any are lost (e.g., due to network congestion or delivery failures), the receiving device may discard the entire message or display only partial content, leading to incomplete information for the recipient.[2] Additionally, memory constraints on the receiving device can prevent storage and reassembly of all segments.
Carrier implementations introduce further variations; while the 3GPP standard permits up to 255 segments, many operators impose practical limits of 5 to 10 parts to mitigate delivery risks and billing complexities.[19] For instance, some networks cap at 6 segments for reliability, beyond which success rates decline.[20] In international routing, certain gateways or legacy networks may not fully support UDH processing, potentially resulting in segments being delivered separately without reassembly. As a modern alternative, Rich Communication Services (RCS) addresses these limitations by natively supporting longer messages without segmentation.
Role in Enhanced Messaging Service
The Enhanced Messaging Service (EMS) extends the capabilities of the standard Short Message Service (SMS) by enabling the inclusion of basic multimedia elements, such as sounds, images, animations, and formatted text, within short messages transmitted over GSM networks. The User Data Header (UDH), a binary structure prefixed to the SMS user data, plays a pivotal role in EMS by signaling the presence, type, and location of these embedded objects, allowing compatible handsets to interpret and render them appropriately. This mechanism operates within the constraints of the 140-octet SMS payload, where the UDH consumes a portion of the space to describe objects, leaving the remainder for text and binary data.[2][21]
In the EMS process, the sending device sets the TP-UDHI (User Data Header Indicator) bit in the SMS Transfer Protocol Data Unit (TPDU) to indicate UDH presence, followed by the UDHL octet specifying the total UDH length in octets. Subsequent information elements (IEs) within the UDH each begin with an IEI (Information Element Identifier) to denote the object type, an IEDL (Information Element Data Length) for the data size, and the actual object data or reference. For example, IEI 0x0B identifies a predefined melody or sound, IEI 0x10 denotes a large picture (up to 32x28 pixels in black-and-white bitmap format, positioned via UDH), and IEI 0x0F specifies a small animation composed of sequential images (positioned via UDH, with data in TP-UD). The user data then follows the UDH, containing the message text interspersed with binary object payloads at positions indicated by the IEs, ensuring the total message adheres to SMS segmentation limits if exceeding 140 octets. This structure supports embedding up to 128 octets of binary objects per single SMS, with concatenation enabling larger compositions up to approximately 760 characters including multimedia across multiple segments.[2][21]
Practical examples illustrate UDH's utility in EMS: a greeting message like "Have a great day!" could incorporate a predefined melody (IEI 0x0B, referencing one of 7 standard sounds such as a chime) positioned at the start, with the UDH directing the receiving device to play it upon message receipt. For more complex enhancements, multiple IEs can chain objects, such as combining a small picture (IEI 0x11, 8x8 pixels) with a user-defined animation (IEI 0x0C for sound or 0x0D for predefined animation, sequencing four frames) to create a simple emotive sequence, like a smiling face that winks. These features were particularly useful for personalizing messages in the pre-smartphone era, though limited to low-resolution, monochrome graphics and monophonic audio due to bandwidth constraints.[21]
On the receiving end, compatible handsets parse the UDH IEs to extract and render objects in real-time—displaying images inline with text, playing sounds sequentially, or animating frames at specified rates—while skipping unsupported elements to avoid disrupting the core message. If the device lacks EMS support, the UDH is ignored, and the fallback renders only the plain text, often with a carriage return to conceal the header bytes visually. EMS, standardized in 3GPP Release 99 and peaking in adoption during the 2000s, facilitated early multimedia experimentation but declined by the 2010s as it was superseded by MMS, which provided superior rich media handling without SMS size restrictions.[2][21][22]
Integration with MMS and Other Services
The User Data Header (UDH) plays a crucial role in integrating Short Message Service (SMS) with Multimedia Messaging Service (MMS) by enabling notifications that bridge text-based SMS to richer multimedia delivery. Specifically, MMS notifications are delivered as SMS messages containing a WAP Push payload directed to port 2948 using the application port addressing information element (IEI 05) within the UDH. This IEI specifies the 16-bit destination port (2948) and source port (typically 0), ensuring the message is routed directly to the MMS User Agent (UA) on the recipient's device without entering the standard SMS inbox. The WAP Push encapsulates an MM1_notification.REQ primitive, including the multimedia message URL, size, expiry time, and subject, as defined in the MMS functional architecture.[23][2]
Upon receipt of the SMS, the device's MMS client intercepts the message via the designated port, parses the notification, and prompts the user to download the full multimedia content from the MMS Relay/Server using an MM1_retrieve.REQ over HTTP or WAP. This workflow allows seamless transition from a lightweight SMS alert to multimedia retrieval, supporting features like address hiding if requested by the originator. The MMS UA then responds with an MM1_notification.RES to acknowledge processing, enabling end-to-end delivery confirmation. This integration relies on the UDH's port addressing to avoid misrouting and ensure compatibility across GSM/UMTS networks.[23][2]
Beyond MMS, the UDH facilitates triggers for other services, such as Over-The-Air (OTA) provisioning for SIM Toolkit applications via TP-PID=0x7F in the SMS TPDU to invoke SIM-resident applets for configuration updates or security enhancements per TS 23.048. These mechanisms allow SMS to activate backend services without user intervention, such as provisioning SIM data in commercial applications.[2][24]
However, UDH integration introduces security considerations, as spoofed application ports can enable phishing by tricking devices into executing unauthorized actions, such as silent data exfiltration or app launches; 3GPP Release 7 addressed this through enhanced SMS filtering and validation mechanisms in the network and UE to detect anomalous UDH elements. In modern contexts, UDH port addressing is employed in two-factor authentication (2FA) systems, where SMS triggers dedicated apps (e.g., via proprietary ports) to process verification codes securely. Despite these uses, UDH adds payload overhead—up to 140 octets in severe cases—rendering it inefficient for large media, and its features are largely deprecated in Rich Communication Services (RCS), the successor to SMS/MMS as of 2025 that uses IP-based messaging without UDH dependencies.[25][26]
Protocol Extensions
In SMPP and UCP Protocols
In the Short Message Peer-to-Peer (SMPP) protocol version 3.4 and later, the User Data Header (UDH) is transported within the short_message parameter of Protocol Data Units (PDUs) such as submit_sm, which carries up to 254 octets of binary user data including the UDH if present.[27] The presence of a UDH is indicated by setting the UDHI (User Data Header Indicator) bit in the esm_class field, specifically bit 6 (value 0x40 added to the base esm_class for default message mode with UDH), ensuring the receiving Short Message Service Center (SMSC) recognizes and preserves the header without alteration.[27] The esm_class field indicates UDHI by setting bit 6 (e.g., adding 0x40), for both default messages and 8-bit binary data (specified in data_coding, e.g., 0x00 for GSM 7-bit default or 0x04 for 8-bit binary).[27]
An example of a submit_sm PDU snippet incorporating UDH might appear in hexadecimal as follows, where the esm_class is 0x40 to flag UDH presence, and the short_message begins with UDH octets for concatenation (e.g., 0x050003CC0201 for a two-part message with reference 0xCC and sequence 1):
submit_sm
command_length: 0x000000B1
command_id: 0x00000004
...
esm_class: 0x40
...
short_message: 0x050003CC0201[remaining user data]
submit_sm
command_length: 0x000000B1
command_id: 0x00000004
...
esm_class: 0x40
...
short_message: 0x050003CC0201[remaining user data]
This structure allows External Short Message Entities (ESMEs) to submit segmented messages via SMPP without losing UDH integrity during transit to the SMSC.[27]
In the Universal Computer Protocol (UCP), specifically the EMI-UCP interface used for SMS gateways, the UDH is embedded in the XSer (Extended Service) field of the message data for operations like code 51 (Submit Short Message), with service type 01 designating GSM UDH information.[28] The XSer field contains the UDH octets directly (e.g., 01 for type, followed by length and data like 0A090003400402 for concatenation), limited to 140 octets to align with GSM constraints, and only one such field is permitted per message to avoid conflicts.[28] Operation code 31, by contrast, serves as an SMT Alert to prompt delivery of buffered messages but does not directly handle UDH transport.[28]
SMS gateways implementing SMPP or UCP must preserve the UDH during routing by refraining from stripping or modifying the header octets, as removal can lead to failed reassembly of concatenated messages or loss of features like application port addressing.[27] Common errors include encoding mismatches, such as incorrect data_coding in SMPP (e.g., treating 8-bit UDH as 7-bit GSM default, resulting in garbled headers) or improper XSer parsing in UCP, which may cause SMSCs to reject PDUs with error codes like 0x0000000D (invalid ESM class).[27] These issues often arise in multi-protocol environments where gateways fail to map UDH indicators consistently between SMPP and UCP.[28]
The transport of UDH via SMPP and UCP is essential for enterprise SMS platforms, enabling bulk concatenation and enhanced messaging in high-volume applications like marketing campaigns, where SMPP's binary handling supports efficient delivery of multi-part content without fragmentation errors.[27]
Adoption in CDMA and Beyond
In CDMA networks, such as those based on IS-95 and cdmaOne standards, the User Data Header (UDH) was not natively defined but adopted through encapsulation within the SMS bearer data structure to support interoperability with GSM features. The 3GPP2 specification C.S0015 for Short Message Service in Wideband Spread Spectrum systems specifies that the User Data subparameter in the bearer data can include a UDH when the HEADER_IND bit in the Message Identifier subparameter is set to 1, encapsulating the GSM-SMS TP-User Data (including UDH elements) as defined in 3GPP TS 23.040 section 9.2.3.24. This approach allowed CDMA SMS to handle advanced features like concatenation and port addressing by embedding GSM-compatible headers, with the CHARi field carrying the encapsulated data.[29]
For concatenated messages in CDMA environments, segmentation relied on a distinct mechanism using a 16-bit message ID (MSG_ID) in the bearer data, rather than the 8-bit reference number in GSM UDH, to avoid collisions across multiple segments while maintaining compatibility.[30] Port addressing, often used for WAP Push or application-specific delivery, was implemented via the Wireless Datagram Protocol (WDP) teleservice in CDMA, which provided a header format analogous to UDH but tailored to the CDMA air interface, as outlined in the WAP specification.[31] This encapsulation ensured that CDMA devices could process UDH-indicated payloads, such as those for enhanced messaging, without requiring full GSM protocol stacks.
In CDMA2000 1x and later evolutions, UDH adoption expanded to support multimedia extensions and cross-network roaming. The 3GPP2 C.S0024 standard for Enhanced Messaging Service (EMS) incorporated UDH-like elements in the user data for object distribution, building on the encapsulation model to enable richer content delivery over CDMA bearers. Interoperability between 3GPP (GSM/UMTS) and 3GPP2 (CDMA2000) networks further drove UDH mapping, where GSM UDH parameters are translated to CDMA User Data subparameters during SMS delivery, as described in interface specifications for multimedia messaging.
Beyond CDMA, UDH was directly integrated into UMTS (3G W-CDMA) networks under 3GPP standards, inheriting the GSM TP-UDH structure without encapsulation, as UMTS SMS operates via the same TS 23.040 protocol stack over the UTRAN air interface. This native adoption facilitated seamless feature support, including concatenation limited to 153 characters per segment due to UDH overhead, across 2G-to-3G migrations. In subsequent systems like LTE, UDH persists in SMS over IMS (IP Multimedia Subsystem) for legacy compatibility, where the SMS payload retains the TP-UDH format during domain selection between circuit-switched fallback and IP-based delivery, per 3GPP TS 24.341.