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:
TCP - 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:
- UDHI = User Data Header Indicator
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.
- UD = User Data or MESSAGE
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.
- UDL = User Data Length or SM_LENGTH
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.
- UDH = User Data Header
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). Information Element 0 0 0 0 0 0 0 0 = Always 0. Other values reserved for future use Identifier Information Element x x x x x x x x = The length of the Information Element Length Concatenated 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 Identifier Total Segment x x x x x x x x = Represents the total number of segments in the short message Count Segment Sequence x x x x x x x x = Identifies the segment in the overall concatenated message Number
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:
- UDHL = User Data Header Length
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