Combining SMS messages

This post was written by Jeroen on February 18, 2009
Posted Under: SMS
This entry is part 6 of 17 in the series Sending out an SMS

As discussed in a previous post, many features of SMS messages become available if you can set the User Data Header (UDH) field.

When using a GSM modem in text mode you can’t sent a UDH, so you need to use PDU mode.

How do you add a UDH?

There are 2 things you need to do:

  • Set the UDH bit in the first octet of the PDU. For an SMS-SUBMIT PDU (the only one we’ve been using so far) the value is normally 0×01. To indicate that a UDH is present we need to set bit 6 (0×40). So for an SMS-SUBMIT with UDH present we set the PDU type to 0×41.
  • With the UDH bit set, this first octet of the payload (or User Data = UD) needs to indicate the length of the UDH in octets. This field is known as UDHL.

The confusing part here is that the UDHL in in octets, but the User Data Length (UDL) is in septets (in the case of an GSM-7 encoded text message). Here is what a payload would look like:

Size Field Description
1 octet UDL size in septets (counting UDHL + UDH + text)
1 octet UDHL size in octets (counting only UDH)
n octets UDH  
6 or fewer bits filler to assure the UD septets that follow are on a septet boundary.
m septets text GSM-7 encoded characters
GSM-7 encoded charcaters always start on a septet boundary, so if you have a UDH you might have to add some padding bits to have you text start at a septet boundary.


If the text is UCS-2 encoded it would look simpler:

Size Field Description
1 octet UDL size in octets (counting UDHL + UDH + text). Each character in the text occupies a short (=2 octets).
1 octet UDHL size in octets (counting only UDH)
n octets UDH  
m shorts text UCS-2 encoded characters.


What is in a UDH?

The UDH itself consists of one or more information elements (IE). An item is encoded in 3 fields:

Size Field Description
1 octet IEI Information element identifier
1 octet IEDL Information element data length
n octets IED Information element data


There can be many information elements present in a UDH. The one IE we need to construct a big SMS message from several smaller messages is the IE with identifier (IEI) 0×00.

This IEI has 3 values as part of its data:

  • A concatenated short message reference number. If you send multiple concatenated SMS messages the receiving end will need to be able to figure out which part belongs to which large message. This reference number solves that problem.
  • The total number of SMS messages in the large message.
  • The sequence number of the current SMS message

So in more detail, if an SMS message is number 2 of 3, this information element should be in the UDH field:

Size Field Value Description
1 octet IEI 0×00 Information element identifier for a concatenated short message
1 octet IEDL 0×03 Information element data length
1 octet   0xa1 A reference number (must be the same for all parts of the same larger messages)
1 octet   0×03 This message has 3 parts
1 octet   0×02 This is part 2.


Here is a complete set of AT commands to send a message consisting of 3 parts:

First part:

Field Value Description
UDL 0xA0 Total payload length in septets (160)
UDHL 0×05 User data header length
UDH 0×0003000301 Concatenated message IE:

  • IEI = 0×00
  • IEDL = 0×03
  • Ref nr = 0×00
  • Total  = 0×03
  • This part = 0×01


Second part:



Field Value Description
UDL 0xA0 Total payload length in septets (160)
UDHL 0×05 User data header length
UDH 0×0003000302 Concatenated message IE:

  • IEI = 0×00
  • IEDL = 0×03
  • Ref nr = 0×00
  • Total  = 0×03
  • This part = 0×02


Third part:

Field Value Description
UDL 0×90 Total payload length in septets (144)
UDHL 0×05 User data header length
UDH 0×0003000303 Concatenated message IE:

  • IEI = 0×00
  • IEDL = 0×03
  • Ref nr = 0×00
  • Total  = 0×03
  • This part = 0×03

Note that the other fields of the PDU remain the same, whith the exception of the ‘message reference’ (which is the octet after the PDU type). The message reference should be different with each SMS-SUBMIT PDU sent.

These three messages together make “Lorem Ipsum”  (see Lorem Ipsum). I am pretty sure this is the first Lorem Ipsum in SMS speak.

Series NavigationWhat are EMS messages?WAP Push over SMS
Tags: , ,

Reader Comments

Thanks alot for helping.

Written By Kosai on April 22nd, 2009 @ 9:47 am

Tried this one without success.
Had to use command ->
at^scms=….. (For concatenated sms)
from my modem Siemens TC65
I am using php serial extension with success
You need Apache, php and MySql
I recommend it.

Written By Franco on May 27th, 2009 @ 8:18 pm

Tried again your sample and received sms individually.
the first one ended with [...] the second one started like this [...] and ended like this [...].
However, I believe your code must be OK and it came to my attention that perhaps I am having a time problem.
When I send the concatenated messages I am using the hyperterminal from windows and there is a time span of at least 10 to 15 seconds perhaps more, from the time I send the first one to the time I send the second one and so on.
My question is: Is there a time limit for the Operator or receiving SMSC as to how to handle a concatenated message?

Written By Franco on June 8th, 2009 @ 8:43 am


In general the operator’s SMSC is unaware of concatenated messages, it just makes sure the individual messages (parts) are delivered. So there wouldn’t be any timeout at the operator’s site. The receiving phone may have a timeout, but it would likely be in the order of hours than seconds.

In your experiments you need to make sure you vary the reference number. If you always use reference number 0×00 (as in my example), the phone won’t be able to tell which parts belong to what message, which might account for what you’re seeing.

Written By Jeroen on June 8th, 2009 @ 9:47 am

great explanation,
i was trying to write a multipart sms for a few hours,
until i found this comment.

thanks a lot

Written By Benson on June 30th, 2009 @ 1:45 pm

I sent these three messages.



The message is : Viva Franco! Viva Franco! Viva Franco!
I received three sms at the same time but individually. I could see a tiny envelope broken in two pieces indicating that is a concatenated sms (for each one of the three sms). The message inside of each sms was a group of strange characters!.
The message is fine, since I sent it via normal pdu and received it as expected.
I sent these concatenated messages with the command at^scms… from my modem TC65 and received ONE message with three Viva Franco! inside the message.
My modem has to be in text mode to be able to concatenate messages when I use at^scms….
(at^scms is an exclusive at command of siemens TC65!!)
I will strongly appreciate your opinion on this matter.

