|
Cellular forums Home > Archive > Cellular GSM Technology > December 2007 > long SMS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| etrby@hotmail.com 2007-11-02, 3:33 pm |
| how can I get long SMS "more thank 160 or 70 characters " as one SMS
by using GSM modem ?
| |
| John Henderson 2007-11-02, 3:33 pm |
| etrby@hotmail.com wrote:
> how can I get long SMS "more thank 160 or 70 characters " as
> one SMS by using GSM modem ?
Are you trying to join the individual parts of a received
multi-part (concatenated) message into the original long
message?
You'll need to operate in PDU-mode, and decipher the UDH (User
Data Header) of each individual SMS to determine which longer
message each belongs to, and which specific part of that longer
message each one is. Then decode and concatenate the
individual short texts.
See GSM 03.40, clause 9.2.3.24 for details. You'll also need
information from GSM 07.05 and 03.38.
Sending a long message by breaking it down into individual parts
is a reversal of this procedure. But take care to use the
required filler bits so that the UDH ends on a septet boundary
as per GSM 03.40.
This is a large topic, and you may have further specific
questions.
John
| |
| etrby@hotmail.com 2007-11-02, 3:33 pm |
| On 2 , 20:54, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> Are you trying to join the individual parts of a received
> multi-part (concatenated) message into the original long
> message?
>
> You'll need to operate in PDU-mode, and decipher the UDH (User
> Data Header) of each individual SMS to determine which longer
> message each belongs to, and which specific part of that longer
> message each one is. Then decode and concatenate the
> individual short texts.
>
> See GSM 03.40, clause 9.2.3.24 for details. You'll also need
> information from GSM 07.05 and 03.38.
>
> Sending a long message by breaking it down into individual parts
> is a reversal of this procedure. But take care to use the
> required filler bits so that the UDH ends on a septet boundary
> as per GSM 03.40.
>
> This is a large topic, and you may have further specific
> questions.
>
> John
actually I'm interested in receiving long SMS as I got long binary SMS
but I could not translate it , some time the 1st part coming later and
it should be arranged , the long message containing important info as
it is a money transfer info SMS coming from the GSM operator so it is
very important to translate it right can u help me from which part I
should start ? thx
| |
| John Henderson 2007-11-02, 10:33 pm |
| etrby@hotmail.com wrote:
> actually I'm interested in receiving long SMS as I got long
> binary SMS but I could not translate it , some time the 1st
> part coming later and it should be arranged , the long message
> containing important info as it is a money transfer info SMS
> coming from the GSM operator so it is very important to
> translate it right can u help me from which part I should
> start ? thx
Are you looking at the messages in PDU-mode? Siemens published
a good introduction to PDU mode, and I've located a copy at:
http://www.jazi.staff.ugm.ac.id/ Mo...sms_pdumode.pdf
You're looking at section 2.1 "SMS-DELIVER (Mobile Terminated)".
Can you identify and tell us the PDU-type octet, the PID, the
DCS and (if you can work out that the UDHI bit is set within
PDU-type) the UDH? There's nothing confidential in those
pieces of information, and it gives us a good starting point.
John
| |
| etrby@hotmail.com 2007-11-03, 4:33 am |
| On 3 , 00:59, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> Are you looking at the messages in PDU-mode? Siemens published
> a good introduction to PDU mode, and I've located a copy at:http://www.jazi.staff.ugm.ac.id/ Mo...0Documents/s...
>
> You're looking at section 2.1 "SMS-DELIVER (Mobile Terminated)".
> Can you identify and tell us the PDU-type octet, the PID, the
> DCS and (if you can work out that the UDHI bit is set within
> PDU-type) the UDH? There's nothing confidential in those
> pieces of information, and it gives us a good starting point.
>
> John
thank u john
i can send u the SMSs i got if u want?
| |
| John Henderson 2007-11-03, 4:33 am |
| etrby@hotmail.com wrote:
> thank u john
> i can send u the SMSs i got if u want?
If that suits you, you could either post the PDUs here or e-mail
them to me. Just remove the "RemoveThis" from my e-mail
address if you want to go that way.
John
| |
| etrby@hotmail.com 2007-11-03, 12:33 pm |
| On 3 , 07:15, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> If that suits you, you could either post the PDUs here or e-mail
> them to me. Just remove the "RemoveThis" from my e-mail
> address if you want to go that way.
>
> John
ok John here it is the messages i got
+CMGR: 1,,121
07910221020020F04004
8167383D197011100033
32406A0500033E030306
310635064A062F064300
2006270644062C062F06
4A062F00200647064800
2000330036002E003700
390020062C0646064A06
29002006480020062706
44063506440627062D06
4A062900200647064900
2000310036002F003100
31002F00300037002E
+CMGR: 1,,153
07910221020020F04004
8167383D197011100033
42408A0500033E030100
3200300032003A002006
440642062F0020064606
2C062D062A0020062706
44062D06310643062900
20063106420645002000
43003000370031003100
300031002E0030003000
330035002E0030003000
30003300200644062A06
2D0648064A0644002000
350020062C0646064A06
29002006450646002006
27064406310642064500
20
+CMGR: 1,,149
07910221020020F04404
8167383D197011100033
5240860500033E030200
30003100320034003000
37003900390030003100
2E00200642064A064506
290020062A062D064806
4A064406430020064706
4900200034002E003800
300020062C0646064A06
29060C00200631063306
45002006270644062A06
2D0648064A0644002006
47064800200030002E00
3200300020062C064606
4A0629002E0020
| |
| John Henderson 2007-11-03, 10:33 pm |
| etrby@hotmail.com wrote:
> ok John here it is the messages i got
>
> +CMGR: 1,,121
>
07910221020020F04004
8167383D197011100033
32406A0500033E030306
310635064A062F064300
2006270644062C062F06
4A062F00200647064800
2000330036002E003700
390020062C0646064A06
29002006480020062706
44063506440627062D06
4A062900200647064900
2000310036002F003100
31002F003000370
02E
That's certainly an interesting message. It is part 3 of a
3-part concatenated message. It is in Arabic. And it uses a
special protocol (PID) specified by the SMSC (apparently
"Mobinil", Egypt, by the SMSC address) and apparently
understood by the handsets it has previously modified in some
way.
It is specifically addressed to a handset (and not intended for
SIM storage). As your modem can't process it as intended, I
expect it has stored it unmodified on the SIM anyway (this is
required behaviour when a mesage can't be processed properly).
I've fully decoded this message for you, except that I haven't
looked up the Arabic characters (which mean nothing to me).
They are the 4-character hexadecimal sequences towards the end
of the decode beginning with "06". You can look them up
yourself at http://www.unicode.org/charts/PDF/U0600.pdf
The characters beginning with "00" are given by
http://www.unicode.org/charts/PDF/U0000.pdf
07 SCA address length (octets)
91 type of number (international)
0221020020F0 SMSC address: +20122000020
40 PDU-type (01000000 binary, as follows)
0 reply path not set
1 UDH is present
0 no status report requested
00 not used (spare)
0 this SMSC has more messages for you
00 MT (Mobile Terminate) message, "SMS Deliver"
04 originator address length (number of digits)
81 type of number ("unknown", national)
6738 originator address: 7683
3D PID: telematic working, SMSC-defined (GSM 03.40, 9.2.3.9)
19 DCS: uncompressed UCS2, addressed to the handset itself
70111000333240 SMSC timestamp: 00:33:23, 01 Nov 07, GMT + 1 hour
6A UDL: 106 decimal
05 UDHL: the next 5 octets are UDH (header)
00 concatenated message using 8-bit numbering
03 information element length (3 octets follow)
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts to this message
03 this is part 3
0631
0635
064A
062F
0643
0020 <space>
0627
0644
062C
062F
064A
062F
0020 <space>
0647
0648
0020 <space>
0033 3
0036 6
002E .
0037 7
0039 9
0020 <space>
062C
0646
064A
0629
0020 <space>
0648
0020 <space>
0627
0644
0635
0644
0627
062D
064A
0629
0020
0647
0649
0020 <space>
0031 1
0036 6
002F /
0031 1
0031 1
002F /
0030 0
0037 7
002E .
>
> +CMGR: 1,,153
>
07910221020020F04004
8167383D197011100033
42408A0500033E030100
3200300032003A002006
440642062F0020064606
2C062D062A0020062706
44062D06310643062900
20063106420645002000
43003000370031003100
300031002E0030003000
330035002E0030003000
30003300200644062A06
2D0648064A06440
02000350020062C06460
64A06290020064506460
02006270644063106420
6450020
I have partially decoded this (part 1 of 3) for you. I'll leave
you to tackle the UCS2 text.
07910221020020F0 SCA
40 PDU-type
04816738 OA (originator address)
3D PID
19 DCS
70111000334240 SMSC timestamp: 00:33:24, 01 Nov 07, GMT + 1 hour
8A UDL
05 UDHL
00
03
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts
01 this is part 1
0032
0030
0032
003A
0020
0644
0642
062F
0020
0646
062C
062D
062A
0020
0627
0644
062D
0631
0643
0629
0020
0631
0642
0645
0020
0043
0030
0037
0031
0031
0030
0031
002E
0030
0030
0033
0035
002E
0030
0030
0030
0033
0020
0644
062A
062D
0648
064A
0644
0020
0035
0020
062C
0646
064A
0629
0020
0645
0646
0020
0627
0644
0631
0642
0645
0020
>
> +CMGR: 1,,149
>
07910221020020F04404
8167383D197011100033
5240860500033E030200
30003100320034003000
37003900390030003100
2E00200642064A064506
290020062A062D064806
4A064406430020064706
4900200034002E003800
300020062C0646064A06
29060C00200631063306
45002006270644062A06
2D0648064A06440
02006470648002000300
02E003200300020062C0
646064A0629002E0020
And this is part 2 of 3.
07910221020020F0 SCA
44 PDU-type (no more messages this time)
04816738 OA
3D PID
19 DCS
70111000335240 SMSC timestamp: 00:33:25, 01 Nov 07, GMT + 1 hour
86 UDL
05 UDHL
00
03
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts
02 this is part 2
0030
0031
0032
0034
0030
0037
0039
0039
0030
0031
002E
0020
0642
064A
0645
0629
0020
062A
062D
0648
064A
0644
0643
0020
0647
0649
0020
0034
002E
0038
0030
0020
062C
0646
064A
0629
060C
0020
0631
0633
0645
0020
0627
0644
062A
062D
0648
064A
0644
0020
0647
0648
0020
0030
002E
0032
0030
0020
062C
0646
064A
0629
002E
0020
John
| |
| etrby@hotmail.com 2007-11-03, 10:33 pm |
| On 3 , 07:15, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> If that suits you, you could either post the PDUs here or e-mail
> them to me. Just remove the "RemoveThis" from my e-mail
> address if you want to go that way.
>
> John
John I can't read ur last reply plz resend it
| |
| John Henderson 2007-11-03, 10:33 pm |
| This is a repost, as requested, but with the PDUs wrapped.
etrby@hotmail.com wrote:
> ok John here it is the messages i got
>
> +CMGR: 1,,121
07910221020020F04004
8167383D197011100033
32406A0500033E030306
310635064A062F064300
2006270644062C062F06
4A062F00200647064800
2000330036002E003700
390020062C0646064A06
29002006480020062706
44063506440627062D06
4A062900200647064900
2000310036002F003100
31002F00300037002E
That's certainly an interesting message. It is part 3 of a
3-part concatenated message. It is in Arabic. And it uses a
special protocol (PID) specified by the SMSC (apparently
"Mobinil", Egypt, by the SMSC address) and apparently
understood by the handsets it has previously modified in some
way.
It is specifically addressed to a handset (and not intended for
SIM storage). As your modem can't process it as intended, I
expect it has stored it unmodified on the SIM anyway (this is
required behaviour when a mesage can't be processed properly).
I've fully decoded this message for you, except that I haven't
looked up the Arabic characters (which mean nothing to me).
They are the 4-character hexadecimal sequences towards the end
of the decode beginning with "06". You can look them up
yourself at http://www.unicode.org/charts/PDF/U0600.pdf
The characters beginning with "00" are given by
http://www.unicode.org/charts/PDF/U0000.pdf
07 SCA address length (octets)
91 type of number (international)
0221020020F0 SMSC address: +20122000020
40 PDU-type (01000000 binary, as follows)
0 reply path not set
1 UDH is present
0 no status report requested
00 not used (spare)
0 this SMSC has more messages for you
00 MT (Mobile Terminate) message, "SMS Deliver"
04 originator address length (number of digits)
81 type of number ("unknown", national)
6738 originator address: 7683
3D PID: telematic working, SMSC-defined (GSM 03.40, 9.2.3.9)
19 DCS: uncompressed UCS2, addressed to the handset itself
70111000333240 SMSC timestamp: 00:33:23, 01 Nov 07, GMT + 1 hour
6A UDL: 106 decimal
05 UDHL: the next 5 octets are UDH (header)
00 concatenated message using 8-bit numbering
03 information element length (3 octets follow)
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts to this message
03 this is part 3
0631
0635
064A
062F
0643
0020 <space>
0627
0644
062C
062F
064A
062F
0020 <space>
0647
0648
0020 <space>
0033 3
0036 6
002E .
0037 7
0039 9
0020 <space>
062C
0646
064A
0629
0020 <space>
0648
0020 <space>
0627
0644
0635
0644
0627
062D
064A
0629
0020
0647
0649
0020 <space>
0031 1
0036 6
002F /
0031 1
0031 1
002F /
0030 0
0037 7
002E .
> +CMGR: 1,,153
07910221020020F04004
8167383D197011100033
42408A0500033E030100
3
200300032003A0020064
40642062F00200646062
C062D062A00200627064
4
062D0631064306290020
06310642064500200043
00300037003100310030
0
031002E0030003000330
035002E0030003000300
03300200644062A062D0
6
48064A06440020003500
20062C0646064A062900
20064506460020062706
4
40631064206450020
I have partially decoded this (part 1 of 3) for you. I'll
leave you to tackle the UCS2 text.
07910221020020F0 SCA
40 PDU-type
04816738 OA (originator address)
3D PID
19 DCS
70111000334240 SMSC timestamp: 00:33:24, 01 Nov 07, GMT + 1 hour
8A UDL
05 UDHL
00
03
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts
01 this is part 1
0032
0030
0032
003A
0020
0644
0642
062F
0020
0646
062C
062D
062A
0020
0627
0644
062D
0631
0643
0629
0020
0631
0642
0645
0020
0043
0030
0037
0031
0031
0030
0031
002E
0030
0030
0033
0035
002E
0030
0030
0030
0033
0020
0644
062A
062D
0648
064A
0644
0020
0035
0020
062C
0646
064A
0629
0020
0645
0646
0020
0627
0644
0631
0642
0645
0020
> +CMGR: 1,,149
07910221020020F04404
8167383D197011100033
5240860500033E030200
3
00031003200340030003
70039003900300031002
E00200642064A0645062
9
0020062A062D0648064A
06440643002006470649
00200034002E00380030
0
020062C0646064A06290
60C00200631063306450
02006270644062A062D0
6
48064A06440020064706
4800200030002E003200
300020062C0646064A06
2
9002E0020
And this is part 2 of 3.
07910221020020F0 SCA
44 PDU-type (no more messages this time)
04816738 OA
3D PID
19 DCS
70111000335240 SMSC timestamp: 00:33:25, 01 Nov 07, GMT + 1hour
86 UDL
05 UDHL
00
03
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts
02 this is part 2
0030
0031
0032
0034
0030
0037
0039
0039
0030
0031
002E
0020
0642
064A
0645
0629
0020
062A
062D
0648
064A
0644
0643
0020
0647
0649
0020
0034
002E
0038
0030
0020
062C
0646
064A
0629
060C
0020
0631
0633
0645
0020
0627
0644
062A
062D
0648
064A
0644
0020
0647
0648
0020
0030
002E
0032
0030
0020
062C
0646
064A
0629
002E
0020
John
| |
| etrby@hotmail.com 2007-11-04, 4:33 am |
| On 3 , 23:57, John Henderson <jhenRemoveT...@talk21.com> wrote:
> This is a repost, as requested, but with the PDUs wrapped.
>
> et...@hotmail.com wrote:
>
>
> 07910221020020F04004
8167383D197011100033
32406A0500033E030306
> 310635064A062F064300
2006270644062C062F06
4A062F00200647064800
> 2000330036002E003700
390020062C0646064A06
29002006480020062706
> 44063506440627062D06
4A062900200647064900
2000310036002F003100
> 31002F00300037002E
>
> That's certainly an interesting message. It is part 3 of a
> 3-part concatenated message. It is in Arabic. And it uses a
> special protocol (PID) specified by the SMSC (apparently
> "Mobinil", Egypt, by the SMSC address) and apparently
> understood by the handsets it has previously modified in some
> way.
>
> It is specifically addressed to a handset (and not intended for
> SIM storage). As your modem can't process it as intended, I
> expect it has stored it unmodified on the SIM anyway (this is
> required behaviour when a mesage can't be processed properly).
>
> I've fully decoded this message for you, except that I haven't
> looked up the Arabic characters (which mean nothing to me).
> They are the 4-character hexadecimal sequences towards the end
> of the decode beginning with "06". You can look them up
> yourself athttp://www.unicode.org/charts/PDF/U0600.pdf
>
> The characters beginning with "00" are given byhttp://www.unicode.org/charts/PDF/U0000.pdf
>
> 07 SCA address length (octets)
> 91 type of number (international)
> 0221020020F0 SMSC address: +20122000020
>
> 40 PDU-type (01000000 binary, as follows)
>
> 0 reply path not set
> 1 UDH is present
> 0 no status report requested
> 00 not used (spare)
> 0 this SMSC has more messages for you
> 00 MT (Mobile Terminate) message, "SMS Deliver"
>
> 04 originator address length (number of digits)
> 81 type of number ("unknown", national)
> 6738 originator address: 7683
>
> 3D PID: telematic working, SMSC-defined (GSM 03.40, 9.2.3.9)
>
> 19 DCS: uncompressed UCS2, addressed to the handset itself
>
> 70111000333240 SMSC timestamp: 00:33:23, 01 Nov 07, GMT + 1 hour
>
> 6A UDL: 106 decimal
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts to this message
> 03 this is part 3
>
> 0631
> 0635
> 064A
> 062F
> 0643
> 0020 <space>
> 0627
> 0644
> 062C
> 062F
> 064A
> 062F
> 0020 <space>
> 0647
> 0648
> 0020 <space>
> 0033 3
> 0036 6
> 002E .
> 0037 7
> 0039 9
> 0020 <space>
> 062C
> 0646
> 064A
> 0629
> 0020 <space>
> 0648
> 0020 <space>
> 0627
> 0644
> 0635
> 0644
> 0627
> 062D
> 064A
> 0629
> 0020
> 0647
> 0649
> 0020 <space>
> 0031 1
> 0036 6
> 002F /
> 0031 1
> 0031 1
> 002F /
> 0030 0
> 0037 7
> 002E .
>
>
> 07910221020020F04004
8167383D197011100033
42408A0500033E030100
3
> 200300032003A0020064
40642062F00200646062
C062D062A00200627064
4
> 062D0631064306290020
06310642064500200043
00300037003100310030
0
> 031002E0030003000330
035002E0030003000300
03300200644062A062D0
6
> 48064A06440020003500
20062C0646064A062900
20064506460020062706
4
> 40631064206450020
>
> I have partially decoded this (part 1 of 3) for you. I'll
> leave you to tackle the UCS2 text.
>
> 07910221020020F0 SCA
> 40 PDU-type
> 04816738 OA (originator address)
> 3D PID
> 19 DCS
> 70111000334240 SMSC timestamp: 00:33:24, 01 Nov 07, GMT + 1 hour
> 8A UDL
> 05 UDHL
> 00
> 03
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts
> 01 this is part 1
>
> 0032
> 0030
> 0032
> 003A
> 0020
> 0644
> 0642
> 062F
> 0020
> 0646
> 062C
> 062D
> 062A
> 0020
> 0627
> 0644
> 062D
> 0631
> 0643
> 0629
> 0020
> 0631
> 0642
> 0645
> 0020
> 0043
> 0030
> 0037
> 0031
> 0031
> 0030
> 0031
> 002E
> 0030
> 0030
> 0033
> 0035
> 002E
> 0030
> 0030
> 0030
> 0033
> 0020
> 0644
> 062A
> 062D
> 0648
> 064A
> 0644
> 0020
> 0035
> 0020
> 062C
> 0646
> 064A
> 0629
> 0020
> 0645
> 0646
> 0020
> 0627
> 0644
> 0631
> 0642
> 0645
> 0020
>
>
> 07910221020020F04404
8167383D197011100033
5240860500033E030200
3
> 00031003200340030003
70039003900300031002
E00200642064A0645062
9
> 0020062A062D0648064A
06440643002006470649
00200034002E00380030
0
> 020062C0646064A06290
60C00200631063306450
02006270644062A062D0
6
> 48064A06440020064706
4800200030002E003200
300020062C0646064A06
2
> 9002E0020
>
> And this is part 2 of 3.
>
> 07910221020020F0 SCA
> 44 PDU-type (no more messages this time)
> 04816738 OA
> 3D PID
> 19 DCS
> 70111000335240 SMSC timestamp: 00:33:25, 01 Nov 07, GMT + 1hour
> 86 UDL
> 05 UDHL
> 00
> 03
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts
> 02 this is part 2
>
> 0030
> 0031
> 0032
> 0034
> 0030
> 0037
> 0039
> 0039
> 0030
> 0031
> 002E
> 0020
> 0642
> 064A
> 0645
> 0629
> 0020
> 062A
> 062D
> 0648
> 064A
> 0644
> 0643
> 0020
> 0647
> 0649
> 0020
> 0034
> 002E
> 0038
> 0030
> 0020
> 062C
> 0646
> 064A
> 0629
> 060C
> 0020
> 0631
> 0633
> 0645
> 0020
> 0627
> 0644
> 062A
> 062D
> 0648
> 064A
> 0644
> 0020
> 0647
> 0648
> 0020
> 0030
> 002E
> 0032
> 0030
> 0020
> 062C
> 0646
> 064A
> 0629
> 002E
> 0020
>
> John
thank u John very much for ur help .
1-yes this message had been delivered to a handset and then resent to
the modem as I can't decode similar message which directly sent to the
modem
2- what do u think if such messages sent to modem directly could be
decoded right ? it seems from ur reply it is a complicated process to
decode such messages and need very special skills in SMS techniques
which I don't have it .
| |
| John Henderson 2007-11-04, 4:33 am |
| etrby@hotmail.com wrote:
> thank u John very much for ur help .
> 1-yes this message had been delivered to a handset and then
> resent to the modem as I can't decode similar message which
> directly sent to the modem
I hope it all made sense when you looked up the Arabic
characters and reconstructed the long message.
> 2- what do u think if such messages sent to modem directly
> could be decoded right ? it seems from ur reply it is a
> complicated process to decode such messages and need very
> special skills in SMS techniques which I don't have it .
I'd write a program to automatically read and decode these
messages from a PC connected to the modem.
It's not too hard with those 16-bit UCS2 characters. It's much
harder to unpack messages which use the SMS default 7-bit
alphabet. Then the translation algorithm needs lots of bit
manipulation because parts of each 7-bit character get spread
across different octets in a complex pattern.
John
| |
| etrby@hotmail.com 2007-11-05, 10:33 pm |
| On Nov 4, 7:27 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> I hope it all made sense when you looked up the Arabic
> characters and reconstructed the long message.
>
>
> I'd write a program to automatically read and decode these
> messages from a PC connected to the modem.
>
> It's not too hard with those 16-bit UCS2 characters. It's much
> harder to unpack messages which use the SMS default 7-bit
> alphabet. Then the translation algorithm needs lots of bit
> manipulation because parts of each 7-bit character get spread
> across different octets in a complex pattern.
>
> John
thank u John
1- does ur PC program read the PDU code and translate it to TXT ?
2- is it a shareware ?
3- I need to ask how could I know that all these 3 messages r a one
message ? is it by OA "04816738 " ??? and then know in which part of
message am I by this code "03 there are 3 parts to this message
03 this is part 3 " right ?
| |
| John Henderson 2007-11-05, 10:33 pm |
| etrby@hotmail.com wrote:
> thank u John
> 1- does ur PC program read the PDU code and translate it to
> TXT ?
Yes, but it's a "work in progress". That means it never gets
finished. And so far, I haven't put in any code to handle
USC2. It just 7-bit and 8-bit text encodings. And more
importantly from your point of view, I haven't coded anything
to link up the parts on multi-part messages yet. Nor have I
given it a friendly Windows-type user interface.
There're a lot of other clever things possible with messages
which use a UDH (whether concatenated or not). Pre-defined
sounds and animations, video attributes (like underlining,
bolding and overstriking), and user-defined graphics are a few
examples of what's available. Decoding and representing some
of these is a programming nightmare.
> 2- is it a shareware ?
If I ever get it developed to the point I'm happy with it, it
will be :)
I wouldn't hold my breath though.
> 3- I need to ask how could I know that all these 3 messages r
> a one message ? is it by OA "04816738 " ??? and then know in
> which part of message am I by this code
> "03 there are 3 parts to this message
> 03 this is part 3 " right ?
Yes, exactly. But there is still scope for ambiguity.
Late-model handsets routinely reassemble concatenated messages
without problems. The actual algorithms used in handsets are
known only to the manufacturers, so I can't comment on them.
3GPP 23.040 (the later version of GSM 03.40, which includes
UMTS) says this (in clause 9.2.3.24.1):
"Each concatenated short message contains a reference number
which together with the originating address and Service Centre
address allows the receiving entity to discriminate between
concatenated short messages sent from different originating
SMEs and/or SCs. In a network which has multiple SCs, it is
possible for different segments of a concatenated SM to be sent
via different SCs and so it is recommended that the SC address
should not be checked by the MS unless the application
specifically requires such a check."
Firstly, note that your messages are encoded with 8-bit
mumbering as per my decode. While 16-bit numbering is also
available, I haven't seen it used.
8-bit numbering means that long messages go from 0 to 255, and
then roll back to reuse 0, 1, 2, etc.
This numbering relates to the messages from a certain sending
device. So the first long message sent to you by Fred and
George will both be message zero. But after Fred has sent you
256 long messages, his device will "reuse" message number zero.
So you might have undeleted messages which conflict with later
messages from the same sender in their numbering. I intend
using the SMSC timestamp to untangle things if this occurs.
John
| |
| etrby@hotmail.com 2007-11-07, 10:33 pm |
| On Nov 6, 3:08 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> Yes, but it's a "work in progress". That means it never gets
> finished. And so far, I haven't put in any code to handle
> USC2. It just 7-bit and 8-bit text encodings. And more
> importantly from your point of view, I haven't coded anything
> to link up the parts on multi-part messages yet. Nor have I
> given it a friendly Windows-type user interface.
>
> There're a lot of other clever things possible with messages
> which use a UDH (whether concatenated or not). Pre-defined
> sounds and animations, video attributes (like underlining,
> bolding and overstriking), and user-defined graphics are a few
> examples of what's available. Decoding and representing some
> of these is a programming nightmare.
>
>
> If I ever get it developed to the point I'm happy with it, it
> will be :)
>
> I wouldn't hold my breath though.
>
>
> Yes, exactly. But there is still scope for ambiguity.
> Late-model handsets routinely reassemble concatenated messages
> without problems. The actual algorithms used in handsets are
> known only to the manufacturers, so I can't comment on them.
>
> 3GPP 23.040 (the later version of GSM 03.40, which includes
> UMTS) says this (in clause 9.2.3.24.1):
>
> "Each concatenated short message contains a reference number
> which together with the originating address and Service Centre
> address allows the receiving entity to discriminate between
> concatenated short messages sent from different originating
> SMEs and/or SCs. In a network which has multiple SCs, it is
> possible for different segments of a concatenated SM to be sent
> via different SCs and so it is recommended that the SC address
> should not be checked by the MS unless the application
> specifically requires such a check."
>
> Firstly, note that your messages are encoded with 8-bit
> mumbering as per my decode. While 16-bit numbering is also
> available, I haven't seen it used.
>
> 8-bit numbering means that long messages go from 0 to 255, and
> then roll back to reuse 0, 1, 2, etc.
>
> This numbering relates to the messages from a certain sending
> device. So the first long message sent to you by Fred and
> George will both be message zero. But after Fred has sent you
> 256 long messages, his device will "reuse" message number zero.
> So you might have undeleted messages which conflict with later
> messages from the same sender in their numbering. I intend
> using the SMSC timestamp to untangle things if this occurs.
>
> John
hi John
after searching in many sites I got a PDU message didn't match with
ur PDU formatting would u plz explain to me why there is a difference
between this 2 format ?
This is a normal sms with time stamp
07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
FD4697D9EC37
Sender Id start from 0B
between smsc and sender id 2 numbers
This is the different SMS :
0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
A7E741F7B79C4D0E01
Sender Id start from 04
between smsc and sender id 4 numbers why ?
TP-SCTS. Time stamp didn't appear here ?? also why
the only difference I knew is that the 1st SMS was received and the
2nd was sent
can u help ???
| |
| John Henderson 2007-11-08, 4:33 am |
| etrby@hotmail.com wrote:
> hi John
> after searching in many sites I got a PDU message didn't
> match with ur PDU formatting would u plz explain to me why
> there is a difference between this 2 format ?
>
> This is a normal sms with time stamp
>
07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
FD4697D9EC37
> Sender Id start from 0B
> between smsc and sender id 2 numbers
>
>
> This is the different SMS :
>
0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
A7E741F7B79C4D0E01[c
olor=darkred]
> Sender Id start from 04
> between smsc and sender id 4 numbers why ?
> TP-SCTS. Time stamp didn't appear here ?? also why
>
> the only difference I knew is that the 1st SMS was received
> and the 2nd was sent
> can u help ???[/color]
As you say, the difference is that the first example is an "MT"
(mobile terminate), or "SMS-deliver" message, while the second
is an "MO" (mobile originate), or "SMS-submit" message.
That difference is given by the MTI (message type indicator)
field, which is the right-most two bits within the PDU-tpe
octet. The PDU-type is "04" hex = "01000000" binary in the
first message, and "11" hex = "00010001" binary in the second.
Certain other SMS header fields will depend on this MTI value
too. For example, an MO SMS contains a message reference
octet, while an MT SMS does not. The destination address (DA)
field in an MO SMS is the originator address (OA) field in an
MT SMS.
The SMSC timestamp in an MT SMS is the VP (validity period
field) in an MO SMS. And VP can be 0, 1 or 7 octets long,
depending on the value of the two VPF (validity period format)
bits embedded within the PDU-type octet. An MO VP can be
non-existent (zero octets), relative (1 octet), or absolute (7
octets, in which case it's exactly the same format as a
TP-SCTS). In your second example, VP is relative (VPF = "10"
binary), and VP is set to the single octet "FF" (the maximum,
or 63 weeks). This is the time an SMSC is supposed to continue
trying to deliver an undeliverable SMS, although in practice
most SMSCs impose an upper limit of 3 to 7 days for keeping
undeliverable messages.
Please note that address fields are variable length, with the
first octet of an address field giving the length. In the SCA
(service centre address), that figure is for the number of
octets (including the type-of-number octet), while in DA and OA
address fields, it refers to the number of BCD digits
(excluding filler digits) in the address itself.
John
| |
| John Henderson 2007-11-08, 4:33 am |
| I wrote:
> The PDU-type is "04" hex = "01000000" binary in the first
> message, and "11" hex = "00010001" binary in the second.
I usually manage to make at least one mistake. "04" is
"00000100" binary, of course.
John
| |
| John Henderson 2007-11-08, 4:33 am |
| etrby@hotmail.com wrote:
> hi John
> after searching in many sites I got a PDU message didn't
> match with ur PDU formatting would u plz explain to me why
> there is a difference between this 2 format ?
>
> This is a normal sms with time stamp
>
07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
FD4697D9EC37
> Sender Id start from 0B
> between smsc and sender id 2 numbers
>
>
> This is the different SMS :
>
0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
A7E741F7B79C4D0E01[c
olor=darkred]
> Sender Id start from 04
> between smsc and sender id 4 numbers why ?[/color]
I wasn't very clear about the 2 versus 4 hex digits.
As an MO SMS, the second example must contain a MR (message
reference). In this case, it's the octet "51" between the
PDU-type octet ("11") and the DA ("04818116").
An MT SMS does not carry an MR, so this octet is not present in
your first example. It's used between the sending device and
the accepting SMSC only.
MR is normally coded as "00" in an SMS-submit PDU, and the
actual number to be used is calculated by reading the
Last-Used-TP-MR value from the EF_SMSS elementary file at SIM
address 6F43 (GSM 03.40, clause 9.2.3.6 and GSM 11.11, clause
10.5.7). But an actual non-zero value is required in special
circumstances.
The actual value used is returned after sending, as "+CMGS:
<mr>" when using the "AT+CMGS" command for example.
John
| |
| etrby@hotmail.com 2007-11-09, 3:33 pm |
| On Nov 8, 8:18 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
>
> 07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
FD4697D9EC37>=
Sender Id start from 0B
>
>
> 0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
A7E741F7B79C4=
D0=ADE01
>
>
> I wasn't very clear about the 2 versus 4 hex digits.
>
> As an MO SMS, the second example must contain a MR (message
> reference). In this case, it's the octet "51" between the
> PDU-type octet ("11") and the DA ("04818116").
>
> An MT SMS does not carry an MR, so this octet is not present in
> your first example. It's used between the sending device and
> the accepting SMSC only.
>
> MR is normally coded as "00" in an SMS-submit PDU, and the
> actual number to be used is calculated by reading the
> Last-Used-TP-MR value from the EF_SMSS elementary file at SIM
> address 6F43 (GSM 03.40, clause 9.2.3.6 and GSM 11.11, clause
> 10.5.7). But an actual non-zero value is required in special
> circumstances.
>
> The actual value used is returned after sending, as "+CMGS:
> <mr>" when using the "AT+CMGS" command for example.
>
> John
thank u John
I hope i didn't bothering u with my questions
1- how do u know that this message was decoded 7 ,8 or 16 bits ?
| |
| John Henderson 2007-11-09, 10:33 pm |
| etrby@hotmail.com wrote:
> I hope i didn't bothering u with my questions
Not at all. It's my pleasure.
> 1- how do u know that this message was decoded 7 ,8 or 16 bits
In the three PDUs from your modem, the DCS (data coding scheme)
was "19" hex (00011001 binary). You use GSM 03.38, section 4
to decode this as follows:
00 general data coding
0 uncompressed
1 the 2 right-most DSC bits have meaning
10 UCS2 (16 bit)
01 ME (handset) specific
Later you gave two other example PDUs. The first was:
07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
FD4697D9EC37
and the second:
0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
A7E741F7B79C4D0E01
In both these examples, the DCS is "00". This is the normal DCS
value most devices default to. Working through it:
00 general data coding
0 uncompressed
0 the 2 right-most DSC bits have no meaning
00 default alphabet (7-bit)
00 has no meaning, as above
The 7-bit alphabet is given in GSM 03.38, sections 6.2.1 and
6.2.1.1. The 7-bit characters defined there are packed into
octets (8-bit units) using the algorithm in GSM 03.38, section
6.1.2.1.1.
The text of the first message decodes as: "<lf>PKYY QKYY "
(where "<lf>" is the line-feed character, ASCII 10 decimal),
and the second message text is "Hello,my pretty world!".
John
| |
| etrby@hotmail.com 2007-11-18, 10:33 pm |
| On Nov 10, 2:10 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> Not at all. It's my pleasure.
>
>
> In the three PDUs from your modem, the DCS (data coding scheme)
> was "19" hex (00011001 binary). You use GSM 03.38, section 4
> to decode this as follows:
>
> 00 general data coding
> 0 uncompressed
> 1 the 2 right-most DSC bits have meaning
> 10 UCS2 (16 bit)
> 01 ME (handset) specific
>
> Later you gave two other example PDUs. The first was:
>
> 07917283010010F5040B
C87238880900F1000099
3092516195800AE8329B
> FD4697D9EC37
>
> and the second:
>
> 0891683108200805F011
51048181160000FF16C8
329BFD66B5F320B8BC4C
> A7E741F7B79C4D0E01
>
> In both these examples, the DCS is "00". This is the normal DCS
> value most devices default to. Working through it:
>
> 00 general data coding
> 0 uncompressed
> 0 the 2 right-most DSC bits have no meaning
> 00 default alphabet (7-bit)
> 00 has no meaning, as above
>
> The 7-bit alphabet is given in GSM 03.38, sections 6.2.1 and
> 6.2.1.1. The 7-bit characters defined there are packed into
> octets (8-bit units) using the algorithm in GSM 03.38, section
> 6.1.2.1.1.
>
> The text of the first message decodes as: "<lf>PKYY QKYY "
> (where "<lf>" is the line-feed character, ASCII 10 decimal),
> and the second message text is "Hello,my pretty world!".
>
> John
thank u Jhon
we got a very strange error in 7 bit conversion , as 3c hex which
means "<" in the 7 bit table conversion don't work like this the
message
07911989414057500414
D032584C4683DD723958
0C000170119130044200
0DD3303BDC7E8382ECF2
FADD06
| |
| etrby@hotmail.com 2007-11-18, 10:33 pm |
| On Nov 19, 1:26 am, et...@hotmail.com wrote:
> On Nov 10, 2:10 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thank u Jhon
> we got a very strange error in 7 bit conversion , as 3c hex which
> means "<" in the 7 bit table conversion don't work like this the
> message
> 07911989414057500414
D032584C4683DD723958
0C000170119130044200
0DD3303BDC7E83=
8-2ECF2FADD06- Hide quoted text -
>
> - Show quoted text -
When we tried to translate above pdu we got this result:
=D30;=DC~=83,=EC=F2=
FA=DD=06
| |
| John Henderson 2007-11-18, 10:33 pm |
| etrby@hotmail.com wrote:
> we got a very strange error in 7 bit conversion , as 3c hex
> which means "<" in the 7 bit table conversion don't work like
> this the message
>
07911989414057500414
D032584C4683DD723958
0C000170119130044200
0DD3303BDC7E8382ECF2
FADD06
I'm not sure where you're seeing or decoding "3c" hex or "<" in
the above message. My decode is:
07 SCA address length (octets)
91 type of number (international)
198941405750 SMSC address: +919814047505 (country "+91" = India)
04 PDU-type (00000100 binary, as follows)
0 reply path not set
0 no UDH present
0 no status report requested
00 not used (spare)
1 this SMSC has no more messages for you
00 MT (Mobile Terminate) message, "SMS Deliver"
14 originator address (OA) length (more on this later)
D0 type of number: alphanumeric, as per GSM 03.40, 9.1.2.5
32584C4683DD7239580C
OA: "20124079901"
00 PID (default value)
01 DCS (00000001 binary, as follows)
00 general data coding
0 uncompressed
0 the 2 right-most DSC bits have no meaning
00 default alphabet (7-bit)
01 has no meaning, as above
70119130044200 SMSC timestamp: 03:40:24, 19 Nov 07, GMT
0D UDL: 13 decimal septets long
D3303BDC7E8382ECF2FA
DD06 mesage text: "Salamo Alekom"
The above message contains two elements encoded using the 7-bit
default alphabet from GSM 03.38. They are the UD (user data)
field "Salamo Alekom" and the originator address field
"20124079901".
The OA length is 14 hex = 20 decimal. Because the OA address
type is alphanumeric, this refers to the number of semi-octets
(individual hexadecimal characters) following the OA length
octet. If the type of OA was numeric, OA length would refer to
the number of BCD digits following.
As it turns out, the OA string contains only the 11 numeric
characters "20124079901". Don't let this confuse you - it's
still alphanumeric.
As I mentioned, alphanumeric OAs gets decoded according to the
7-bit default alphabet, as per GSM 03.38, section 6.1.2.1.1.
Numbering the octets from 1 to 10 gives us:
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".
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
We decode the UD in the same way. Numbering the octets:
1 D3 11010011
2 30 00110000
3 3B 00111011
4 DC 11011100
5 7E 01111110
6 83 10000011
7 82 10000010
8 EC 11101100
9 F2 11110010
10 FA 11111010
11 DD 11011101
12 06 00000110
septet from octet, bits bit pattern value
1 1, 1-7 1010011 S
2 2, 1-6 & 1, 8 110000 1 a
3 3, 1-5 & 2, 7-8 11011 00 l
4 4, 1-4 & 3, 6-8 1100 001 a
5 5, 1-3 & 4, 5-8 110 1101 m
6 6, 1-2 & 5, 4-8 11 01111 o
7 7, 1 & 6, 3-8 0 100000 <space>
8 7, 2-8 1000001 A
9 8, 1-7 1101100 l
10 9, 1-6 & 8, 8 110010 1 e
11 10, 1-5 & 9, 7-8 11010 11 k
12 11, 1-4 & 10, 6-8 1101 111 o
13 12, 1-3 & 11, 5-8 110 1101 m
There's no really easy way to understand the GSM 03.39,
6.1.2.1.1 coding mechanism without your head hurting along the
way :(
John
| |
| etrby@hotmail.com 2007-11-24, 4:33 am |
| On Nov 19, 4:04 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> 07911989414057500414
D032584C4683DD723958
0C000170119130044200
0DD3303BDC7E838-2ECF2FADD06
>
> I'm not sure where you're seeing or decoding "3c" hex or "<" in
> the above message. My decode is:
>
> 07 SCA address length (octets)
> 91 type of number (international)
> 198941405750 SMSC address: +919814047505 (country "+91" = India)
> 04 PDU-type (00000100 binary, as follows)
>
> 0 reply path not set
> 0 no UDH present
> 0 no status report requested
> 00 not used (spare)
> 1 this SMSC has no more messages for you
> 00 MT (Mobile Terminate) message, "SMS Deliver"
>
> 14 originator address (OA) length (more on this later)
> D0 type of number: alphanumeric, as per GSM 03.40, 9.1.2.5
> 32584C4683DD7239580C
OA: "20124079901"
> 00 PID (default value)
> 01 DCS (00000001 binary, as follows)
>
> 00 general data coding
> 0 uncompressed
> 0 the 2 right-most DSC bits have no meaning
> 00 default alphabet (7-bit)
> 01 has no meaning, as above
>
> 70119130044200 SMSC timestamp: 03:40:24, 19 Nov 07, GMT
>
> 0D UDL: 13 decimal septets long
> D3303BDC7E8382ECF2FA
DD06 mesage text: "Salamo Alekom"
>
> The above message contains two elements encoded using the 7-bit
> default alphabet from GSM 03.38. They are the UD (user data)
> field "Salamo Alekom" and the originator address field
> "20124079901".
>
> The OA length is 14 hex = 20 decimal. Because the OA address
> type is alphanumeric, this refers to the number of semi-octets
> (individual hexadecimal characters) following the OA length
> octet. If the type of OA was numeric, OA length would refer to
> the number of BCD digits following.
>
> As it turns out, the OA string contains only the 11 numeric
> characters "20124079901". Don't let this confuse you - it's
> still alphanumeric.
>
> As I mentioned, alphanumeric OAs gets decoded according to the
> 7-bit default alphabet, as per GSM 03.38, section 6.1.2.1.1.
> Numbering the octets from 1 to 10 gives us:
>
> 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".
>
> 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
>
> We decode the UD in the same way. Numbering the octets:
>
> 1 D3 11010011
> 2 30 00110000
> 3 3B 00111011
> 4 DC 11011100
> 5 7E 01111110
> 6 83 10000011
> 7 82 10000010
> 8 EC 11101100
> 9 F2 11110010
> 10 FA 11111010
> 11 DD 11011101
> 12 06 00000110
>
> septet from octet, bits bit pattern value
> 1 1, 1-7 1010011 S
> 2 2, 1-6 & 1, 8 110000 1 a
> 3 3, 1-5 & 2, 7-8 11011 00 l
> 4 4, 1-4 & 3, 6-8 1100 001 a
> 5 5, 1-3 & 4, 5-8 110 1101 m
> 6 6, 1-2 & 5, 4-8 11 01111 o
> 7 7, 1 & 6, 3-8 0 100000 <space>
> 8 7, 2-8 1000001 A
> 9 8, 1-7 1101100 l
> 10 9, 1-6 & 8, 8 110010 1 e
> 11 10, 1-5 & 9, 7-8 11010 11 k
> 12 11, 1-4 & 10, 6-8 1101 111 o
> 13 12, 1-3 & 11, 5-8 110 1101 m
>
> There's no really easy way to understand the GSM 03.39,
> 6.1.2.1.1 coding mechanism without your head hurting along the
> way :(
>
> John
thank u John very much for ur patience and help , now I 'am facing
another problem regarding connecting long SMS parts all to gather for
example I have a long SMS coming into 3 parts I can know which part is
1st , 2nd and 3rd part but the problem is if I got many long SMSs
coming from the same sender ID and same SMSC this may make all SMSs
parts to be confused do u have any solution for this problem
| |
| John Henderson 2007-11-24, 4:33 am |
| etrby@hotmail.com wrote:
> thank u John very much for ur patience and help , now I 'am
> facing another problem regarding connecting long SMS parts all
> to gather for example I have a long SMS coming into 3 parts I
> can know which part is 1st , 2nd and 3rd part but the problem
> is if I got many long SMSs coming from the same sender ID and
> same SMSC this may make all SMSs parts to be confused do u
> have any solution for this problem
The most important pieces of information for grouping are the
message number and the OA (sender, "originator address").
A concatenated SMS-submit (MO, "mobile originate") message has
two message numbers, which are totally independent of one
another.
One sits between the PDU-type octet and the DA (destination
address). This is the one which you normally set to zero in
your SMS-submit PDU, and which the phone/modem allocates
dynamically as it sends the message. The value used is
returned in the "+CMGS: " result code. It does not exist in
the SMS-deliver PDU, so you can't use it to identify received
messages. In any case, each part of a concatenated message
would have a different message number in this position.
The second message reference number is put into the UDH (user
data header). This one remains unchanged from SMS-submit PDU
through to SMS-deliver (received) PDU, and will be the same for
all parts of the one long message.
In an earlier post, I decoded the three message parts of a
concatenated message for you. This is the UDH decode from one
of those messages:
6A UDL: 106 decimal
05 UDHL: the next 5 octets are UDH (header)
00 concatenated message using 8-bit numbering
03 information element length (3 octets follow)
3E concatenated message number 3E hex (62 decimal)
03 there are 3 parts to this message
03 this is part 3
The message number I'm talking about is 3E hex (62 decimal) in
this example. All three parts had this message number, and
this identifies which message the three parts belong to, when
viewed in conjunction with the OA.
This number for this OA will eventually roll over (at 255) and
earlier numbers will be reused for later messages. If you keep
messages long enough for this to be a problem, I suggest you
use the SMSC timestamp to untangle the parts.
If you had six messages from the same sender all with UDH
message number 62 decimal, and two messages were part 1, two
were part 2, and two were part 3, then the SMSC timestamps
should allow you to group them correctly. Three timestamps
would be very close together (within a few seconds) and the
other three would also be very close to each other but very
different from the other three.
The decoding of the SMSC timestamp is given in GSM 03.40, clause
9.2.3.11. The Siemens PDU guide at
http://www.jazi.staff.ugm.ac.id/ Mo...sms_pdumode.pdf
also gives some basic information on decoding this and other
PDU header data elements.
I hope that's clear and answers your question. Otherwise,
please let me know.
John
| |
| etrby@hotmail.com 2007-11-29, 3:33 pm |
| On Nov 24, 4:16 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> The most important pieces of information for grouping are the
> message number and the OA (sender, "originator address").
>
> A concatenated SMS-submit (MO, "mobile originate") message has
> two message numbers, which are totally independent of one
> another.
>
> One sits between the PDU-type octet and the DA (destination
> address). This is the one which you normally set to zero in
> your SMS-submit PDU, and which the phone/modem allocates
> dynamically as it sends the message. The value used is
> returned in the "+CMGS: " result code. It does not exist in
> the SMS-deliver PDU, so you can't use it to identify received
> messages. In any case, each part of a concatenated message
> would have a different message number in this position.
>
> The second message reference number is put into the UDH (user
> data header). This one remains unchanged from SMS-submit PDU
> through to SMS-deliver (received) PDU, and will be the same for
> all parts of the one long message.
>
> In an earlier post, I decoded the three message parts of a
> concatenated message for you. This is the UDH decode from one
> of those messages:
>
> 6A UDL: 106 decimal
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts to this message
> 03 this is part 3
>
> The message number I'm talking about is 3E hex (62 decimal) in
> this example. All three parts had this message number, and
> this identifies which message the three parts belong to, when
> viewed in conjunction with the OA.
>
> This number for this OA will eventually roll over (at 255) and
> earlier numbers will be reused for later messages. If you keep
> messages long enough for this to be a problem, I suggest you
> use the SMSC timestamp to untangle the parts.
>
> If you had six messages from the same sender all with UDH
> message number 62 decimal, and two messages were part 1, two
> were part 2, and two were part 3, then the SMSC timestamps
> should allow you to group them correctly. Three timestamps
> would be very close together (within a few seconds) and the
> other three would also be very close to each other but very
> different from the other three.
>
> The decoding of the SMSC timestamp is given in GSM 03.40, clause
> 9.2.3.11. The Siemens PDU guide athttp://www.jazi.staff.ugm.ac.id/ Mobile%20and%20Wirel
ess%20Documents/s...
> also gives some basic information on decoding this and other
> PDU header data elements.
>
> I hope that's clear and answers your question. Otherwise,
> please let me know.
>
> John
thank u John
| |
| aakash78_m@yahoo.co.in 2007-12-19, 4:33 am |
| On Nov 24, 7:16 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
>
> The most important pieces of information for grouping are the
> message number and the OA (sender, "originator address").
>
> A concatenated SMS-submit (MO, "mobile originate") message has
> two message numbers, which are totally independent of one
> another.
>
> One sits between the PDU-type octet and the DA (destination
> address). This is the one which you normally set to zero in
> your SMS-submit PDU, and which the phone/modem allocates
> dynamically as it sends the message. The value used is
> returned in the "+CMGS: " result code. It does not exist in
> the SMS-deliver PDU, so you can't use it to identify received
> messages. In any case, each part of a concatenated message
> would have a different message number in this position.
>
> The second message reference number is put into the UDH (user
> data header). This one remains unchanged from SMS-submit PDU
> through to SMS-deliver (received) PDU, and will be the same for
> all parts of the one long message.
>
> In an earlier post, I decoded the three message parts of a
> concatenated message for you. This is the UDH decode from one
> of those messages:
>
> 6A UDL: 106 decimal
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts to this message
> 03 this is part 3
>
> The message number I'm talking about is 3E hex (62 decimal) in
> this example. All three parts had this message number, and
> this identifies which message the three parts belong to, when
> viewed in conjunction with the OA.
>
> This number for this OA will eventually roll over (at 255) and
> earlier numbers will be reused for later messages. If you keep
> messages long enough for this to be a problem, I suggest you
> use the SMSC timestamp to untangle the parts.
>
> If you had six messages from the same sender all with UDH
> message number 62 decimal, and two messages were part 1, two
> were part 2, and two were part 3, then the SMSC timestamps
> should allow you to group them correctly. Three timestamps
> would be very close together (within a few seconds) and the
> other three would also be very close to each other but very
> different from the other three.
>
> The decoding of the SMSC timestamp is given in GSM 03.40, clause
> 9.2.3.11. The Siemens PDU guide athttp://www.jazi.staff.ugm.ac.id/ Mobile%20and%20Wirel
ess%20Documents/s...
> also gives some basic information on decoding this and other
> PDU header data elements.
>
> I hope that's clear and answers your question. Otherwise,
> please let me know.
>
> John
Hi Joh,
The information you provided in your earlier posts helped me a lot.
However, I still have some question wrt long/concatenated sms.
When I encode a message of length 153 chareecters in 7 bit format and
append(prefixed the header to the mesage as 05 00 01 03 01) the header
to it, some how the message is not getting displayed properly in the
handset. The example message i used is "hellohellohello......" up to
153 characters.
Can you explain me how I should encode the message part. I looked in
to the Mobile originated message and the same is encoded as
differently. I find difference only in the used data that is encoded
in to the deliver sm pdu.
Appreciate your suggestions.
Regards,
Aakash
| |
| John Henderson 2007-12-19, 3:33 pm |
| aakash78_m@yahoo.co.in wrote:
> The information you provided in your earlier posts helped me a
> lot. However, I still have some question wrt long/concatenated
> sms.
>
> When I encode a message of length 153 chareecters in 7 bit
> format and append(prefixed the header to the mesage as 05 00
> 01 03 01) the header to it, some how the message is not
> getting displayed properly in the handset. The example message
> i used is "hellohellohello......" up to 153 characters.
>
> Can you explain me how I should encode the message part. I
> looked in to the Mobile originated message and the same is
> encoded as differently. I find difference only in the used
> data that is encoded in to the deliver sm pdu.
>
> Appreciate your suggestions.
Hi Aakash,
One requirement when encoding an SMS in the default 7-bit
alphabet, and which has a UDH, is to pad the UDH out to the
next septet boundary.
I don't know if this is one of the problems you're having. If
it's not, perhaps you could post your UD encoding so that we
can see where the problem is.
Why do we need to pad the UDH to the next septet boundary?
Basically it's because older phones were not able to join the
parts of concatenated messages they received. Therefore the
best they could do is to display the various message parts as
individual independent messages, and hope that all made sense
to the person reading them. Therefore they display the UDH
without decoding or removing it, as 7 garbage characters before
the actual text. If the UDH was not padded to a septet
boundary, then the text itself would also be garbage (because
it would not be correctly aligned with the beginning of the UD
itself).
You mention a UDH of 0500010301. That's one octet too short.
The leading "05" says that there are five more octets of UDH,
and the remaining "00010301" is only four octets.
Let's assume you want to send part 1 of a 3-part concatenated
SMS, and that the message reference number is 1. That UDH would
be
050003010301
as follows:
05 UDHL: the next 5 octets are UDH (header)
00 concatenated message using 8-bit numbering
03 information element length (3 octets follow)
01 concatenated message number 1
03 there are 3 parts to this message
01 this is part 3
Let's now take your message text "hellohellohello......"
litterally and encode it.
If the UD contained no UDH, then this would encode as:
E8329BFD4697D9EC37BA
CC66BF5D2E97CBE502
But we must pad to the next septet boundary. Because the UDH
takes up 6 octets (48 bits), we've got to pad out to 49 bits (7
septets = 49 bits = the next septet boundary).
I do this by prefixing the message text with 7 "@" characters,
and then overlaying the UDH on top. I use "@" because it's
"0000000" binary in the 7-bit default alphabet, giving me all
the binary zero padding I could possibly need.
" @@@@@@@hellohellohel
lo......" encodes as:
000000000000D06536FB
8D2EB3D96F7499CD7EBB
5C2E97CB05
Overwriting the first 6 octets with the real UDH gives
050003010301D06536FB
8D2EB3D96F7499CD7EBB
5C2E97CB05
And that's our UD field, with the actual text displayed
correctly by new and old phones alike.
John
| |
| kishore.kumarreddy@gmail.com 2007-12-20, 7:33 am |
| On Dec 20, 1:07 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> aakash7...@yahoo.co.in wrote:
>
>
>
>
> Hi Aakash,
>
> One requirement when encoding an SMS in the default 7-bit
> alphabet, and which has a UDH, is to pad the UDH out to the
> next septet boundary.
>
> I don't know if this is one of the problems you're having. If
> it's not, perhaps you could post your UD encoding so that we
> can see where the problem is.
>
> Why do we need to pad the UDH to the next septet boundary?
> Basically it's because older phones were not able to join the
> parts of concatenated messages they received. Therefore the
> best they could do is to display the various message parts as
> individual independent messages, and hope that all made sense
> to the person reading them. Therefore they display the UDH
> without decoding or removing it, as 7 garbage characters before
> the actual text. If the UDH was not padded to a septet
> boundary, then the text itself would also be garbage (because
> it would not be correctly aligned with the beginning of the UD
> itself).
>
> You mention a UDH of 0500010301. That's one octet too short.
> The leading "05" says that there are five more octets of UDH,
> and the remaining "00010301" is only four octets.
>
> Let's assume you want to send part 1 of a 3-part concatenated
> SMS, and that the message reference number is 1. That UDH would
> be
>
> 050003010301
>
> as follows:
>
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 01 concatenated message number 1
> 03 there are 3 parts to this message
> 01 this is part 3
>
> Let's now take your message text "hellohellohello......"
> litterally and encode it.
>
> If the UD contained no UDH, then this would encode as:
>
> E8329BFD4697D9EC37BA
CC66BF5D2E97CBE502
>
> But we must pad to the next septet boundary. Because the UDH
> takes up 6 octets (48 bits), we've got to pad out to 49 bits (7
> septets = 49 bits = the next septet boundary).
>
> I do this by prefixing the message text with 7 "@" characters,
> and then overlaying the UDH on top. I use "@" because it's
> "0000000" binary in the 7-bit default alphabet, giving me all
> the binary zero padding I could possibly need.
>
> " @@@@@@@hellohellohel
lo......" encodes as:
>
> 000000000000D06536FB
8D2EB3D96F7499CD7EBB
5C2E97CB05
>
> Overwriting the first 6 octets with the real UDH gives
>
> 050003010301D06536FB
8D2EB3D96F7499CD7EBB
5C2E97CB05
>
> And that's our UD field, with the actual text displayed
> correctly by new and old phones alike.
>
> John- Hide quoted text -
>
> - Show quoted text -
Hi John,
The explanation is very clear.
Yes, the header I quoted in my earlier post was wrong.
Thanks a lot for your quick help John!!!
Regards-
Aakash
|
|
|
|
|