User Data Header Length

Description

The User Data Header Length (UDHL) is an integral part of the SMS User Data Header (UDH) mechanism, defined in 3GPP TS 23.040. It is an 8-bit (one-octet) value that occupies the first octet of the TP-User-Data field when the User Data Header Indicator (UDHI) is set to 1. The UDHL's sole purpose is to declare the total length, in octets, of the entire User Data Header that immediately follows it. This length value includes all subsequent Information Elements (IEs) but excludes the UDHL octet itself and the user data text. The range is from 0 to 140 octets, constrained by the maximum SMS payload size.

Operationally, when an SMS entity (e.g., a handset or SMSC) processes a message with UDHI=1, it reads the first octet of the TP-User-Data as the UDHL. This value tells the parser how many octets to consume as the structured UDH. For instance, if UDHL is 5, the next 5 octets are interpreted as the header. The parser then sequentially decodes the header content, which consists of one or more Information Elements. Each IE is composed of an Information Element Identifier (IEI), an Information Element Data Length (IEDL), and the IED. The sum of the lengths of all IEs must exactly equal the UDHL value. After reading UDHL octets, the remaining octets in the TP-User-Data field are treated as the user text payload.

Architecturally, UDHL serves as the critical pointer that defines the boundary between control information and user data within the SMS payload. It enables variable-length headers without requiring a fixed format, providing immense flexibility. The network or handset's SMS protocol stack relies on an accurate UDHL to correctly strip the header before presenting the message to the user or passing it to an application. An incorrect UDHL would cause misparsing, potentially leading to corrupted message display or failure to recognize header features. Its design is simple yet powerful, forming the backbone of the UDH's extensible architecture by allowing multiple, different IEs to be bundled together in a single message while clearly delimiting their collective extent.

Purpose & Motivation

UDHL was created to address the need for a flexible, variable-length header system within the strict size constraints of an SMS message. Early SMS had no header concept; all 160 characters (or 140 octets) were for user text. To introduce features like message concatenation, where a long message is split into several SMS segments, a method was needed to embed segment numbering and identification into the message without corrupting the visible text. A fixed-length header would be inefficient and inflexible for future features. UDHL provides a dynamic solution: it tells the receiver exactly how much of the payload is dedicated to header information, regardless of how many or what type of Information Elements are present.

This solves the problem of extensibility and co-existence of multiple enhanced features in a single message. For example, a message could contain both a concatenation IE and an application port IE. The UDHL allows the receiver to correctly find the end of this composite header. Without UDHL, the receiver would have no way to know where the header ends and the text begins, as IEs can have variable data lengths. The motivation was to create a future-proof, TLV-like (Type-Length-Value) structure within SMS, enabling continuous innovation in messaging services—such as ringtones, pictures (via EMS), and WAP push—while maintaining a single, simple length field for parsing.

Its introduction, alongside UDHI, standardized what was previously a fragmented landscape of proprietary implementations. By providing a clear and unambiguous length indicator, it ensured interoperability across different vendors' handsets and network equipment. This was crucial for the global rollout of interoperable value-added services over SMS, turning it into a reliable service delivery platform. The UDHL mechanism exemplifies efficient use of limited payload space to enable rich functionality.

Key Features

• 8-bit length field defining total UDH size in octets
• First octet of TP-User-Data when UDHI is set
• Enables parsing of variable-length User Data Headers
• Critical for separating header IEs from user text payload
• Supports multiple concatenated Information Elements
• Defined range of 0-140 constrained by SMS payload limits

Evolution Across Releases

Defining Specifications