SMPP Test Tool: How to Test an SMPP Client Without Sending Real SMS
What an SMPP test tool is, what to check when testing an SMPP client, and how an SMSC simulator lets you do it without paying for real SMS delivery.
A single SMS can carry only 140 bytes of user data. When your text is longer, it has to be split into several parts that the handset reassembles into one message. In SMPP your client usually does that splitting. Mistakes here show up as garbled, truncated or duplicated messages, so it is worth testing deliberately.
Character limits
| Encoding | Single SMS | Each part of a multipart SMS |
|---|---|---|
| GSM 7-bit | 160 characters | 153 characters |
| UCS2 (Unicode) | 70 characters | 67 characters |
The per-part limit is lower because some of the 140 bytes are used by the concatenation header. Note that several GSM 7-bit characters, such as €, [ and ], take two positions, and that a single character outside the GSM alphabet forces the whole message to UCS2, which cuts the limits to 70 and 67.
Method 1: UDH in the short message
The most common method puts a User Data Header at the start of every part's short_message and sets the UDHI bit in esm_class (esm_class |= 0x40). With an 8-bit reference number the header is six bytes:
05 00 03 RR TT NN05: header length00 03: concatenation information element with 3 bytes of dataRR: reference number, the same in every part of one messageTT: total number of partsNN: this part's sequence number, starting at 1
A 16-bit reference variant exists (06 08 04 RR RR TT NN), which uses seven bytes.
Method 2: SAR TLVs
Instead of a UDH, SMPP can carry the same information in optional parameters: sar_msg_ref_num (0x020C), sar_total_segments (0x020E) and sar_segment_seqnum (0x020F). Not every SMSC supports both methods, so make this configurable in your client.
Method 3: message_payload
Some SMSCs accept the whole long text in one message_payload TLV (0x0424) and do the splitting themselves. Check what your provider expects.
What to test
- Messages of exactly 160, 161, 306 and 307 GSM characters, and 70, 71, 134 and 135 UCS2 characters.
- One non-GSM character inside an otherwise Latin text.
- Emoji, which are outside the BMP and take a surrogate pair in UCS2.
- That every part carries the same reference number and the right sequence number.
- How many delivery receipts you get, one per part or one per message, and that your client matches them correctly.
The sandbox accepts multipart SMS and both UCS2 and GSM 7-bit, and shows each processed message in the panel, so you can check what your client actually sent against what you intended.
Want to try this against a real SMPP endpoint? Register for the sandbox and use it free for 3 days, or tell us about your scenario.