Erorr In Compile PDU

[a***@gmail.com]

Hi,
When we trying to compile this PDU SMS

07910221020020F040048167383D1170113232848040140500033A0202EC6176BD0C4ACF4134170E06

We Got this Result:

EC6176BD0C4ACF4134170E06

I think there r an errors in Header info.

Thanks,


Source Subject in

http://groups.google.com.eg/group/alt.cellular.gsm/browse_thread/thread/3644c5ba348b355/7800e21198ad40a3?hl=en&

[John Henderson]

Post by a***@gmail.com
When we trying to compile this PDU SMS

07910221020020F040048167383D1170113232848040140500033A0202EC6176BD0C4ACF4134170E06

Post by a***@gmail.com
EC6176BD0C4ACF4134170E06
I think there r an errors in Header info.
Thanks,
Source Subject in

http://groups.google.com.eg/group/alt.cellular.gsm/browse_thread/thread/3644c5ba348b355/7800e21198ad40a3?hl=en&

Your PDU looks good to me. It's part 2 of a 2-part concatenated
message. It carries the 13-character text:

value is 4.80

The brief decode is:

07910221020020F0 SMSC
40 PDU-type: RP no, UDHI yes, SR no, MMS yes, MT
04816738 originator
3D PID
11 DCS: 7-bit default alphabet, ME specific
70113232848040 SMSC timestamp
14 UDL: 20 characters (7 pseudo-characters + 13 actual)
0500033A0202 UDH
EC6176BD0C4ACF4134170E06 UD without UDH: "value is 4.80"

If your problem is decoding "EC6176BD0C4ACF4134170E06" to get
"value is 4.80", that's likely because you're not allowing for
the padding of the text to the next septet boundary following
the UDH, and the necessary alignment of the text to the
beginning of the entire UD field. Instead of trying to decode
"EC6176BD0C4ACF4134170E06" while taking the existence of the
UDH into consideration, it's much easier to decode the entire
UD field, "0500033A0202EC6176BD0C4ACF4134170E06", and throw
away the initial 7 pseudo-characters from the decode.

That there are 7 pseudo-characters is given by the UDHI bit
being turned on within the PDU-type octet, taken together with
the UDH length of "05" (the first octet within the UD).

One octet for UDH length + 5 octets for UDH gives a total of 6
octets already used within the UD. That's 48 bits, and the
next septet boundary occurs at 49 bits (7 septets at 7 bits
each). As the default alphabet uses one character per septet,
thats 7 leading characters we throw away when decoding the
entire UD field.

Important references: GSM 03.38, sections 4, 6.1.2.1, 6.2.1
GSM 03.40, section 9.2.3.24

John

[a***@gmail.com]

Thanks very much

But I'm trying to translate (EC6176BD0C4ACF4134170E06) by using 7bit
but i failed.
and got this result (lCYkKARgA\)


may u please help me?

[John Henderson]

Post by a***@gmail.com
Thanks very much
But I'm trying to translate (EC6176BD0C4ACF4134170E06) by
using 7bit but i failed.
and got this result (lCYkKARgA\)

That's the correct decode, but only if
"EC6176BD0C4ACF4134170E06" is the whole UD field.

Earlier, we worked out that your UD field contained a UDH, and
that the whole UD field is
"0500033A0202EC6176BD0C4ACF4134170E06".

As I tried to say in a previous post, you can decode this longer
string as if it were all text, and throw away the first 7
characters. What remains will be the actual 13-character text
you want. Doing this will _automatically_ align the decode to
the correct boundaries.

If you want to decode just the "EC6176BD0C4ACF4134170E06", then
you need to allow for the fact that the first character in your
decode is the eighth septet (character) of the whole UD field.
And the first octet "EC" of the part which interests you here
is the seventh octet of the UD.

Numbering the octets in the whole UD for reference, and
expanding them to binary, we get:

1 05 00000101
2 00 00000000
3 03 00000011
4 3A 00111010
5 02 00000010
6 02 00000010
7 EC 11101100
8 61 01100001
9 76 01110110
10 BD 10111101
11 0C 00001100
12 4A 01001010
13 CF 11001111
14 41 01000001
15 34 00110100
16 17 00010111
17 0E 00001110
18 06 00000110

