More on the SMS PDU

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

As discussed in an earlier post, you can connect to a GSM modem and use AT commands to send SMS messages. There are 2 possible methods: text mode and PDU mode.

It turns out that most devices support PDU mode, but only a few support text mode.

Here is an example AT command to submit a PDU:

> 0001000B915121551532F400000CC8F79D9C07E54F61363B04<Ctrl-Z>
As explained before the size (24) is the number of octets in the PDU. he PDU itself is passed as a hex representation of those octets (48 characters). Here is what the individual octets represent:

Size Value Description
1 octet 00 Indicates that we don’t supply a SMSC number. The one that is configured in the device will be used.
1 octet 01 PDU type and options. This is a one octet bit-field that controls:

  • Message type (here it set to 1 which means this is an SMS-SUBMIT PDU)
  • Validity period format
  • Reply path
  • User Data header present (UDH indicator)
  • Request status report

The most significant of these is the UDH indicator. More on these fields in a future post.

1 octet 00 Our message reference. In case there is an error delivering the message, this number will be part of the error response so we can see which message failed.
1 octet 0B Size of destination telephone number (in digits)
1 octet 91 International numbering plan. This indicates that what follows is is an international telephone number.
6 octets 5121551532f4 Telephone number. This is the destination phone number is a reverse nibble encoding:

  • octet ’51’ stands for digits 1 and 5
  • octet ’21’ stands for digits 1 and 2
  • octet ‘55’ stands for 5 and 5
  • octet ‘15’ stands for 5 and 1
  • octet ‘32’ stands for 2 and 3
  • octet ‘f1’ stands for digit 1 and the f indicates the end

So ‘915121551532f4’ translates to +1 512 555 1234.

1 octet 00 Protocol identifier. This can be used to indicate a higher level protocol. ‘0’ indicates no higher level protocol.
1 octet 00 This represents the Data Coding Scheme. A ‘0’ indicates that the messages is encoded in the GSM 7 (default) alphabet.

  • The message could also be encoded in UCS-2. In which case this octet would be ‘08’.

‘There are other (fun) uses for this byte that I’ll show in a future post.

1 octet 0c Payload size in septets (characters). This field is also called User Data Length.
11 octets C8f79D9C07E5
The payload, also known as User Data. In this case it is just GSM encoded text. This is the tricky encoding:

  • The GSM-7 alphabet is a 7 bit alphabet. It’s character set is unlike any of the standard ISO or ASCII character sets (for instance a septet ‘0’ stands for the character ‘@’).
  • Septets are placed in octets in a funny way. I’ll explain below.

This particular string represents “Howdy y’all!”

The GSM-7 payload encoding is hard to explain, I’ll show how it works with the example above. Each character is represented by the bits with the same color:

C8 1 1 0 0 1 0 0 0 1001000 = ‘H’
F7 1 1 1 1 0 1 1 1 1101111 = ‘o’
9D 1 0 0 1 1 1 0 1 1110111 = ‘w’
9C 1 0 0 1 1 1 0 0 1100100 = ‘d’
07 0 0 0 0 0 1 1 1 1111001 = ‘y’
E5 1 1 1 0 0 1 0 1 0100000 = ‘ ‘ (space)
4F 0 1 0 0 1 1 1 1 1111001 = ‘y’,0100111 = ‘‘’ (quote)
61 0 1 1 0 0 0 0 1 1100001 = ‘a’
36 0 0 1 1 0 1 1 0 1101100 = ‘l’
3B 0 0 1 1 1 0 1 1 1101100 =’l’
04 0 0 0 0 0 1 0 0 0100001 = ‘!’

So every septet is added by first inserting the least significant bits in the unused most significant bits of the octet, then the rest of the bits (the most significant bits) are inserted in the next octet’s least significant bits. Confused? It becomes a lot clearer if you realize the octets are transmitted right to left. I have written articles (withe code) on how to convert to the GSM-7 character set and another on how to pack GSM-7 septets.

The precise specification of the PDUs is given in 3GPP TS 23.040. The spec for the AT commands is in 3GPP TS 27.005. The GSM-7 character set is described in 3GPP TS 23.038.

There is little literature on this topics, but I found the following book has a pretty good introduction to the general topic and explores some SIM based scenarios:

Mobile Application Development with SMS and the SIM Toolkit

In the next post I’ll show how to turn an SMS message into a flash SMS message.

Series NavigationSending a flash SMS message
Tags: , ,