Written By franco on June 30th, 2009 @ 6:26 pm


There is a reference number in the Concatenated Message IEI. This reference number should be the same for all parts of the concatenated message. So you should use something like:
- 0003010301
- 0003010302 (not 0003020302)
- 0003010303 (not 0003030303)
The messages probably consist of strange characters because the GSM-7 encoding expects characters to be encoded relative to their position. So count:
- 1 byte (for the UDHL)
- 5 bytes for the actual UDL
These 6 bytes occupy 48 bits. The first septet after this starts on the 49th bit.

Written By Jeroen on July 4th, 2009 @ 8:22 am

Jeroen, great article set! Been trying to get multipart working and your article solved the riddle. Thanks!

Written By Sam C on July 5th, 2009 @ 11:36 pm

Thanks again for the solution.
I know have total control of concatenated sms.
Did what you suggested and solved my problem!!!!

Written By Franco on July 6th, 2009 @ 9:33 am

by changing the two octets after the phone number
(0000) to (0010) , is it possible to send the concatenated message as a flash message?

Written By Franco on July 7th, 2009 @ 8:16 pm


I have never tried that. It may work or maybe not; it would depend on the implementation on the recipient phone . The specs don’t mention this combination of features. Why don’t you try it and let us know if it works? Be sure to set the DCS the same for all parts of the multi-part message.


Written By Jeroen on July 7th, 2009 @ 10:34 pm

Tried these three ->
To my surprise I received all three messages in one whole FLASH message.
(1)LoremViva Franco! (2)nostrViva Franco! (3)LoremViva Franco!.
And thanks again.

Written By Franco on July 8th, 2009 @ 5:35 pm

Hi Jeroen.
Thanks for this useful article.
I am currently working on something similar to this.

And I am finding it difficult to understand the PDU structure to add the UDH.

in your last post

can you please tell me which is the service centre number and which is the recipient’s mobile number .
If i know this it will be helpful for me to understand the rest.

Thanks in advance !


Written By Mohamed Ameer on August 5th, 2009 @ 8:21 am


In your PDU, the recipient’s phone number seems to be coded as 0B910585785777F5.
- 0x0b = length of address (11 digits)
- 0×91 = international phone number (assume +)
Then follows the phone number in reversed nibbles:
- 0×05 = “50″
- 0×85 = “58″
- 0×78 = “87″
- 0×57 = “75″
- 0×85 = “58″
- 0×77 = “77″
- 0xF5 = “5″ (F is a filler nibble)
This would add up to “+5058877558775″. This contains 13 digits, so something must be wrong.

The service center number is in the first octet , which indicates the length of of the service center number in OCTETS. When that value is 0×00, the service center that is stored in the SIM is to be used. Say your service center number is “+15125559876″, you’d replace the 0×00 with:
0×07 = length of service center address in octets
0×91 = international phone number
0×51 = “15″
0×21 = “12″
0×55 = “55″
0×95 = “59″
0×78 = “87″
0xF6 = “6″ (and filler F)

Hope this helps. Note the difference in recipient address length (is in digits) and service center address length (in octets).


Written By Jeroen on August 6th, 2009 @ 12:08 pm

I tried to send segmented messages but the modem response “ERROR”

this are the pdus



i can´t find the error, can any body help me???

Written By Darien on September 8th, 2009 @ 1:20 pm

Te second 0×85 = “58″ is not in the pdu, so
it is 11 digits, which is fine!!!.
Your first pdu has xx octets and a half which
will automatucally give an error.

Written By Franco on September 9th, 2009 @ 5:26 pm

Hi Franco:
Sorry again but i don´t understand your answer…
I don´t think that i generate an odd number number of chars.

Let me explain what i do:

1- Encode all the text in septets, and split the text encoded in segments of 134 octets.
2- Build the headers of the sms and the UDH for each segment.
3- Concatenate the header and the text encoded of each segment.

I am wrong?????

Written By Darien on September 9th, 2009 @ 7:24 pm


I haven’t studied your PDUs yet, but from what you describe, I think one error might be is that you encode all text in septets and then split them over segments. Have you made sure that all text starts at a septet boundary (see articles “More on the PDU” and “7-bit encoding”) ? This should be the case in each segment. Your steps make me think that at least in the second PDU your text isn’t.

Another think I just noticed is that you use 0×81 for the numbering plan (the first octet of the destination phone number). This is an unknown numbering plan. Use 0×91 for numbers that start with a country code or 0xa1 for numbers without.


Written By Jeroen on September 9th, 2009 @ 7:42 pm