We're now decoding from octet 7 ("EC") above, numbering the
resulting characters from 1. I stress again that the decode
aligns to the start of the whole UD field, not the start of the
part after the UDH.

I'm numbering the bits in each octet from 1 on the right to 8 on
the left.

char # from octet, bits bit pattern value
1 7, 2-8 1110110 v
2 8, 1-7 1100001 a
3 9, 1-6 & 8, 8 110110 0 l
4 10, 1-5 & 9, 7-8 11101 01 u
5 11, 1-4 & 10, 6-8 1100 101 e
6 12, 1-3 & 11, 5-8 010 0000 <space>
7 13, 1-2 & 12, 4-8 11 01001 i
8 14, 1 & 13, 3-8 1 110011 s
9 14, 2-8 0100000 <space>
10 15, 1-7 0110100 4
11 16, 1-6 & 15, 8 010111 0 .
12 17, 1-5 & 16, 7-8 01110 00 8
13 18, 1-4 & 17, 6-8 0110 000 0

I hope you can understand my English when you've got the worked
result to look at.

John

[a***@gmail.com]

Thanks very much;


I want ask u about Decoding:

why it = 11 (xxxxxxx3D "11"xxxxxxx)
not : 00 7bit //04 8bit //08 16

And how I can know if PDU data contains pseudo-characters ??

sorry for frequent questions..

[John Henderson]

Post by a***@gmail.com
why it = 11 (xxxxxxx3D "11"xxxxxxx)
not : 00 7bit //04 8bit //08 16

That "11" is the DCS (data coding scheme) octet. In binary,
it's "00010001". Working through those bits from left to
right:

00 data coding: general
0 SMS is not compressed
1 the right most 2 bits indicate the message class
00 message is encoded using 7-bit default alphabet
01 message class 1, ME specific

The message class indicates the intended "destination" of the
SMS once received. The two bits gives us 4 possible classes,
from class 0 to class 3, as follows:

class 0: if possible, display the message immediately on the
screen, and don't store it anywhere.

class 1: ME (handset/modem/device) specific. Store the message
in the phone memory if possible.

class 2: SIM specific. Store the message on the SIM if
possible.

class 3: TE (terminal equipment) specific. If possible, pass
the message directly to another piece of equipment that is
connected to the phone. This will be connected via a serial
cable (RS232 or USB), IrDA, or Bluetooth.

GSM 03.38 has this to say about class 1:

"When a mobile terminated message is Class 1, the MS shall send
an acknowledgement to the SC when the message has
successfully reached the MS and can be stored. The MS shall
normally store the message in the ME by default, if that is
possible, but otherwise the message may be stored elsewhere,
e.g. in the SIM. The user may be able to override the
default meaning and select their own routing."

As to why the sender used DCS = "11" instead of "00", I can't
answer that. Effectively, there'd be no difference in the
result.

Post by a***@gmail.com
And how I can know if PDU data contains pseudo-characters ??

They'll be there every time the UD contains a UDH. And that
information is given to you by the UDHI (user data header
indicator) bit being turned on within the PDU-type octet. The
standards sometimes refer to the PDU-type octet as the "first
octet" (or just "<fo>"), because it's the first octet after the
SCA (service centre address).

UDHI is the second bit from the left in the PDU-type octet. In
your PDU, the PDU-type octet was "40" hex, or "01000000"
binary. So UDHI = 1, and therefore the UD contains a UDH.

The length of the UDH is given by UDHL (user data header
length). This is the first octet in the UD. In your case, it
is "05" (hex). This means that the UD contains 5 octets of
UDH, plus the 1 octet for the UDHL itself. That's 6 octets of
UD taken by UDH. But the text doesn't start immediately after
the UDH, because the text must be padded to a septet boundary.
Given 48 bits (6 octets) of UDH, the next septet boundary is at
bit 49 (7 * 7). And bit 49 of the UD is where my decode
started, although it was aligned all the way back to the UDHL.