Reader Comments

Great article, it helped me a lot!
I’m a newbie fan of gsm modems. They make fine remote control for a PC ;)

Written By Ivan on February 19th, 2009 @ 1:57 am

Thanks a lot for the article…


Written By Gardiary on April 13th, 2009 @ 12:43 am

Thanx a lot for this piece of information!

I have succeeded to implement this in a java application that communicates with mobilephone over Bluetooth.
I have build an GUI for easy use, but I have left to build an interpreter for text input.

Does anyone know about an good explanation or example code for an interpreter? Preferably written in java.

Best regard!

Written By Johan on April 17th, 2009 @ 5:22 am

There is a lot about SMS and PDU mode scattered about the internets and in various books, but this is the clearest explanation of the whole package I have seen yet.

Thank you!!

Written By metamanda on April 24th, 2009 @ 3:21 pm


I just wish I had more time to continue working on this….


Written By Jeroen on April 24th, 2009 @ 3:54 pm

If I set octet 13 to a number higher than 00
can I use the standard ASCII table?

Written By franco on May 31st, 2009 @ 7:00 pm

No, unfortunately SMS text messages can only be sent using GSM-7 or Unicode.

Written By Jeroen on May 31st, 2009 @ 8:01 pm

i have trouble in send sms in PDU..anybody send a detailed Examples…Im using sonyEricsion W810i, Motorolal6 the both GSM modem i cant send sms in PDU mode,..Pls Help me

Written By Susi on May 31st, 2009 @ 10:26 pm

