My Oracle Support Banner

How to Analyse "User Data Header" Errors thrown by xmsTrigger for SMPP Traffic (Doc ID 1308314.1)

Last updated on DECEMBER 04, 2019

Applies to:

Oracle Communications Network Charging and Control - Version 2.2.0 and later
Information in this document applies to any platform.


This article will cover different User Data Header errors which can be thrown by xmsTrigger in regards to the SMPP (Short Message Peer to Peer ) protocol and how to understand them.

Firstly, a quick review of the SMPP "packet" and how the they fit together.  The following elements of an SMPP message which we are interested in are as follows:

  - SMPP
    - ...
    - GSM Features (This is where the User Data Header Indicator will be set if required)
    - ...
    - User Data Length
    - User Data
      - User Data Header Length
      - User Data Header
    - ...

Where, TCP (Transmission Control Protocol) is the transport protocol for the SMPP packets and encoded within the SMPP message are the following TLVs (Tag Length Value) which we are interested in:

The UDHI is a flag contained in the "esm_class" (External Short Message) bitmask.  In Wireshark, this bit mask is referred to as "GSM Features" (Global System for Mobile Communications).

Each bit in the mask represents (as taken from the SMPP Protocol Specification Version 5.0):

              7 6 5 4 3 2 1 0 bit

Messaging   - x x x x x x 0 0 = Default MC Mode
 Mode       | x x x x x x 0 1 = Datagram mode
 Bits 0-1   | x x x x x x 1 0 = Forward mode
            - x x x x x x 1 1 = Store and Forward mode

Message     - x x 0 0 0 0 x x = Default message Type
 Type       | x x 0 0 0 1 x x = Short Message contains MC Delivery Receipt
 Bits 2&5   - x x 1 0 0 0 x x = Short Message contains Intermediate Delivery Notification

ANSI-41     - x x 0 0 1 0 x x = Short Message contains Delivery Acknowledgement
 Specific   | x x 0 1 0 0 x x = Short Message contains Manual/User Acknowledgement
 Bits 2-5   - x x 0 1 1 0 x x = Short Message contains Conversation Abort

GSM         - 0 0 x x x x x x = No specific features selected
 Specific   | 0 1 x x x x x x = UDH Indicator
 Bits 6-7   | 1 0 x x x x x x = Set Reply Path
            - 1 1 x x x x x x = Set UDHI and Reply Path 

The most common setting for this bit mask is 01000000b or 0x40, which means all system defaults but a UDH is encoded in the UD.
The User Data, as the name implies, is the message or payload encoded in the SMPP message.  It is important to note that the UD encompasses the UDH if the UDHI is set.
In SMPP, the User Data Length is an integer which represents the number of octets in the message.  An octet is a grouping of 8 bits.

Note: In MAP (Mobile Application Part), the UDL is calculated differently and depends on the Data Coding Scheme.
Follows the same encoding as the GSM header specifications and is used to relay concatenation information if necessary.  The UDH is considered part of the UD is not to be confused with the SMPP PDU (Protocol Data Unit) header.

The UDH will NOT be present if the UDHI is NOT set.

In Concatenated Short Messages, the UDH is six octets long and encoded as follows as per the GSM 3.40 Specifications:

                7 6 5 4 3 2 1 0 bit

UDH Length      x x x x x x x x = Usually 5 (00000101).

 Element        0 0 0 0 0 0 0 0 = Always 0.  Other values reserved for future use
 Element        x x x x x x x x = The length of the Information Element

 Short          x x x x x x x x = Modulo 256 for the Concatenated Short Message
 Message                          Must remain unchanged for all segments of the same message

 Segment        x x x x x x x x = Represents the total number of segments in the short message

 Sequence       x x x x x x x x = Identifies the segment in the overall concatenated message

For example, the UDH for a two segment message would be encoded as follows:

[Length] [IEI] [IEL] [ID] [# Segments] [Current Segment]
     05    00    03   01           02                01 = First/Initial Segment UDH
     05    00    03   01           02                02 = Second/Final Segment UDH
To find SMPP messages with the UDHI set, use the following Wireshark filter:

smpp.esm.submit.features == 0x01

Note: Wireshark does not decode/display the IE Data (ID, #Segments and Current Segment) in a UDH of Concatenated Short Messages fully in the Packet Details pane.  Refer to the Packet Bytes Pane to find out the UDH information as per the following example of a UDH for the first of five segments in a concatenated SMS:

As described for the UDH, the UDHL is the first octet in the UDH and represent the total length of the UDH.  This will usually be 5 as the octet which contains the length of the UDH is not included in the UDHL count.

The relationship between the aforementioned elements of an SMPP message can also be visualised as:

Where if the UDHI is set, then the UDL will be the length of the UDH + UD and within the UDH, is the UDHL which is the length of the UDH.

Note: The "octets" are not to scale.


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.