Post by a***@gmail.com
sorry for frequent questions..

That's OK. They were questions for me once too :)

John

[a***@gmail.com]

Thanks Jone very much

And I want ask u about:

Do u have any PHP script to read PDU ??

[John Henderson]

Post by a***@gmail.com
Thanks Jone very much
Do u have any PHP script to read PDU ??

No, sorry.

John

[a***@gmail.com]

Thanks vey much
Is:

" That "11" is the DCS (data coding scheme) octet. In binary,
it's "00010001". Working through those bits from left to
right: "


That is: DCS (data coding scheme) octet ,, Or Hex??

11 in Octel = 1001
11 in Hex = 10001

??

thanks again

[John Henderson]

Post by a***@gmail.com
Thanks vey much
" That "11" is the DCS (data coding scheme) octet. In binary,
it's "00010001". Working through those bits from left to
right: "
That is: DCS (data coding scheme) octet ,, Or Hex??
11 in Octel = 1001
11 in Hex = 10001
??

It's an octet, so it's 8 bits. In most other contexts an octet
is called a "byte".

Octets are always represented in hexadecimal. So your DCS value
is "11" hex. Each digit in this hex representation is 4 bits.
So each hex "1" is "0001" binary, making your DCS "00010001"
binary. Of course that's "10001" binary if you suppress the
leading zeros, but I find it less confusing to see them when
doing decodes.

John

[a***@gmail.com]

Many Thanks jon,


I have anther querstion about:

How I can decode Sender ID if it like following (it's not hex but it
7bit How I can know that):

07911989414057500414D032584C4683DD7239580C00087011914060240060062706440633064406270645002006390644064A06430645002006480

thank again

[John Henderson]

Post by a***@gmail.com
How I can decode Sender ID if it like following (it's not hex

It's encoded in exactly the same way as 7-bit text in a User
Data field. In other words, using the packing algorithm from
GSM 03.38, section 6.1.2.1.1. The unpacked septets (7-bit
characters) then get looked up in the table from GSM 03.38,
section 6.2.1.

The Originator Address field from your message is
14D032584C4683DD7239580C. It decodes like this:

14 OA length: 14 hex (20 decimal) semi-octets
D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5)
32584C4683DD7239580C OA string "20124079901", as follows:

Numbering the octets of 7-bit data from 1 to 10 gives us this
binary data:

1 32 00110010
2 58 01011000
3 4C 01001100
4 46 01000110
5 83 10000011
6 DD 11011101
7 72 01110010
8 39 00111001
9 58 01011000
10 0C 00001100

The decode goes like this: Numbering the bits in a octet from 1
on the right to 8 on the left, the first septet consists of
octet 1, bits 1 to 7: 0110010, = "2" (from lookup in GSM 03.38,
6.2.1).

The second septet contains octet 2, bits 1 to 6 and octet 1, bit
8: 0110000, "0".

Putting the whole 10 octets (encoding 11 septets) into columns
we get:

septet from octet, bits bit pattern value
1 1, 1-7 0110010 2
2 2, 1-6 & 1, 8 011000 0 0
3 3, 1-5 & 2, 7-8 01100 01 1
4 4, 1-4 & 3, 6-8 0110 010 2
5 5, 1-3 & 4, 5-8 011 0100 4
6 6, 1-2 & 5, 4-8 01 10000 0
7 7, 1 & 6, 3-8 0 110111 7
8 7, 2-8 0111001 9
9 8, 1-7 0111001 9
10 9, 1-6 & 8, 8 011000 0 0
11 10, 1-5 & 9, 7-8 01100 01 1

John

[m***@gmail.com]

Hi John,