When I sent a flash message with my own letters
(0C D6B43D0C32CAC361F7F81D02 = 12 characters)
I counted the octets and substracted one so I thought
at+cmgs= Total octets minus one will do it.
Then my modem was sending error.
Then I substracted two and it sent it fine!!!
Somehow the special characters from y`all! which
you had 5 octets but in reality it is 6 characters.
So when dealing with special characters one must be careful as to the number for

Written By Franco on June 3rd, 2009 @ 6:34 pm


You need to be aware of the difference between octents and septets. In the GSM-7 alphabet characters are encoded in one septet (some special characters are encoded as 2 septets). In the example I gave there are 12 (0x0C) septets, 12 characters, but only 11 octets.

I see your example has length 12 (0x0C) too, but there are 12 octets following it; 12 x 8 bits = 96 bits. 96 bits hold 13 septets (13 x 7 = 91). So my guess is that your length should have been set to 13 (0x0D).

Some special characters in the GSM-7 alphabet do require 2 septets to encode. My example doesn’t contain any of those (the single quote isn’t special in this respect). But if your example does, you need to count septets, not characters….

Hope this helps,

Written By Jeroen on June 4th, 2009 @ 8:02 am

Thanks again!.
Your explanation made me discover my mistake.

Written By franco on June 6th, 2009 @ 8:13 pm

This topic is greate, even explained in detail, but my problem is that I dont understand this octet.

how H is equal to C8?

can some one explain pls?

and what will be the octet code for:

+ 92 321 9820211

Written By Naveed on June 9th, 2009 @ 3:34 am

You need to pay attention to the color coding. The ‘H’ is represented by 0×48 (= 1001000) which are the last 7 bits of the octet 0xC8.

Use the table in (take for instance version 6.1.0 of this spec) to see how each character is encoded. You’ll see that this is very different from ASCII.

+ 92 321 9820211 would be encoded as 0×29 0×23 0×91 0×28 0×20 0×11. Every digit is represented by a nibble (= 4bits), the nibbles are reversed inside each octet.

Written By Jeroen on June 9th, 2009 @ 7:57 am

Thanks for the reply Jeroen!

I will try my best to pay attention and make myself understand this time.

thanks again.

Written By Naveed on June 9th, 2009 @ 11:51 pm

I tried second octet with 11 instead of 01 as you have and It went through ok.
Any ideas why?

Written By Franco on June 12th, 2009 @ 9:30 pm

The second octet (which is the first octet of the SUBMIT PDU) contains various fields:
- The PDU type
- The type of validity period specified (if any)
- Whether a reply path is set
- Whether a UDHL is set
- Whether a status report is requested
The value 0×11 would indicate that it is a SUBMIT PDU and that there is a (relative) validity period specified. A relative validity period would be an extra octet before the UDL field. So what you set as UDL would be interpreted as a validity period. Any single octet value can work as a relative validity period. The next octet, the first one of your payload would be interpreted as the new UDL. So if the message went through I would expect the first character to be missing, the second to be wrong and the rest of the message would likely be truncated.

Written By Jeroen on June 15th, 2009 @ 8:35 am

This way of setting the second octet to 11 I got it
No wonder it went through fine since they set up an octet before the UDL to AA (170).
My main question is: Under what circumstances would you
use a validity period as set by these people?
P.D. Jeroen your knowledge is strongly respected and appreciated.

Written By Franco on June 15th, 2009 @ 6:55 pm

A validity period lets you specify how long the SMSC should keep the message for delivery. If the message isn’t delivered in the validity period (because the phone is off) the SMSC will discard the message and the recipient will never see it.

That one octet (0xAA) determines a period of 4 days:
- If the value is between 0 and 143 it indicates a number of 5 minute intervals (e.g. 12 specifies a validity of an hour)
- If the value is between 144 and 167 it indicates a number of 30 minute intervals (first subtract 143)
- If the value is between 168 and 196 it indicates a number of days (first subtract 166)
- If the value is 197 or higher it indicates a number of weeks (first subtract 192)
So the maximum validity you can specify is 255, which would be 63 weeks.

Written By Jeroen on June 15th, 2009 @ 7:11 pm

I once, as part of my marketing strategy, visited the local operator (SMSC) and asked them: How long do you keep a sms which was not delivered at the first time; the person in charge made a phone call and said to me 72 hours. (Meaning text sms).
Does a sms sent via PDU will override the standard procedure of the operator?

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

Probably only if you specify a validity period shorter than their default.

Written By Jeroen on June 16th, 2009 @ 8:45 am


I tried this command and it gives me ERROR, dont know why? please help:

> 0001000C91292391782447000004C8F71D

Written By Naveed on June 17th, 2009 @ 4:06 am

Without examining your example too much, I’d say:
- your UDL is 4, since the DCS indicates GSM-7 this corresponds to 4 septets
- 4 septets are 28 bits and still require 4 octets to encode
- so either you made a mistake on the encoding, or your UDL is one too high


Written By Jeroen on June 17th, 2009 @ 8:57 am

The second octet has 01 which means that there is No reply path.(0000100)
When I receive an sms via pdu from the SMSC they send octet A4 which has what 01 has plus reply path exists and status report requested. (1010100)
I am confused as to how I can send an sms (pdu) and tell the receiving phone that there is No reply path or mainly that the phone can not reply to the sms.
Do I have to set the first bit to 0? or 1?
Or by default all aperators have it set to 1?

Written By Franco on June 17th, 2009 @ 7:49 pm

The reply path maybe does not do exactly what you expect. It is not about disabling or enabling replies, but rather about letting the recipient use the same path (=SMSC) as the sender should they wish to reply.

- If a reply path is requested, the receiving phone should try to use the same SMSC that the sender used to ensure a better chance of delivery of the reply. Also the recipient of the SMS may not have SMS available on their subscription (and no SMSC configured). Setting the reply path gives them the opportunity to answer to the SMS no matter what. Who pays for the reply depends on the operator, but it could be the recipient of the reply.

- So if you receive an SMS with reply path set, you can send messages back using the SMSC that originated the message rather than the default one (which is pre-configured in your SIM). If you send an SMS with reply path, the recipient can send messages back which could be charged to you!

Written By Jeroen on June 17th, 2009 @ 8:35 pm

Hi Jeroen

Do you have any examples of how to enable the UDHI so you can send multipart PDU SMS? I enable the bit in the SMS_SUBMIT octet (I set that octet to 41). My encoding is left as 7-bit as I believe my receiving phone does not support unicode. I prepend the UDH to my user data (so I am prepending 6 octets to the front of the septets of message data e.g. prepend “050003000201″).

Some of the time I am getting an error from the modem. Other times, it sends rubbish as the message. The spec has no samples for this case and I’m trauling the web for some.

Any help would be greatly appreciated!

Written By Sam C on July 5th, 2009 @ 9:28 pm

Hi Jeroen,

Sorry disregard my previous post. I just found your article on multi-part SMS. I’ll post a question again if I run into trouble again.


Written By Sam C on July 5th, 2009 @ 9:32 pm

Is it possible that you could give us an example of same
sms but in either UCS-4, UCS-2 or UTF-8.
Hve tried it and failed several times.

Written By Franco on July 15th, 2009 @ 6:38 pm

08 is for UCS-2
Just tried like this -> at+cmgs=25
00 01 00 0B 91 0585785777F5 0008 0C 00560069007600610020004600720061006E0063006F0021
(Viva Franco!)
It is sent; however I get half of the total words.
(Viva F)
Tried modifying 0C and at+cmgs=25 and get error.

Written By Franco on July 15th, 2009 @ 7:07 pm

The UDL field for UCS-2 should be the length in octets, which is twice the number of characters.

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

Just found out that if I use 04 as the DCS,
leave 0C and message in HEX.
It is received as expected or OK.
If I use 08 as the DCS leave 0C and message in HEX.
I receive a group of tiny squares!!!.
I am confused!.

Written By Franco on July 15th, 2009 @ 7:32 pm

The DCS value 08 stands for text in UCS-2. Every character should have 2 octets. If you take an ASCII character and put a 0 before it, it’ll correspond to the same character in Unicode (ASCII is a subset of Unicode). If you leave out the zeros you’re picking random (2 octet) Unicode characters, which either are not valid or the device probably doesn’t know how to display.

The value 04 stands for 8 bit data. It seems that your receiving device interprets this as characters in some character-set (try sending a character > 128). This is a great feature of that device, but you can’t rely on all devices behaving this way. This is not a standard feature!

Written By Jeroen on July 15th, 2009 @ 7:40 pm

Sent character 174 (AE – Hex) and I could see the tiny
registered trademark (0004 and ascii-hex).
I have, finally, been able to work with UCS-2.
Thanks Again.

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

The last 2 bits of the DCS mentions 4 classes
one is what we usually use (00) inmediate display(alert)
Hvae looked for the meaning of the other 3 classes
(01)(10) and (11). If you could please give us a quick
explanation of what it means.

Written By franco on July 19th, 2009 @ 4:30 pm


In short:
- Class 1 (01) is for (proprietary) messages intended for the phone (ME)
- Class 2 (10) is for messages intended for the SIM
- Class 3 (11) is for messages intended for terminal equipment (TE) (like PCs attached to the phone)

Class 1 is sort of obsolete. You address applications on the phone by adding a WDP port. Class 2 is used by telcos to store some apps (SIM apps) and/or phone numbers (like their customer service number) onto your SIM. Class 3 would be used for instance by remote control applications.


Written By Jeroen on July 20th, 2009 @ 9:24 am

Copy_Pasted your initial commants and the error “invalid PDU lenght” occured. I use an RS232 terminal program to send the AT commands to my GSM-modem and i typed exactly (in HEX):

1) 41542B434D47533D32340D0A (AT+CMGS=24 in hex)
2) 0001000B915121551532F400000CC8F79D9C07E54F61363B041a

(1a is the hex code for special character according to ascii table)

Do you have any idea what is going wrong? Thank you!

Written By dimis on July 24th, 2009 @ 2:52 am


You’re supposed to send the ‘AT+CMGS=24′ as plain text, followed by a new line. The <ctrl-Z> also needs to be the character 26, not it’s hex value. Only the PDU itself is hex encoded.

Of course if you copy the command literally, you’ll be sending an SMS message to a non-existing number (+1 512 555 1234) which might also cause an error.


Written By Jeroen on July 24th, 2009 @ 8:07 am

Is it right to say that using
- Class 2 (10) is for messages intended for the SIM
I can send a sms to a friend`s phone and be able
to store at his phone contacts(sim) my name and my phone number?
If yes!, Can you explian how one goes about to be able to do it?
P.S. Everytime you answer a post lots of new questions
become available to us!.

