 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups General General TopicsGSMBluetoothProviders AlltelATT WirelessCingularFidoNextelSprint PCST-MobileVerizonManufacturers EricssonNokiaMotorolaCountry Specific Australian GroupUK GroupRelated Topics PocketPCPalmMore Topics ... |
Cellular Phone Forum / General / GSM / December 2007long SMS
how can I get long SMS "more thank 160 or 70 characters " as one SMS by using GSM modem ? > 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 > et...@hotmail.com wrote: > > how can I get long SMS "more thank 160 or 70 characters " as [quoted text clipped - 22 lines] > > 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 > actually I'm interested in receiving long SMS as I got long > binary SMS but I could not translate it , some time the 1st [quoted text clipped - 3 lines] > 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/Mobile%20and%20Wireless%20Documents/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 > et...@hotmail.com wrote: > > actually I'm interested in receiving long SMS as I got long [quoted text clipped - 15 lines] > > John thank u john i can send u the SMSs i got if u want? > 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 > et...@hotmail.com wrote: > > thank u john [quoted text clipped - 5 lines] > > John ok John here it is the messages i got +CMGR: 1,,121 07910221020020F040048167383D19701110003332406A0500033E030306310635064A062F064300 2006270644062C062F064A062F002006470648002000330036002E003700390020062C0646064A06 2900200648002006270644063506440627062D064A0629002006470649002000310036002F003100 31002F00300037002E +CMGR: 1,,153 07910221020020F040048167383D19701110003342408A0500033E0301003200300032003A002006 440642062F00200646062C062D062A002006270644062D0631064306290020063106420645002000 43003000370031003100300031002E0030003000330035002E003000300030003300200644062A06 2D0648064A0644002000350020062C0646064A062900200645064600200627064406310642064500 20 +CMGR: 1,,149 07910221020020F044048167383D1970111000335240860500033E03020030003100320034003000 370039003900300031002E00200642064A064506290020062A062D0648064A064406430020064706 4900200034002E003800300020062C0646064A0629060C0020063106330645002006270644062A06 2D0648064A064400200647064800200030002E003200300020062C0646064A0629002E0020 > ok John here it is the messages i got > > +CMGR: 1,,121 07910221020020F040048167383D19701110003332406A0500033E030306310635064A062F0643002006270644062C062F064A062F002006470648002000330036002E003700390020062C0646064A062900200648002006270644063506440627062D064A0629002006470649002000310036002F00310031002F00300037002E 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 07910221020020F040048167383D19701110003342408A0500033E0301003200300032003A002006440642062F00200646062C062D062A002006270644062D063106430629002006310642064500200043003000370031003100300031002E0030003000330035002E003000300030003300200644062A062D0648064A0644002000350020062C0646064A06290020064506460020062706440631064206450020 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 07910221020020F044048167383D1970111000335240860500033E03020030003100320034003000370039003900300031002E00200642064A064506290020062A062D0648064A0644064300200647064900200034002E003800300020062C0646064A0629060C0020063106330645002006270644062A062D0648064A064400200647064800200030002E003200300020062C0646064A0629002E0020 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 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 07910221020020F040048167383D19701110003332406A0500033E030306 310635064A062F0643002006270644062C062F064A062F00200647064800 2000330036002E003700390020062C0646064A0629002006480020062706 44063506440627062D064A0629002006470649002000310036002F003100 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 07910221020020F040048167383D19701110003342408A0500033E0301003 200300032003A002006440642062F00200646062C062D062A002006270644 062D063106430629002006310642064500200043003000370031003100300 031002E0030003000330035002E003000300030003300200644062A062D06 48064A0644002000350020062C0646064A062900200645064600200627064 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 07910221020020F044048167383D1970111000335240860500033E0302003 0003100320034003000370039003900300031002E00200642064A06450629 0020062A062D0648064A0644064300200647064900200034002E003800300 020062C0646064A0629060C0020063106330645002006270644062A062D06 48064A064400200647064800200030002E003200300020062C0646064A062 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 > This is a repost, as requested, but with the PDUs wrapped. > [quoted text clipped - 295 lines] > > 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 . > 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 > et...@hotmail.com wrote: > > thank u John very much for ur help . [quoted text clipped - 20 lines] > > 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 ? > 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 > et...@hotmail.com wrote: > > thank u John [quoted text clipped - 62 lines] > > 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 07917283010010F5040BC87238880900F10000993092516195800AE8329BFD4697D9EC37 Sender Id start from 0B between smsc and sender id 2 numbers This is the different SMS : 0891683108200805F01151048181160000FF16C8329BFD66B5F320B8BC4CA7E741F7B79C4D0E01 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 ??? > 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 07917283010010F5040BC87238880900F10000993092516195800AE8329BFD4697D9EC37 > Sender Id start from 0B > between smsc and sender id 2 numbers > > This is the different SMS : 0891683108200805F01151048181160000FF16C8329BFD66B5F320B8BC4CA7E741F7B79C4D0E01 > Sender Id start from 04 > between smsc and sender id 4 numbers why ? [quoted text clipped - 3 lines] > and the 2nd was sent > can u help ??? 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 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 > 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 07917283010010F5040BC87238880900F10000993092516195800AE8329BFD4697D9EC37 > Sender Id start from 0B > between smsc and sender id 2 numbers > > This is the different SMS : 0891683108200805F01151048181160000FF16C8329BFD66B5F320B8BC4CA7E741F7B79C4D0E01 > Sender Id start from 04 > between smsc and sender id 4 numbers why ? 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 > et...@hotmail.com wrote: > > hi John [quoted text clipped - 35 lines] > > 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 ? > 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: 07917283010010F5040BC87238880900F10000993092516195800AE8329B FD4697D9EC37 and the second: 0891683108200805F01151048181160000FF16C8329BFD66B5F320B8BC4C 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 > et...@hotmail.com wrote: > > I hope i didn't bothering u with my questions [quoted text clipped - 42 lines] > > 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 07911989414057500414D032584C4683DD7239580C0001701191300442000DD3303BDC7E8382ECF2FADD06 On Nov 19, 1:26 am, et...@hotmail.com wrote: > > et...@hotmail.com wrote: > > > I hope i didn't bothering u with my questions [quoted text clipped - 50 lines] > > - Show quoted text - When we tried to translate above pdu we got this result: س0;ـ~ƒ,ىٍْف > 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 07911989414057500414D032584C4683DD7239580C0001701191300442000DD3303BDC7E8382ECF2FADD06 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 D3303BDC7E8382ECF2FADD06 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 > et...@hotmail.com wrote: > > we got a very strange error in 7 bit conversion , as 3c hex [quoted text clipped - 123 lines] > > 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 > thank u John very much for ur patience and help , now I 'am > facing another problem regarding connecting long SMS parts all [quoted text clipped - 3 lines] > 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/Mobile%20and%20Wireless%20Documents/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 > et...@hotmail.com wrote: > > thank u John very much for ur patience and help , now I 'am [quoted text clipped - 65 lines] > > John thank u John > et...@hotmail.com wrote: > > thank u John very much for ur patience and help , now I 'am [quoted text clipped - 65 lines] > > 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 > The information you provided in your earlier posts helped me a > lot. However, I still have some question wrt long/concatenated [quoted text clipped - 12 lines] > > 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: E8329BFD4697D9EC37BACC66BF5D2E97CBE502 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. "@@@@@@@hellohellohello......" encodes as: 000000000000D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05 Overwriting the first 6 octets with the real UDH gives 050003010301D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05 And that's our UD field, with the actual text displayed correctly by new and old phones alike. John > aakash7...@yahoo.co.in wrote: > > The information you provided in your earlier posts helped me a [quoted text clipped - 85 lines] > > - 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 > et...@hotmail.com wrote: > > thank u john [quoted text clipped - 5 lines] > > John John I can't read ur last reply plz resend it |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.