I have 3 different problem
1. I can not get 'normal text' for this message :
06912618010000640B912618819088F200F5702110805300826C06050423F40000424547494E3A56434152440D0A56455253494F4E3A322E310D0A5245563A3230303731313235543033353935325A0D0A4E3A3B4172656B2D5374616E6C65793B3B3B0D0A54454C3B43454C4C3A30383838313135353333330D0A454E443A56434152440D0A
another sample message :
07912618485400F9440B912618274067F100F5601002021061828406050423F40000424547494E3A56434152440D0A56455253494F4E3A322E310D0A4E3A48656E64726F3B0D0A54454C3B43454C4C3A2B363539333637333132310D0A4F52473A36332048756D6520417665202330322D30312048696C6C7669657720477265656E20436F6E646F202862697320393633290D0A454E443A56434152440D0A
Can you explain me, how to get the 'normal text' for that PDU
2. I need to get text for Originator Address. The Originator Address
must be TELKOMSEL. How to get that Originator Address text and do you
have any link about the documentation for this.
Message :
07912618018758F30410D0D42273F96C4E8B4C00008040422191328297D0323BEC3E9FC36E50968E6629EBED301D24ABBD60B4170C070ABAC96150BBEC26C3E9EBB01B749687E9E93908076ABBE920717A1C968741F3F23CDC0E83A865F6FADD9E97D92E10B42C47A7E975F739EC0685C96110390D0AAFD1693948CC7683E8E1731A1D76834C207A593E2ED3C36B109C0C92A7DDE374D80D8297E5E3F03A0C0FBB01
3. When I try to get total parts of message using your explanation, it
gets 53. Actually, In my mobile phone only about 3 or 4 concatenated
message. How to get the right total parts of message ? The message :
06912618010000600C91261892931174000040306102947400A006080400350201CCB7BD0C4ACF41F0303D5D76D341613719949E83D66937990562BFED65507A0E72BFE9207539CC7ED7E7A0B71C247E87E774739DBD03A5E9A0F41CE47ED34161B9FC7D0EBBE9A0B71C24AF93CB2E970BC47CDBCB2071392C9F83C26C36888E4EBBCF7316485C66A7CBF6F21C1466B3417474DA7D9EB340E837BC0C0AB3D9203A3AED3ECF59

Thank you,

Best regards,

Martha

[John Henderson]

Post by m***@gmail.com
Hi John,
I have 3 different problem

I'll handle your two messages in your part 1 query seperately.

I seriously doubt that these two messages are meant to be
human-readable. They're 8-bit data, specifically addressed to
a particular "machine" port on the destination handset.

Nevertheless, I have begun the decoding process for the first
message as follows:

06912618010000 SCA

64 PDU-type (hex)
01100100 PDU-type (binary) as follows:
0 reply path (not set)
1 UDHI (UDHI is set - UD has a UDH)
1 SRI (set - delivery acknowlegment requested)
00 spare
1 MMS (no more messages waiting delivery)
00 MTI (SMS type "MT" = SMS deliver = a "received" message)

0B912618819088F2 OA (originator address)

00 PID

F5 DCS (hex)
11110101 DCS (binary) as follows:
1111 data coding/message class
0 spare bit (must be zero)
1 message data is 8-bit
01 ME-specific (for phone, not SIM)

70211080530082 SCTS (1 Dec 07, 08:35:00, GMT + 7 hours)

6C UDL, 6C hex = 108 decimal
06 UDHL, the next 6 octets are UDH (header)
05 application port addressing, 16-bit address
04 information element length (4 octets follow)
23F4 destination port, 9204 decimal -
GSM 03.40 says: "As allocated by IANA (http://www.IANA.com/)"

0000 originator port

42 B (these are all just 8-bit ASCII values)
45 E
47 G
49 I
4E N
3A :
56 8
43 C
41 A
52 R
44 D
0D <carriage return>
0A <line feed>
56 8
45 E
52 R
53 S
49 I
4F O
4E N
3A :
32 2
2E .
31 1

I'll leave the rest of these two messages to you to decode.

John

[John Henderson]

Post by John Henderson
42 B
45 E
47 G
49 I
4E N
56 8
43 C
41 A
52 R
44 D
0D <carriage return>
0A <line feed>
56 8
45 E
52 R
53 S
49 I
4F O
4E N
32 2
2E .
31 1

The two char 56 hex above, which I decoded as "8", should decode
to "V".

According to
http://mobile.act.cmis.csiro.au/comp3410/assignment.asp this
"port 23F4" message is an address book update. The URL has
much good detail on this type of SMS.

John

[a***@gmail.com]

Hi john

Thanks very much

I'll try and if any prob. I'll back


thanks

[a***@gmail.com]

OK john,

But is it like D0 always in alphanumeric sender id ?

in (D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5) )

[John Henderson]

Post by a***@gmail.com
OK john,
But is it like D0 always in alphanumeric sender id ?
in (D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5) )

Yes, type-of-address "D0" is always alphanumeric, always using
the 7-bit default alphabet, and always encoded in exactly the
same way as a 7-bit message text.

The other two common type-of-address (hex) values are:

91 international format. Always begins with the country code.
In other words, you understand that the number begins with "+".

81 national format. No country code is present - just a number
within a country.

John

[a***@gmail.com]

That is good.

Thanks Very Much John ..

[John Henderson]

Post by m***@gmail.com
2. I need to get text for Originator Address. The Originator
Address must be TELKOMSEL. How to get that Originator Address
text and do you have any link about the documentation for

OK, the OA (originator address) element for this next message
is:

10D0D42273F96C4E8B4C

10 OA is 10 hex (16 decimal) semi-octets long
D0 type of address (hex)
11010000 type of address (binary) as follows:
1 reserved (must be "1")
101 alphanumeric (7-bit default alphabet)
0000 must be "0000" when leading bits are "1101"

"D42273F96C4E8B4C" carries the encoded OA, which does indeed
decode to "TELKOMSEL".

The decoding of the OA element is covered in GSM 03.40, section
9.1.2.5. This is where the OA length and type-of-address are
covered in detail. Because type-of-address is alphanumeric in
this case (type = "D0"), you must decode it according to GSM
03.38 section 6.1.2.1.1 "Packing of 7-bit characters", and
section 6.2.1 (default alphabet lookup table). You can
download these GSM technical standards from www.etsi.org or
www.3gpp.org and other sources you can find using google.

"D42273F96C4E8B4C" decodes to "TELKOMSEL" using exactly the same
mechanical procedure as "32584C4683DD7239580C" decodes to
"20124079901" in the example I worked for alfarok in a recent
post. In this case, I decoded it using a program.

Post by m***@gmail.com
3. When I try to get total parts of message using your
explanation, it gets 53. Actually, In my mobile phone only
about 3 or 4 concatenated message. How to get the right total

In the next message, the UDHI bit is set within the PDU-type
octet (as is correct for a concatenated message). There's
nothing special about the PID or the UDH (both are "00"). So
I'll go straight to the UDH field, beginning with the UDL:

A0 UDL: A0 hex = 160 decimal septets
06 UDHL, the next 6 octets are UDH (header)
08 concatenated short message using 16-bit numbering
04 information element length (4 octets follow)
0035 16-bit message number, 35 hex (53 decimal)
02 message has 2 parts
01 this is part 1

For the detailed explanation, please see GSM 03.40, sections
9.2.3.24 and 9.2.3.24.8.

John

[Martha Sasongko]

Hi John,

Thank you for your comprehensive answer above.
It helps me much.
I have 1 next question
1. How to set PDU, so the receiver can receive the sender not as a
phone number, but a string (like TELKOMSEL). I don't find any
explanation about this issue in PDU Format for SMS-SUBMIT in 03.40
article.

Thank you,

Best regards,

Martha

[John Henderson]

Post by m***@gmail.com
Hi John,
Thank you for your comprehensive answer above.
It helps me much.
I have 1 next question
1. How to set PDU, so the receiver can receive the sender not
as a phone number, but a string (like TELKOMSEL). I don't find
any explanation about this issue in PDU Format for SMS-SUBMIT
in 03.40 article.

You cannot set the originator address of messages submitted
"over the air". The originator address is always set by the
SMSC with which the SMS is lodged, and to the best of my
knowledge is always set to the actual sender's number.

To have any chance of controlling the content of the originator
address field, you must establish a relationship with a
commercial message centre direct lodgement bureau service, and
submit messages using a protocol such as SMPP over TCP/IP. I
referred someone in another thread to
http://en.wikipedia.org/wiki/Short_message_peer-to-peer_protocol
and that article should give you some useful terms for a search
engine.

John

[lin]

John Henderson 在 2008年3月26日 星期三上午10:17:37 [UTC+8] 的信中寫道：

Post by John Henderson
As I tried to say in a previous post, you can decode this longer
string as if it were all text, and throw away the first 7
characters. What remains will be the actual 13-character text
you want. Doing this will _automatically_ align the decode to
the correct boundaries.

Hi John,
Thanks for explaining how to decode PDU SMS that UD containing UDH, this confused me for a long time.

I have a problem here, as you said "throw away the first 7 characters".
Is it because the length of UDH(0500033A0202) is 6 bytes (48bits), so a fill bit needs to be added between UDH and SM to make SM starts from the septet boundary? (the length of UDH now is 7 bytes(49 bits), so the first 7 characters of the whole UD we decode are pseudo characters, meaningless)

If it is, as I know UDH can have different lengths, e.g.
1. 060804F42E0201
2. 080701030003080202
The length of the UDH in the first example is 7 bytes (49 bits), so I can decode the SM directly, or decode the whole UD and remove the first 7 characters.
In the second example, UDL is 9 bytes (72 bits), so there are 5 fill bits to make UDH 77bits and then SM can start on septet boundary. So UDH uses 11 septets, after decoding the whole UD, I should remove the first 11 characters to get the real SMS content.

Do i understand correctly?

[lin]

John Henderson 在 2008年3月26日 星期三上午10:17:37 [UTC+8] 的信中寫道：

Post by John Henderson
As I tried to say in a previous post, you can decode this longer
string as if it were all text, and throw away the first 7
characters. What remains will be the actual 13-character text
you want. Doing this will _automatically_ align the decode to
the correct boundaries.

Hi John,
Thanks for explaining how to decode PDU SMS that UD containing UDH, this confused me for a long time.

I have a problem here, as you said "throw away the first 7 characters".
Is it because the length of UDH(0500033A0202) is 6 bytes (48bits), so a fill bit needs to be added between UDH and SM to make SM starts from the septet boundary? (the length of UDH now is 7 bytes(49 bits), so the first 7 characters of the whole UD we decode are pseudo characters, meaningless)

If it is, as I know UDH can have different lengths, e.g.
1. 060804F42E0201
2. 080701030003080202
The length of the UDH in the first example is 7 bytes (56 bits), so I can decode the SM directly, or decode the whole UD and remove the first 8 characters.
In the second example, UDL is 9 bytes (72 bits), so there are 5 fill bits to make UDH 77bits and then SM can start on septet boundary. So UDH uses 11 septets, after decoding the whole UD, I should remove the first 11 characters to get the real SMS content.

Do i understand correctly?

[cathexis]

Post by m***@gmail.com
Hi John,
Thanks for explaining how to decode PDU SMS that UD containing UDH, this
confused me for a long time.

Thank you for your follow-up question to my post.

Post by m***@gmail.com
I have a problem here, as you said "throw away the first 7 characters".
Is it because the length of UDH(0500033A0202) is 6 bytes (48bits), so a
fill bit needs to be added between UDH and SM to make SM starts from the
septet boundary? (the length of UDH now is 7 bytes(49 bits), so the first
7 characters of the whole UD we decode are pseudo characters, meaningless)
If it is, as I know UDH can have different lengths, e.g.
1. 060804F42E0201
2. 080701030003080202
The length of the UDH in the first example is 7 bytes (56 bits), so I can
decode the SM directly, or decode the whole UD and remove the first 8
characters. In the second example, UDL is 9 bytes (72 bits), so there are
5 fill bits to make UDH 77bits and then SM can start on septet boundary.
So UDH uses 11 septets, after decoding the whole UD, I should remove the
first 11 characters to get the real SMS content.
Do i understand correctly?

You do.

In your second example, the value of 5 bits 73 through 77 have no relevance
to the decode. Their "correct" value is undefined.

But they form part of the 11th septet (starting at the beginning of the
whole UD). It follows that the 11th 7-bit character from that decode is
likewise undefined.

John