Written By Franco on August 7th, 2009 @ 5:08 pm


Class 2 messages will be stored on the recipients SIM instead of on the phone.

There are more advanced ways to interact with the SIM via SMS… More about that in a future post.


Written By Jeroen on August 10th, 2009 @ 8:54 pm

Looking at Protocol Identifier
It says that if bit 7 is set to 0
and bit 6 is set to 1 one has a choice of
selecting rest of bits Example: 000001
(Replace short message type 1)
Code = 01000001 = 41(hex)
Si if I send a sms with phone number xyz
and with Protocol Identifier 41(hex)
and lets suppose I sent a link and user stored
sms at his phone.
After 7 days the link I had; changed to a
new URL.
So I send a new sms with the new link, same phone and
same Protocol identifier, is it right to say that
the existing sms at the recepients phone will be replaced silently by this new sms?

Written By Franco on August 12th, 2009 @ 7:23 pm

I am sorry but when I tried it.
Effectively, the new one replaces the old one.
Unfortunately NOT SILENTLY!.
Meaning that the old one, as such, disappears.
This is indeed a very useful tool to ovoid too many sms and keeping up to date certain messages.

Written By Franco on August 12th, 2009 @ 8:07 pm

This is exactly what was intended with the protocol identifier you used. You can manage up to 7 messages this way.