When are we going to see new posts?
I am anxiously waiting for them!!!.
In reference to octet 0×81 I think he got
it from here ->
(Just right at the very end).
As Jeroen explained, every segment should be independent of the next!.
I would suggest that you try an example with
a much shorter message and then work from there.
Also you should read very carefully Jeroen`s post
#7 Written By Jeroen on July 4th, 2009 @ 8:22 am,
it is extremly important for concatenated messages!.

Written By Franco on September 10th, 2009 @ 8:47 am

Hello Jeroen:

You are right in your comments, i did what you say, i fix my algorithm to pack in septets and use International Numbering Plan …..

but i still having the same answer from the modem ERROR.

my pdus are:



Written By Darien on September 10th, 2009 @ 2:32 pm


When I have time I’ll have a closer look, but first… Here are a number of things that could cause AT+CMGS to fail:
- Have you switched your modem to PDU mode? (try ‘AT+CMGF?’, should return ’0′, if it returns ’1′ use ‘AT+CMGF=0′)
- Does you modem support AT+CMGS? (try ‘AT+CMGS=?’, should return ‘OK’)
- Is there an SMSC preconfigured on your phone? (try ‘AT+CSCA?’, this should return the number of your SMSC)


Written By Jeroen on September 14th, 2009 @ 12:24 pm

Can you show a sample on how to send a long unicode SMS?

Written By Mark on September 15th, 2009 @ 5:34 am

You have mentioned that the text could be UCS-2 encoded.
I am having problems at getting it right!
For concatenated messages and using DCS as 0×00 then
one gets a normal concatenated message as in the case of your example (7 bit encoded).
When I use DCS as 0×10 I get a concatenated flash message OK (7 bit encoded).
However, when I try to use DCS as 0×04 or 0×08 which
signals 8 bit and UCS-2 respectively, it does not seem to work at all, I just get errors.
So if I use 0×08 then UDL should be in octets.
Is there anything else I am missing in order to be able to send concatenated sms using UCS-2?

Written By Franco on September 15th, 2009 @ 7:49 pm


Yes, the DCS should be 0×08 and the UDL should be in octets (which ends up being 1 + UDHL + 2 * number of characters). Also you don’t have to insert padding as in the GSM-7 case. I know you’ve already managed to send UCS-2 (not concatenated) messages, so it must be something small you’re missing. If you wish you can post your PDUs so I can check…


Written By Jeroen on September 16th, 2009 @ 1:52 pm

This is the code that gives me error from the start ->
00 41 00 0B 91 0585785777F5 0004 14 05 0003010301 56697661204672616E636F21AE

00 41 00 0B 91 0585785777F5 0004 14 05 0003010302 56697661204672616E636F21AE

00 41 00 0B 91 0585785777F5 0004 14 05 0003010303 56697661204672616E636F21AE

Also tried it with DCS 0×08 for UCS-2 and of course
the UDL changes accordingly
I get error 553 from the first pdu!.

Written By Franco on September 16th, 2009 @ 7:48 pm


Two comments:

You use the same reference number (the 3rd octet in your PDUs) for all your 3 messages. This can cause problems, especially if you’re sending the second one before the first one is delivered.

I think you have your UDL wrong. I count 19 octets: 1 for UDHL, 5 for the IEI and 13 for your text.

Hope this helps,

Written By Jeroen on September 16th, 2009 @ 9:55 pm

Thanks Again, you were right my mistake was with
the UDL changed it and it went through fine!.

From your comments I just learned that one can send the second one as first and the first one as second.

I suppose that if one sends the third one and one has not sent either one of the first two, the SMSC or the operator will somehow truncate or discard all of them?

Or could it be that the SMSC or Operator will wait for the other two?

And I would ask: What happens if you send the first two and never send the third one, What will the SMSC or operator do with them or rather how long will they keep them before erasing them?

Your thought will be appreciated!.

Written By Franco on September 17th, 2009 @ 8:04 pm


The operator is completely unaware of the messages being parts of a concatenated message. It will deliver whatever it gets as individual messages. The phone waits for all parts in order to reassemble them and show them as one large message. There are no rules for what a phone should do if it doesn’t get all parts. Since all parts are usually sent at the same time, they tend to be delivered at the same time. There is a technique the SMSC uses to make this scenario even more unlikely… but since you can’t control that from your own PDUs it is a bit off topic for this article.


Written By Jeroen on September 18th, 2009 @ 7:48 am

Hello there… im stuck with sending multipart SMS using PDU…

text that i want to send:
Test Broadcast more than 2 messages. This will create 2 type of 145 char len for PDU conversion. If this success then ican test sending these parts as a concatenate messages.

I have split the text into 2 part.
160 char and 14 char.

The SMS-SUBMIT command as follows..

1st part

2nd Part

i can received combined message BUT… the text not complete.. What I received just..
Test Broadcast more than 2 messages. This will create 2 type of 145 char len for PDU conversion. If this success then ican test sending these parts as a nate me

Really appreciate you or others help or comment.

Written By izwan on September 25th, 2009 @ 8:11 pm


I have not examined your PDUs in detail, but…. From what you describe I’d say there has to be an error in your PDUs length. The maximum size of the PDU payload (which includes the UDH and the UDHL) is 160 septets. So if you add a UDH to create a multipart SMS you’ll use 6 octets for UDH + UDHL. 6 octets (+ 1 bit padding) occupy the space of 7 septets, leaving you with only 153 septets for your text.

In you second PDU I see that your UDL (payload size) does not include the space required for the UDH and UDHL.

Good luck,

Written By Jeroen on September 26th, 2009 @ 10:52 am


Yes, what you said is true..
I forgot to include the UDH+UDHL in the calculation.

so now… I just grab 153char/septets per parts if message length more than 160char/septets.

I am already success… YESSSSSSS…

Thanks for your reply.

Written By izwan on September 27th, 2009 @ 10:26 am

Can different segments of the same message have different encoding schemes and/or UDH?

So if I have a message where first segment is all English, and second all chinesh and third with some Turkish characters. Can I have different DCS+UDH for each segment? Or does the DCS+UDH need to be same across all the segments of the message?

Written By Vinit on September 30th, 2009 @ 4:10 pm


The DCS needs to be the same, so if you want to mix character sets you’ll have to resort to UCS-2 (I doubt any handset will support both Turkish and Chinese characters though). The UDH can change (for instance each part would have it’s own text formatting IEs).


Written By Jeroen on October 1st, 2009 @ 7:58 am

Can you help me, I have a sms continued:
I have problems reading, when reading the message why it looks like:
ù?? @ PÅA@Dgjmgt.gjgjgmgjg.gjgjgmgmgjg.gjgjgjhmg.ggggggggg
where the fault?

Written By Ivan on October 5th, 2009 @ 2:56 pm


I am not sure what you’re trying to send. Did you try sending it to real phone? Could it be that the site you point to doesn’t deal with UDH?


Written By Jeroen on October 5th, 2009 @ 9:12 pm

The PDU(GSM-7) that is used for normal messages IS NOT the same as the one that has to be used for Concatenated messages.
Read carefully the post by Jeroen of the 4th of July.
He wrote -> ”
The messages probably consist of strange characters because the GSM-7 encoding expects characters to be encoded relative to their position. So count:
- 1 byte (for the UDHL)
- 5 bytes for the actual UDL
These 6 bytes occupy 48 bits. The first septet after this starts on the 49th bit.


Written By Franco on October 7th, 2009 @ 6:06 pm

Thank you very much Franco. now i can read sms continued correctly.

Written By Ivan on October 8th, 2009 @ 6:18 pm

How can i verify whether my phone supports PDU Concatenated mode(41).. My mobile is working successfully for normal PDU mode(01)…… But it is shows an error while concatenating……………
After sending this through HyperTerminal showing an “ERROR”
then what to do?

Written By Kasi on October 15th, 2009 @ 9:18 pm


When you send an SMS message in PDU mode, the phone used to send the PDUs doesn’t have to have any of the features you’re trying to use. It will just forward the message to the SMSC and the SMSC delivers to the recipient phone. For concatenation, the recipient phone may or may not support it, if it does you’ll see one big message, if it doesn’t you’ll see the parts as individual messages.

So there must be something else wrong with your PDU…. If the response is just “ERROR” it means it never left your phone.


Written By Jeroen on October 16th, 2009 @ 7:51 am

Jeroen, first of all I can’t describe how useful your pages have been; I’m writing a fully automated application that has to do things based upon the messages received and if I didn’t come across here it would have taken way longer ;)

Now I have a question though, and I hope I didn’t miss it among the comments. It’s about receiving messages, and particularly UDHL & IEDL.
I’ve never ever seen anything different from 0×05 and 0×03 (respectively) incoming, but there’s the world out there, and I’m sure there’s some freaky phone just waiting for me to finalize the application to send something different and scramble my readings :)
The question is: IF those 2 values are different from that, where can I find the (real) data to be read? I mean, let’s say that it’s 0×06 and 0×04: where will Ref, Total and Sequence be? same length and right aligned? one longer? I’m afraid I can’t figure this out without real examples that at the time I don’t have.

Thank you very much!

Written By FreeANT on October 18th, 2009 @ 8:20 am

The UDHL could literally be almost any value. For instance EMS formatting, inline images, wall-papers etc, all can be sent using a UDH. In the case of an inline image, the IEDL can easily be 128 bytes and the UDHL of course will be even larger.

If you want to make sure you decode all SMS and EMS message correctly you’ll have a adapt you code to deal with arbitrary UDHL values. It is OK to skip over the IEs you don’t recognize, this is what all phones do, but should should scan them all to look for the ones you are interested in (i.e. in your case the multipart IE). The multi-part IE is not guaranteed to be the first IE and there could be many IEs in the same UDH. The only thing that is certain is that IEDL for the IE for concatenated short messages will be 3 and that it only appears once in every message, because this is the way this IE is described in the specifications.

Another IE you may have to look for would be the one with IEI 0×08…. It is identical to the one with IEI 0×00 that I described in this article, but it uses a 16 bit value for the reference number. In this case the IEDL would be 4 and if this is the only IE in the UDH, the UDHL would be 6.


Written By Jeroen on October 19th, 2009 @ 3:43 pm

Hi Jeroen,

I’ve made great progress with sms programming thanks to your posts, but I’m still stuck with sending multipart sms.

There’s something I don’t manage to understand in the way I have to code the PDU when I add an UDH for a multipart SMS.
When I try to send the first part of your example to my mobile, it works fine, and I receive the text from “Lorem” to “veniam, quis”.

If I try to send the same text in PDU mode as a single sms, it works fine with the following code :
> 0011000B913306xxxxxxF00000AA9aCCB7BCDC06A5E1F37A1B447EB3DF72D03C4D0785DB653A0B347EBBE7E531BD4CAFCB4161721A9E9EA7C769F7195466A7E92CD0BC4C0691DFA072BA3E6FBFC9207AB90D7FCB4169F7384D4E93EB6E3AA84E07B1C3E2B7BC0C2AD341E437FB2D2F83DAE1B33B0C0AB3D3F17AD805AAD2416577BA0D0A9341EDB43BDD06D9CBEE74B8CD02C5EBE939
+CMGS: 112

I got that by translating the text to GSM-7 bit characters, and then packing the 7-bit characters in octets.

What I don’t manage to understand is how you obtain 986F79B90D4AC3E7F53… for the same text.
What do I miss ? Octets and septets gymnastic if far from intuitive for me…

Many thanks in advance for your help.

Written By Marie-Line on October 28th, 2009 @ 10:08 am


The difference is cause by the offset of the text in the SMS payload. GSM-7 septets always start on septet boundaries.

In my example I have a UDH that takes up 6 octets (1 for the UDHL and 5 for the IE). These 6 octets take up 48 bits. This takes the space of 7 septets (49 bits). So the text starts where the 8th character would start. If you look at my code for packing septets into octets you’ll see a parameter paddingBits and how to calculate it. This is what causing the difference.

Good luck,

Written By Jeroen on October 30th, 2009 @ 7:43 am

Hi Jeroen sorry for the delay, been bit busy.
Thanks again for the advice, made good use of it.

Now I have a doubt; in spite of all the searching seems still bit obscure: the length of the message to give as a parameter to AT+CMGS, in pdu ofc.
According to every single source, it’s supposed to be the number of octets of the string excluding the SC specification (the starting ’00′), nothing more, nothing less.
Agree on that, and the sendings work great. I just perform a bovine strlen($str)/2-1.

But is it right doing it like that?

even watching your examples, and the other posters’, the rule is valid. In my case, 2 concatenated messages containing the first verse of the Nutella Nutellae poem (Lorem Ipsum was taken already ;) )

len: 152

len: 101

length is 152, due to the shorter number (denmark, 10 digits) and that’s fine. The number is ofc a fake.
The doubt is, the length *limit* of the message is given by UDL+UDHL+UDH+text right? That one is specifically the thing that can NOT be over 140, while the rest is just making up fancy air traffic. On the other hand would be stupid if I had to sacrifice text in order to specify an SC, for example, or just for having a longer number.
Sorry if it sounds like a silly doubt, but it’s a thing that’s not crystal clear yet.

However, after taking, it’s time to give ;)
About the translation and encoding into gsm-7 and vice versa, I didn’t want to be dependant from sys calls, even if it’s iconv (that I could use as my server is linux).
Plus, my C is rusty and I needed also the encoding/decoding. So I developed a couple functions to do that. Language is PHP, software is free.

I would be happy if you wanted to take a look and -in case- share them, perhaps in the appropriate spot.
I didn’t know where to post them as they cover both the ‘GSM-7 encoding’ and the ‘How to pack GSM-7..’.

The functions allow to specify the number of padding bits (as from your algorythm) so they can be used in every situation.
They are (even too much) verbose and with many remarks, to make the translation to other languages possible.
Or, just reading how it’s done; I hope it might help understanding, if somebody around is in the same desperate situation I was 2 months ago :)

Here is the tarball. There’s also a zip in case you don’t have a unix machine handy :P
files are made and packed under *x so I am not sure about the CR/LF situation if seen on a Windows machine.
BTW I hope you don’t mind if I ‘stole’ a piece of your iconv library text to set up the arrays for the translation. Really didn’t feel like to type the values in. You will find it at first glance ;)

Enjoy, and thanks lots for your articles Jeroen ;)

Written By FreeANT on November 7th, 2009 @ 11:02 am

Hi Jeroen,

You make reference to the IEI and cited that the IEI with identifier (IEI) 0×00 would be for concentenated messages. What other values for the IEI have been reserved per the spec?

Written By Mark Ryan on November 15th, 2009 @ 11:05 pm

hi Jeroen
I don’t Know the meaning of first “0041000B” ,can you tell me more about it, i can send message without it just 70 characters

think you

Written By bill on November 16th, 2009 @ 8:47 am

Could it be that you’re sending messages in Chinese/Unicode? Unicode characters take 2 octets each. GSM-7 characters take 1 septet. 70 Unicode characters takes the same space as 160 GSM-7 characters and this is the maximum size for a text message without concatenation.

If you want to understand more about those octets I suggest you look at an other article “More on the SMS PDU”.


Written By Jeroen on November 16th, 2009 @ 11:08 am

yes,I send message in Chinese with Unicode,I will read the article.
thank you Jeroen

Written By bill on November 17th, 2009 @ 12:07 am

hi Jeroen
I still have two questions,if I send Combining SMS messages in China, could I use “0041000B” at the head,
I have already send single message in my
programming with wavecom modem,but i Can’t make out Combining SMS messagess,tell me the rule of Combining SMS messages and i can program it,the other question is how can i work out the length ,At+cmgs=length,I’m puzzled with the length.

Written By bill on November 17th, 2009 @ 7:47 am

hi Jeroen
I Close to the success of sending Combining SMS messages , I just don’t know how to work out the result of “UDL 0xA0 Total payload length in septets “,I
don’t understand it tell me please

Written By bill on November 17th, 2009 @ 9:07 am

hi Jeroen
I send 2 messages successly and they showed in one message but Garbled, bad luck
In China the head is “0011000B”
this is my programming
string s = String.Format(
strSMScontent.Length + 6,
“0″ + count,
“0″ + currIndex

Written By bill on November 17th, 2009 @ 10:06 am


For Unicode characters, the length should be the number of octets in the message. This includes the UDH (+ 1 octet for the UDHL) and 2 octets for every Unicode character. The length in septest only applies when you send messages using the GSM-7 character set.


Written By Jeroen on November 18th, 2009 @ 12:46 am

hi Jeroen
I get it,I send Combining messages and receive,no Garbled, I find when i use the function
to encode the message , in the end there a line
,and after “0011000B91{0}000800{1:X2}05000304{2:D2}{3:D2}{4}”, the {1:x2} is the message length ,I have no doublt about the encode function,but in fact it’s wrong, Cheers ,thank you Jeroen all the same.

Written By bill on November 19th, 2009 @ 12:33 am

hi Jeroen
I get a question,there is a Nokia phone ,it can show
combining message in one message,but I send combining messages to it with GSM modem,but it received
messages not show in one and no Garbled, I just don’t understand it and my phone can receive correctly.

Written By bill on November 19th, 2009 @ 7:51 am

How do I calculate the fill bit for septet boundary?
please help

Written By saeed on November 19th, 2009 @ 3:42 pm


Please look at the article “How to pack GSM-7 characters into octets”. The calculations are shown there.


Written By Jeroen on November 20th, 2009 @ 8:52 am

How is it that your encoded user data is 986F79B90D4AC3E7F53688FC66BFE5A0799A0…. while mine is CCB7BCDC06A5E1F37A1B447EB3DF72D03C4D0785DB653A0B347EBBE7E531BD4CAFCB4161721A9E9EA7C769F7195466A7E92CD0BC4C0691DFA072BA3E6FBFC9207AB90D7FCB4169F7384D4E93EB6E3AA84E07B1C3E2B7BC0C2AD341E437FB2D2F83DAE1B33B0C0AB3D3F17AD855A583CAEE741B142683DA6977BA0DB297DDE9709B058AD7D373

Am I missing something here with the conversion? How do you divide a long message in the first place? For example I have a message that is 450 characters long. How do i divide it into parts before encoding? Do i divide it in 160 since that is the character limit to determine the number of parts? Really confused here. Please give an easy explanation on me, i’m a newbie in this area. x_x

Written By RC L on January 25th, 2010 @ 1:43 am

Dear Jeroen ,

I have tried the sample message which you shown, everything went well I am also getting OK status for each of the 3 parts but nothing has happen after that. I have not received any message not even a single part.

why this has happen ? Please guide

Written By Hitesh on February 1st, 2010 @ 11:29 am


I have tried another message , message is in 2 parts.

part 1 : 0011000C911969832078180000A706050003000201E834BD3C4703
(text : hitesh)

part 2 :
(text : agja)

both parts are send to network successfully but in return I am corrupted message which is not even opening

why? please help me out

Written By Hitesh on February 1st, 2010 @ 1:14 pm

Thanks, this site is very helpful

My problem solved.
Altough I’m dificult to understanding in English and my program is VB, but I try.. try..and try…
At the end, I solved the problem.

Written By Budikm on February 12th, 2010 @ 9:58 pm

Hello guys,

I’ve built an sms gateway, I’m using unicode due to Portuguese language use of punctuation.
Now we are in need of sending bigger sms, 70 char is not enough.

I need to learn how to build multi part pdu.

0041 : Sms-Submit + UDH bit

000B915121551532F40000 : What is this ?

A0 : total payload lenght

05 : user data header lenght

00 : IEI
03 : IEDL
00 : Ref nr
03 : Total
01 : Current Part
: Concatenated message

986F79B90D4AC3E7F53688FC66BFE5A0799A0E0AB7CB741668FC76CFCB637A995E9783C2E4343C3D4F8FD3EE33A8CC4ED359A079990C22BF41E5747DDE7E9341F4721BFE9683D2EE719A9C26D7DD74509D0E6287C56F791954A683C86FF65B5E06B5C36777181466A7E3F5B0AB4A0795DDE936284C06B5D3EE741B642FBBD3E1360B14AFA7E7 : is this the message, dates, smsc,sender, receiver ?

I really need to learn how tu build an multipart pdu.
Any help ?

Here you guys can see how i build my pdu, i need to change it in a way to send multi part.
Its c#

public static string GetPdu(string number, string message, string smscAddress, out int actualLength)
const byte internationalFormat = 0×91; // telephone/ISDN, international format
const byte unknownFormat = 0×81; // telephone/ISDN, unknown format

// Determine destination address type
byte numberAddressType;
string useNumber;
if (number.StartsWith(“+”))
numberAddressType = internationalFormat;
useNumber = number.Substring(1); // strip initial “+” character
numberAddressType = unknownFormat;
useNumber = number;

// Determine SMSC address type
byte smscAddressType;
string useSmscAddress;
if (smscAddress.StartsWith(“+”))
smscAddressType = internationalFormat;
useSmscAddress = smscAddress.Substring(1); // strip initial “+” character
smscAddressType = unknownFormat;
useSmscAddress = smscAddress;

// Encode the user data text
byte dataLength;
string encodedText = EncodeText2(message, out dataLength);
// Encode the SMSC address
string encodedSmsc = EncodeSmscAddress(useSmscAddress, smscAddressType);

// Create the PDU string
StringBuilder builder = new StringBuilder();
builder.Append(IntToHex(0×41)); // message flags:
// msg type=SMS-SUBMIT-PDU,
// validity=relative
builder.Append(IntToHex(0×00)); // Message Reference, 0=set by device
builder.Append(EncodeDestinationAddress(useNumber, numberAddressType));
builder.Append(IntToHex(0×00)); // Protocol ID, 0=SME-to-SME
builder.Append(IntToHex(0×08)); // Data Coding Scheme, 0=7-Bit default
builder.Append(IntToHex(0xAA)); // Relative Validity, 0xA7=24 hrs,0xAA=4days



actualLength = builder.Length / 2;
builder.Insert(0, encodedSmsc);
return builder.ToString();

Written By Diogo Pinheiro on March 1st, 2010 @ 10:02 am




The above pdu code is sending the sms. but the recieving nuber is gets this sms as two sms’s and some garbage characters are adding the starting of text whre is the mistake please let me know as early as possible. it is very urgent for me

Written By venky on March 4th, 2010 @ 6:47 am


This is one part of my sms-pdu
After the -> AO 05 00 03 A7 02 01


When i try reading it with my existing code that i use to read single sms, it shows weird characters. Would you be kind enough to enlighten me.

Thanking you,

Written By Kumar on March 4th, 2010 @ 7:49 am

I taking help of this article to generate PDU code,for sending SMS by AT commands

But when i use it to send Long SMS,its not succssful to send please help me send out LOng SMS succussfully.

My message Length is 165,so i break it in two parts

when i send sms first part is sent but on receiver phone it display in Special charater form not as actual as i send.

and second part not sent,its return PDU sting with addition of “ERROR”

First Part IS::

and Second Part is::

please help me and tell me where is the fault.

i really need a help from ur side.

thanks in advance.

Written By Vijay Laxmi on April 3rd, 2010 @ 12:10 am

hi (my english is not too well)
i try the pdu from the article like this:

and i try edit and send to my phone number like this:

it still eror. can u help me?
and where i cand send e-mail to ask abput PDU?
thx alot before..

Written By classix16 on April 4th, 2010 @ 9:30 pm

I am able to send longer SMS in PDU mode using GSM 7 encoding but the problem is, messages are sent to the same network not to different network plz help me

Written By komail on June 15th, 2010 @ 12:00 pm

Hi dear.
Thanks very much for your useful information.
I have problem to mix the information.
I need to send a mixed ucs2 and english sms.
for example I need to send or receive some text like:
“hello in persian is ???? and in arabic is ??????”
and this kind of sms may be multi_part.
now I confused how I have to do it.

Written By Amin on August 15th, 2010 @ 4:52 am

any body read my question?
No one help me?

Written By Amin on August 17th, 2010 @ 11:17 pm


You’ll have to encode the whole message as UCS2 and (in the case of ASCII text) insert the ASCII characters as 2 byte characters (e.g. precede them with a 0×00). This works because the USC2 codes for ASCII characters is the same as the ASCII codes. Of course this encoding is very unefficient for English text (only 70 characters instead of 160 as in the GSM7 case), but for mixed text it is your only option.


Written By Jeroen on September 3rd, 2010 @ 10:02 am

The Lorem ipsum text you reference as the message text does not match up exactly with the text you’re using in your message. You have obviously accidentally deleted a ‘ ‘ before the sentence starting “Ut enim ad minim veniam, quis nostrud exercitation..” . This caused a brief headache trying to figure out why my bitshifting code didn’t produce exactly the same hex half way through the first message as yours does.

Please fix that.

Written By Stomach Contents on February 2nd, 2011 @ 2:15 am

Hi Jeroen,

I have make a project using vb for sending sms, This is working fine using concatenated sms PDU mode, But this is not working properly for concatenated unicode sms, Plz. help me for this, Please tell/send me a VB example/text example for this. Thanks…….

Written By Anil on February 8th, 2011 @ 2:45 am

Anil i am doing the same thing in vba. Can you post here your PDU econcoder function?

Written By alb83 on February 24th, 2011 @ 2:55 pm

Hi all,

I sent an Arabic SMS today with smpp logica 1.3 Open Source with Java

This part of code can help you:

Message =”????? ??? ???? ????????? ???????? ???????? ??? ???? ????? ????? ????? ????????? ???? ??? ????????? ???????? ??? ??? ???????”;
String[] splittedMsg = Main.SplitByWidth(Message, 63);

int totalSegments = splittedMsg.length;

//iteerating on splittedMsg array. Only Sequence Number and short message text will change each time
for (int i = 0; i < totalSegments; i++) {
SubmitSM msg = new SubmitSM();
msg.setEsmClass((byte)Data.SM_UDH_GSM); //Set UDHI Flag Data.SM_UDH_GSM=0×40
msg.setDataCoding((byte) 0×08);
ByteBuffer ed = new ByteBuffer();
ed.appendByte((byte) 6); // UDH Length
ed.appendByte((byte) 0×08); // IE Identifier
ed.appendByte((byte) 4); // IE Data Length
ed.appendByte((byte) 00) ; //Reference Number 1st Octet
ed.appendByte((byte) 00) ; //Reference Number 2nd Octet
ed.appendByte((byte) totalSegments) ; //Number of pieces
ed.appendByte((byte) (i+1)) ; //Sequence number
//This encoding comes in Logica Open SMPP. Refer to its docs for more detail
ed.appendString(splittedMsg[i], Data.ENC_UTF16_BE);
DestAddr.setAddress("213661133673");// 213661686742 0661686746 0661698177 0661686742 0661502966
resp = session.submit(msg);



Written By Lamine OUADJAOUT on March 1st, 2011 @ 12:16 pm

what is this?(first your PDU code)
Please explain it!

Written By Mohammad on March 2nd, 2011 @ 2:47 am

great samples
I used your algoritm but when i send the message and when they arrived 2 charactors from the second and 3th segment missed
could you please help me.

Written By Dariush on March 18th, 2011 @ 11:12 pm

Hi, I’ve tried to send sms via Hyperterminal, and failed with “+CMS ERROR: 500″
What might be wrong?

PDU code:



Written By Alex on April 5th, 2011 @ 2:16 am

does each part need to be 153 7-bit character parts ? (except of the lasst part)

is it possible to use something smaller as chunk size ?

Written By Nick on April 19th, 2011 @ 3:06 am

Hello Jeroen,

This is a great site. I’ve learned how to put together a PDU; send and receive. Great! it works!
But now I want to send and receive multi-part SMS, and I do not know how to pad or add padding bits to the User data. Would you be kind enough to show me how to add padding bits for SMS-Submit and how to decode (with padding bits) SMS-Deliver? Maybe a flow chart or source code? I can do only VB 6 and use a Wavecom modem pool.
Thanks! and more power!


Written By Jeff Garque on April 28th, 2011 @ 10:41 pm

In concatenated messages (7-bit alphabet) does the user data in all but the last message must be complete (e.g. 153 characters), as wireshark is not decoding it correctly otherwise?

Written By Justin on May 3rd, 2011 @ 8:02 am

Hello Jeff,

With the help of Jeroen’s this post I have been able to develop a VB6 Program for sending multipart messages. You can download the code at
I have tested the code with Nokia Mobile. Attach the mobile at Port 5 (or change the port in code), Run the program and click send.

This program has one bug. All parts of messages are send successfully from the program but at receiving end Normally 2nd part and 4th part is missing. If you can resolve this bug then please let me know.

I would request Jeroen also to help us in this regard.

Written By Faisal Ayub on June 18th, 2011 @ 6:07 am

Hello everyone. How will I know that received PDU has header or not? Thank you in advance.

Written By JayEm on June 24th, 2011 @ 3:13 am


dear franco i have a great command on send long sms of i have learn how send 16-bit sms please can u send me a udh for 16-bit sms

Written By abbas on July 15th, 2011 @ 6:58 pm

hi everyone. i’m creating a sms program i need to use unicode and long sms and also i must give smsc in the command.
firt i try to send a sms unicode and short sms with smsc it is ok working
07 91 093592100000 01 00 0C 91 095565486048 00 08 12 011F00FC0131006F0069015F00E7002E0075
but i cant send
07 91 093592100000 41 00 0C 91 095565486048 00 08 12 XX??
because i can’t understant what i must write?
i can’t find unicode,long and with smsc.. can anyone help me?

Written By tolgakayahan on August 16th, 2011 @ 7:35 am

Hi, I m stuck with my PDU can you please tell me what’s wrong with my PDU

My PDU is

00 41 00 0C 91 29 33 41 22 59 68 00 00 A0 05 00 03 00 03 01
N u m b e r H e a d e r

8C = Length of Data


Above PDU is for data and data is given below.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua

Combined PDU is:

Thanx a lot for your help.

Written By Ali Rizwan on August 16th, 2011 @ 7:31 pm

I have a problem with my message. I’m using PDU with SMSC number in SMS-SUBMIT mode with STATUS-REQUEST, the coding is UCS2, and everything seems fine – the message is delivered with proper coding, but i get no STATUS-REQUEST. And then when i add any UDH (of course i’m changing first byte after SMSC number to 0×61) it seems like everything is ok, i’m even checking it with PDUSpy, except the message isn’t delivered (it is sent from device – i get the +CMGS: and OK codes) and i still don’t have the status from SMSC. It seems like UDH makes SMSC lose the message somewhere. My PDU is:
Thanks for help.

Written By Mro on November 12th, 2011 @ 12:46 pm

Ok, i found my error. I just didn’t set the validity period and SMS was delivered later (later i mean after 2-3 days ;/ ).
PS. Great site!

Written By Mro on November 13th, 2011 @ 5:43 am

I have some VB6 applications that might can help for convert SMS to PDU (Concatenated SMS support) ,
you can download in website link below & free of use it


Achmad Subechi
From Indonesia

Written By achmad subechi on December 6th, 2011 @ 12:45 am

Dear Jeroen,

First part of canctenated message is going with ok response(but Not delivered),2nd part is giving error in reponse.I have tried each and every thing you mentioned.plSSSSSS help me.I am facing problem in second part in which we have to calculate UDl in septents ,how to manage 6(UHDL+UDH)bytes other then message data ,to be converted in to septents. please help me…,anybody have solution please send me mail

Written By sumit ahuja on February 29th, 2012 @ 1:26 pm

Hi Jeroen,

I’m stuck with a problem while sending a concatenated sms. Let’s say the message is split in 2 parts, the resulting sms I receive has an extra character at the beginning of each part and some are missing at the end …
If I send both parts individually, the pdu conversion works fine.
Have you already met this kind of problem ? Or maybe you know a tool that could give me the right converted pdu (a tool that supports multi parts sms) ?
Thanks a lot,


Written By Jertho on March 26th, 2012 @ 12:14 am

I have here my ENCODED PDU message (only First Part)…

I can send this long message to Ericsson, Motorola and ALCATEL etc, but not on IPhones and others… Should I send my long messages asyncronously? How can I do it? I have observed that I receive the whole message once destination receives it… There is a case when the receiving phone receives the messages part by part- after receiving all parts- the messages is concatenated as one… How can I do that? Please help :(

Written By GANI on December 3rd, 2012 @ 12:04 am

On the THIRD part of your message: HOW did you come up with the “139″ (at+cmgs=139????)

Please help me…


Written By GANI on December 19th, 2012 @ 12:11 am

I appreciate about LMS imformation that you provide.
first of all, I can’t speak English very well. so understand me, please.
I’m studying LMS.
If you have source code or Tool(VC++ or C#), I’d like to recieve that.
Thank you.

Written By Feel on February 12th, 2013 @ 5:34 pm

eymiznpcjmfujejoht, Electronic cigarettes smokeless, McIDygl, [url=]Reviews on electronic cigarettes[/url], dwRNAZU, Volcano electronic cigarette, Mgwlwee, Reverse Phone, HxzQoxe, [url=]Canada reverse phone number[/url], IoNQZgF, Reverse Phone, NTNjPgW,, AVMPVZF, [url=]Option fair value hedge[/url], ztgdVCr, Optionfair, wZciScY, Meratol Reviews, hKwOUqS, [url=]Buy meratol[/url], wRoUnLk, Meratol Reviews, uUWxaXr, Tramadol without prescription, tvrhhqd, [url=]Tramadol side[/url], jcdTRoh, Tramadol, CTGLSQC, 32 bit launch options, CdzHvZl, [url=]Optionbit Review[/url], DKJNftB, Optionbit, PuQdvXj.

Written By Optionbit on April 9th, 2013 @ 8:48 pm

Tested that code. When I send the 3 sequences above I obtain these SMS:
1) @ù@??
2) @ù@?
3) @ù@?0

There’s no “single and long” SMS I receive.

Written By Gianpiero on July 19th, 2013 @ 10:03 am

Same problem of Jérôme (#89). I’ve got an extra “L” char at the beginning and a missing char at the end. How can I solve this problem?

Written By Gianpiero on July 22nd, 2013 @ 11:39 am

Do you have c# code with concanated support ? Thanks

Written By fanste on August 29th, 2013 @ 2:16 am


I think I have a problem with my PDU which muste sent 3 conbined SMS. These are my PDU
AT+CMGS = 75
AT+CMGS = 74
AT+CMGS = 74

The first part is sent but the receiver has a blank message the for oter part, a +CMS:304 is generated.
Could you help me to know where is the problem ?

Written By Gwen on October 18th, 2013 @ 2:02 am

Part 1:
00 00 00 c4 00 00 00 04 00 00 00 00 00 00 00 02 00 00 00 32 30 32 30 00 00 00 39 33 37 30 37 33 30 34 36 39 39 00 00 00 00 00 00 00 00 18 00 84 06 2c 06 47 06 2a 00 20 06 2f 06 27 06 46 06 44 06 48 06 2f 00 20 06 22 06 47 06 46 06 af 00 20 00 22 06 cc 06 a9 00 20 06 42 06 2f 06 45 00 20 06 7e 06 cc 06 34 00 22 00 20 06 27 06 32 00 20 06 2c 06 27 06 48 06 cc 06 2f 00 20 06 34 06 31 06 cc 06 41 00 20 06 28 06 39 06 46 06 48 06 27 06 46 00 20 00 43 00 52 00 42 00 54 00 20 00 20 06 2f 06 31 06 7e 06 cc 06 27 06 45 00 20 00 31 00 31 00 30 02 0c 00 02 00 03 02 0e 00 01 02 02 0f 00 01 01

Part 2:
00 00 00 c0 00 00 00 04 00 00 00 00 00 00 00 03 00 00 00 32 30 32 30 00 00 00 39 33 37 30 37 33 30 34 36 39 39 00 00 00 00 00 00 00 00 18 00 80 00 30 00 34 00 30 00 34 00 35 00 20 00 44 00 57 00 4e 00 53 00 20 00 20 06 46 06 48 06 34 06 2a 06 47 00 20 06 48 00 20 06 28 06 47 00 20 06 34 06 45 06 27 06 31 06 47 00 20 00 38 00 32 00 38 00 32 00 20 06 27 06 31 06 33 06 27 06 44 00 20 06 a9 06 46 06 cc 06 2f 00 2e 00 20 06 47 06 32 06 cc 06 46 06 47 00 20 06 27 06 2e 06 30 00 20 06 45 06 cc 00 20 06 af 06 31 06 2f 06 2f 00 2e 02 0c 00 02 00 03 02 0e 00 01 02 02 0f 00 01 02

Here I sent these two parts of a single pdu but the problem is that they do not combine into a single long sms the first one comes first then the second one… The same sms works perfectly when it is done through the smpp client application software…

Written By John on December 16th, 2013 @ 5:11 am

Dear Jeroen,

With your support & Mr. Franko, Now I can able to send the concatenated SMS using VB without any problem. Thanks for sharing.

Written By Karthick on February 17th, 2014 @ 5:16 am

Add a Comment

required, use real name
required, will not be published
optional, your blog address

Previous Post: