Cellular GSM Technology - Erorr In Compile PDU

Author

Erorr In Compile PDU

alfarok@gmail.com

2008-03-05, 10:33 pm

Hi,
When we trying to compile this PDU SMS

07910221020020F04004
8167383D117011323284
8040140500033A0202EC
6176BD0C4ACF4134170E
06

We Got this Result:

EC6176BD0C4ACF413417
0E06

I think there r an errors in Header info.

Thanks,

Source Subject in

http://groups.google.com.eg/group/a...98ad40a3?hl=en&

John Henderson

2008-03-05, 10:33 pm

alfarok@gmail.com wrote:

> When we trying to compile this PDU SMS
>
>
07910221020020F04004
8167383D117011323284
8040140500033A0202EC
6176BD0C4ACF4134170E
06
>
> We Got this Result:
>
> EC6176BD0C4ACF413417
0E06
>
> I think there r an errors in Header info.
>
> Thanks,
>
>
> Source Subject in
>
>
http://groups.google.com.eg/group/a...98ad40a3?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
EC6176BD0C4ACF413417
0E06 UD without UDH: "value is 4.80"

If your problem is decoding " EC6176BD0C4ACF413417
0E06" 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
" EC6176BD0C4ACF413417
0E06" while taking the existence of the
UDH into consideration, it's much easier to decode the entire
UD field, " 0500033A0202EC6176BD
0C4ACF4134170E06", 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

alfarok@gmail.com

2008-03-25, 10:33 am

Thanks very much

But I'm trying to translate (EC6176BD0C4ACF41341
70E06) by using 7bit
but i failed.
and got this result (lCYkKARgA=06=04=02=
07\)

may u please help me?

John Henderson

2008-03-25, 10:33 pm

alfarok@gmail.com wrote:

> Thanks very much
>
> But I'm trying to translate (EC6176BD0C4ACF41341
70E06) by
> using 7bit but i failed.
> and got this result (lCYkKARgA\)

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

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

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 " EC6176BD0C4ACF413417
0E06", 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

alfarok@gmail.com

2008-03-26, 10:33 pm

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

2008-03-26, 10:33 pm

alfarok@gmail.com wrote:

> I want ask u about Decoding:
>
> 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.

> 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.

> sorry for frequent questions..

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

John

alfarok@gmail.com

2008-03-30, 12:33 pm

Thanks Jone very much

And I want ask u about:

Do u have any PHP script to read PDU ??

John Henderson

2008-03-30, 3:33 pm

alfarok@gmail.com wrote:

> Thanks Jone very much
>
> And I want ask u about :
>
> Do u have any PHP script to read PDU ??

No, sorry.

John

alfarok@gmail.com

2008-04-01, 3:33 pm

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

2008-04-01, 10:33 pm

alfarok@gmail.com wrote:

> 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
>
> ??

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

LinkBot