Written By Jeroen on August 12th, 2009 @ 8:09 pm

Your thoughts on the different octets that
one could choose from Protocol Identifier
will be appreciated.

Short Message Type 0
000001 Replace Short Message Type 1 (Used this one)
000010 Replace Short Message Type 2
000011 Replace Short Message Type 3
000100 Replace Short Message Type 4
000101 Replace Short Message Type 5
000110 Replace Short Message Type 6
000111 Replace Short Message Type 7
001000..011110 Reserved
011111 Return Call Message
100000..111100 Reserved
111101 ME Data download
111110 ME De-personalization Short MEssage
111111 SIM Data download

Written By Franco on August 12th, 2009 @ 8:10 pm


It seems you’re finding your way around the specs just fine. If I’d answer all your questions in detail, I’d be robbing myself of many future posts. So I kindly ask you to be patient, or (as you’re already doing) explore on your own for now.


Written By Jeroen on August 12th, 2009 @ 9:10 pm

This is good…… I got the total content from this article……Nice for improving our project

Written By Kasi on September 4th, 2009 @ 1:01 am

help me to send messages in PDU mode,how to convert to GSM-7???? help me…

Written By umesh on September 14th, 2009 @ 3:57 am

This article shows (visually) how to pack GSM-7 characters into septets. Two other articles “GSM-7 Encoding with the GNU iconv library” and “How to pack GSM-7 characters into septets” give very explicit examples on how to code this in C.

If you need to know more on the GSM-7 character set you should look into 3GPP TS 23.038 (take for instance version 7.0.0). This document has a table with all the GSM-7 characters and their values.

Good luck,

Written By Jeroen on September 14th, 2009 @ 11:15 am

Hi Jeroen:

I would like to know if there is a way to change the sender’s phone number in a sms by using PDU mode.
Best regards,

Written By ariel on September 15th, 2009 @ 7:33 am


No unfortunately (or fortunately) this is not possible, the sender’s phone number is inserted by a piece of equipment in the operator’s network (called the MSC). If you send your message using a (TCP) connection directly to the SMSC this sometimes is possible.


Written By Jeroen on September 15th, 2009 @ 7:47 am


Thanks for your prompt response. I have another question:
How to create a header using PDU mode?
Best regards,

Written By Ariel on September 15th, 2009 @ 8:03 am


I am not sure what type of header you’re referring to.


Written By Jeroen on September 15th, 2009 @ 8:07 am

Hi Jeroen:

How to include a header into a sms using PDU mode?
I want my sms to a header and a body.
Best regards,

Written By Ariel on September 15th, 2009 @ 8:09 am


SMS text messages don’t have a header and/or body. They’re just 160 characters of plain text (or more if you use concatenation). Most phones will display the first few words of a message as a ‘subject’ in the list of SMS messages in your SMS inbox, but this is not a feature of SMS text messages, but rather something the phones implement.


Written By Jeroen on September 15th, 2009 @ 8:34 am

Hi Jeroen’

Thanks for your explanation. I think that I misunderstood the concept of UDH in sms. I thought the UDH would display in a sms text.
Best regards,

Written By Ariel on September 15th, 2009 @ 8:51 am


For examples of how the UDH is used see the article “What are EMS messages?”.


Written By Jeroen on September 15th, 2009 @ 9:31 am

Hi Jeroen,

I have two related questions:
1.I would like to send a sms with delivery confirmation. How do I accomplish this?
2.Does the delivery confirmation force the SMSC to resend the sms when the sms does not go through?
Best regards,

Written By Ariel on September 16th, 2009 @ 7:42 pm


1. To ask for a delivery confirmation you have to set the third bit in the PDU type octet (e.g. SUBMIT = 0×01, SUBMIT + Status Report = 0×21).
2. The SMSC will try to deliver the SMS until it expires. The expiry can be set in your PDU, but there will be some limit imposed by the SMSC (e.g. you could tell to keep trying for a year, but likely the SMSC will only try for a few days). The delivery reports (status reports) don’t change a thing regarding this, the only thing it does is send a special message to you (with different PDU type) when the message is delivered or deleted.


Written By Jeroen on September 16th, 2009 @ 10:04 pm

I thought that for a submit and status report
it is 0010 0001 = 0×21 ?
Well, I wanted to ask about the delivery confirmation!.
When the operator or the SMSC sends a delivery confirmation and I do a at+cmgl=4 I get the pdu in the default alphabet (7 bits = septets); is there a way to make the Operator or SMSC send the pdu using something like USC-2 or 8 Bits ?.

Written By franco on September 17th, 2009 @ 8:28 pm


You’re right on the status report bit. I always get confused by the way the 3GPP specs put the bits in the tables.

The delivery confirmations are coded/configured in the SMSC. There is no way (afaik) to make it sent in a different DCS. It probably uses GSM-7 because this is lowest common denominator (all phones support this).


Written By Jeroen on September 18th, 2009 @ 8:03 am

As you stated, when the DCS = 00 for 7Bits or DCS = 08 for UCS-2 or DCS = 04 for 8bits.
Using 04 and 8bits works fine for me,
when I use 05 or 06 I get same message same everything else.
04 implies 00000100
05 implies 00000101
06 implies 00000110
04 implies inmediate display (Alert)
05 implies ME specific
06 implies SIM specific
Am I overlooking something that goes on inside my phone when I use 05 or 06? or is the SMSC server not considering the las two bits?.
I am confused about the results!.
Your thought will be appreciated

Written By Franco on October 15th, 2009 @ 8:23 pm


First, mosts SMSCs don’t look at the content of the PDU. The DCS is part if the PDU and the SMSC will pass on what ever it received. However there are a few SMSCs that filter SMS messages with a non-zero DCS. In these SMSCs you message would not be delivered. Maybe some other reader can correct me, but as far as I know the message gets delivered as-is or not at all. From this perspective the last two bits of the DCS (or any other part of the SMS message) don’t affect the SMSCs behavior.

The DCS values 0×04, 0×05 and 0×06 all have have bit 4 set to 0. The spec says: “Bit 4, if set to 0, indicates that bits 1 to 0 are reserved and have no message class meaning”. So the last 2 bits in your DCS are basically being ignored by the receiving phone.


Written By Jeroen on October 17th, 2009 @ 2:42 pm

Thanks again!.

Written By Franco on October 19th, 2009 @ 7:03 am

hallo !
At first I could not get your calculations to end up, then I saw that you have made a misstake:

at line:

F7 1 1 1 1 0 1 1 1 1101111 = ‘0’

there should be a small ‘o’, that correspond to 111,
captial ‘O’ is 79, 1001111


Written By Lennart Håkansson on October 24th, 2009 @ 12:00 pm


You’re right. I encoded “Howdy y’all” and the ‘O’ should have been ‘o’. I’ve corrected the article.


Written By Jeroen on October 25th, 2009 @ 5:48 pm

Dear friend,
Pl help me. While sending message using pdu mode the length of the character(converted in words) will display in recipient phone. For example if length of the character is 98 means “L” is added in every message. How to rectify it…

Written By nrkarthick on November 23rd, 2009 @ 2:04 am

You’d have to show me your PDU to be able to figure out what is happening…. Could it be that you have the ‘Validity Period Present’ bit set?


Written By Jeroen on November 23rd, 2009 @ 8:41 am

Hi Jeroen
Sorry, I cant figure out the mistake,
Concatenation of sms is success and the recipient get full concatenated sms but that User Data size (98 converted to “L”) is displaying as the starting character before the message. For example, My message is starting like “Dear Friend …..” but because of User Data size I am getting “LDear Friend…..”

Same problem in second message also (Converted 81 is displaying as starting character)

Is there anything to specify the starting Location of character??

Following is the PDU mode concatenated sms for your reference
00 41 00 0C 91 19 0949965958 00 00 A0 05 0003000201 98 C472580E1AD6E7F477BB2C6F289661795D0EB2E6E7F930481876AF41E332BB2C9687E9E539681AB6A7DDE73968186EC3C3E9B31B6496BFDBA0D89C0E72BEED2E10FD0D9AC5E67410B13C7681603957430165EB416F78D90DCABFEB729039DC4EB3F32C90599E2EBBC9739009242FB3C3F4B4BD3C0785C7E377DD4D9F83EE693A1A1476E741

00 41 00 0C 91 190949965958 00 00 89 05 0003000202 81 6F33E85D9783C4F2B07B8C2ECF412650D9AD7EE741F6B03CFDAECF41F2B0FB5C06BDCD20B8FC4DAE8FE97357430165EB41F6F43C4D07BDEB7290BB1C968BF320B13CEC1EA3CB735743016583D267F75B5E06A5CD20F79B0E4ABBE96579794E2F935D0DC5D22A04119FA021B2E87406932E

If I change the 98(User data size) to 00 in first message then I receive “@Dear Friends,…..”.

How to omit that starting character…??

Also shall I use 51 instead of 41 to get delivery report for the send messages. Guide me to get delivery reports for concatenated pdu sms via AT command.

How to track the message reference number??

Thanks in advance…

Written By NRKARTHICK on November 24th, 2009 @ 1:15 am

It seems to me you have an extra User Data Size in your PDUs.

In the first one:
A0 05 0003000201 98 – A0 is the user data size (UDL =160 septets). 05 is the user data header length (UDHL). The next 5 octets or the UDH. Then starts your text. The 98 is not required (and is in fact interpreted as text). Because of this extra octet you probably didn’t have to worry about the offset in bits for your text, but if you remove the 98 you’ll need to pay attention.

The second one:
89 05 0003000202 81 – Basically the same story. The 81 should not be there.

Look at ‘How to pack GSM-7 characters into octets’ and particularly pay attention to the offset bits.


Written By Jeroen on November 24th, 2009 @ 3:15 pm

Hi Jeroen
This is my second question…..
Is it possible to write the long(more than 160) sms in pdu mode using AT+CMGW instead of AT+CMGS (ie: writing long sms in message memory to send to more recipients….)??

Written By NRKARTHICK on November 25th, 2009 @ 12:31 am



Written By Jeroen on November 26th, 2009 @ 3:16 pm

Dear Jeroen,
You are 100% correct…
If i omit that extra octets than i get only symbols as message. So that Extra octet preserves Offset in bits.
I will try to find the solution. Thanks for your help and i will mention your name in my projects.

Written By NRKARTHICK on November 30th, 2009 @ 2:29 am

Dear Jeroen,

My country is india (country Code:+91),
State is Tamilnadu.
For me Local(ie. Inside tamilnadu circle) sms is free but national sms is not free.

But my database contains 100000 phone numbers including national numbers.
I dont know how to omit the national numbers which debit my account balance.
Because i am using 91 as my country code so i cant filter the national numbers.

Through mobile if i try to send sms to national numbers without my country code it will not send and it ask me to include country code but through PDU how to solve this problem? (ie. if i get error then i will continue to send to next number which means that error occured due to national number)

I tried using A1 as mentioned by you but i am getting error.

Following are the Two Scenario for your reference

1. Country Code (91 India) Included
00 41 00 0C 91 19 0949965958 00 00 A0 05 0003000201 98 C472580E1AD6E7F477BB2C6F289661795D0EB2E6E7F930481876A

(This is Ok for Both local and national sms, but i have to send only for local numbers)

2. Country Code Excluded
00 41 00 0A A1 0949965958 00 00 A0 05 0003000201 98 C472580E1AD6E7F477BB2C6F289661795D0EB2E6E7F930481876A

(Error CMS+:500)

Please help me…
Thanks in advance.

Written By Karthick on December 5th, 2009 @ 6:08 am

Dear Jeroen,
Please help me to send SMS without country code because national sms is not free for me but local sms is free.

If I send sms to national numbers directly from phone without country code then it ask me to insert 0 or 91.

Following PDU is for your reference…

00 41 00 0A A1 0949965958 00 00 A0 05 0003000201 98 C472580E1AD6E7F477BB2C6F289661795D0EB2E6E7F930481876AF41E3…


Written By NRKARTHICK on December 6th, 2009 @ 9:51 pm

Your articles are really good and provide lot of information on SMS and GSM standards.

For some time I am doing a research to find a way to replace SMS on the handset with a new message version. This is useful e.g when a one time password is sent via SMS (old password becomes invalid and hence may be replaced with a new message if sender id and message reference are same etc)

Is there anyway of doing it? I have a multiwave GSM modem to play with. I will be thankful for any tip.
I saw someone discussing similar thing in messages above?


Written By Kashif on March 27th, 2010 @ 2:20 pm

OK, I found the answer of my question
(Replacing message on handset with new one)
Setting PID to 01000001 or decimal 65 or hex 41 replace message.

For hardware modems (GSM) it should be set in AT+CSMP
its default value is 17,179,0,0
setting it to 17,179,65,0 make message replace
setting it to 17,179,0,16 makes flash SMS

tested on Siemens and Wavecom modems.

I hope it would help those trying to find this information. I spend lot of time till I read this post and it gave me idea to figure it out.

Written By Kashif on March 27th, 2010 @ 6:42 pm

Hi Jeroen,
with the help of your article am able to send the below message and received correctly as “hellohello”, your article helped me a lot!

> 0011000C911999084443130000AA0AE8329BFD4697D9EC37
+CMGS: 2


but when i tried to send the above message as an combined message by sending message 3 times as shown below, i was able send success but not able to receive correctly in the receiving end.
sending :
> 0041000C91199908444313000011050003000301E8329BFD4697D9EC37
+CMGS: 14

> 0041000C91199908444313000011050003000302E8329BFD4697D9EC37
+CMGS: 15

> 0041000C91199908444313000011050003000303E8329BFD4697D9EC37
+CMGS: 16

but at the receiving end am received message like this “t26v7t26v7t26v7t26v7t26v7t26v7″ it should be “hellohellohellohellohellohello”.
pls help me out to find the problem.

Written By jags on June 16th, 2010 @ 2:07 am

Hi Jeroen,
I have problem with Tp-mr field in pdu format.
I am sending messages throught hyper terminal. And the problem is that i do not get the same message reference (that i set in SMS-SUBMIT) when reading SMS status report:

example: (SMS-SUBMIT)
07918346011033F325 08 0B918336234567F800001873B8BCDC2EBBD565F71B242ECFCBE434FB0D72B95C
my message reference is : 08

what i get is: (STATUS REPORT)
+CMD: 06550B918336234567F801702001723480017020017244800000000012
returned message reference is: 55(hex)

As i see the problem is in that the modem “override” my message reference because this message reference is the one that is on SIM card(TP-MR -> incremental field) which is used in case if you set message reference to 00(let modem choose).

I do not know how to tell modem not to “override” it. I think there must be some kind of AT COMMAND to tell that. Or it can be a trick in addtional pdu fileds, but i cannot figure it out i read all the documentation from ETSI.

Please help.

Written By kristl on July 8th, 2010 @ 3:13 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:41 am

i want to send sms from pc to mobile via Java,
can You tell me where i put this code
00 41 00 0C 91 19 0949965958 00 00 A0 05 0003000201 98 C472580E1AD6E7F477BB2C6F289661795D0EB2E6E7F930481876A

Written By Iftequar Ahmed on July 9th, 2011 @ 3:50 am

how can i resolve
CMS ERROR: 304 Invalid PDU mode parameter

Written By Iftequar Ahmed on July 9th, 2011 @ 3:52 am

Hello, sorry to restart this list but I have a problem…
I setup a hyperterminal to send and receive caracters and mos of the AT commands works fine. I mean that I receive SMS, calls … BUT I am unable to call (using the ADT) and unable to send SMS (CMGS or CMSS) each time I try the system stops to send any caracter to the terminal ??? and this in PDU or TEXT mode
Concerning your PDU demo at the beginning you indicate a length of 24 but there is 25 caracters ??? plus the ctrlZ i suppose I miss something
At least what is the pdu to send a message using a local phone number (I mean 06XXXXXXXX from France) ?
Thank’s a lot and congratulations for your work

Written By chris on December 28th, 2011 @ 11:00 am


This structure is sending sms in normal way how can i change it for replacing previous sms?

builder.Append(desaddress(usenumber, numbertype));


length = builder.Length / 2;
builder.Insert(0, encodedsmsc);
return builder.ToString();

Written By marriam on June 3rd, 2012 @ 12:38 am

you are by far the best at explanations i have found. i have a galaxy s2 and when i try to send or recieve oic mess. it say wrong pdu for your device. but texting is fine. is this nornal or shouldnt the phone be capable of both? and how do i fix this?

Written By wendy on January 17th, 2013 @ 12:12 pm

Great Post.
It helped me a lot.

Written By fahad on April 7th, 2013 @ 10:49 pm


  1. Anonymous  on August 24th, 2012 @ 5:32 pm

Add a Comment

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