 |
 | 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 / May 2008Erorr In Compile PDU
Hi, When we trying to compile this PDU SMS 07910221020020F040048167383D1170113232848040140500033A0202EC6176BD0C4ACF4134170E06 We Got this Result: EC6176BD0C4ACF4134170E06 I think there r an errors in Header info. Thanks, Source Subject in http://groups.google.com.eg/group/alt.cellular.gsm/browse_thread/thread/3644c5ba 348b355/7800e21198ad40a3?hl=en& > When we trying to compile this PDU SMS 07910221020020F040048167383D1170113232848040140500033A0202EC6176BD0C4ACF4134170E06 > We Got this Result: > [quoted text clipped - 5 lines] > > Source Subject in http://groups.google.com.eg/group/alt.cellular.gsm/browse_thread/thread/3644c5ba 348b355/7800e21198ad40a3?hl=en& Your PDU looks good to me. It's part 2 of a 2-part concatenated message. It carries the 13-character text: value is 4.80 The brief decode is: 07910221020020F0 SMSC 40 PDU-type: RP no, UDHI yes, SR no, MMS yes, MT 04816738 originator 3D PID 11 DCS: 7-bit default alphabet, ME specific 70113232848040 SMSC timestamp 14 UDL: 20 characters (7 pseudo-characters + 13 actual) 0500033A0202 UDH EC6176BD0C4ACF4134170E06 UD without UDH: "value is 4.80" If your problem is decoding "EC6176BD0C4ACF4134170E06" to get "value is 4.80", that's likely because you're not allowing for the padding of the text to the next septet boundary following the UDH, and the necessary alignment of the text to the beginning of the entire UD field. Instead of trying to decode "EC6176BD0C4ACF4134170E06" while taking the existence of the UDH into consideration, it's much easier to decode the entire UD field, "0500033A0202EC6176BD0C4ACF4134170E06", and throw away the initial 7 pseudo-characters from the decode. That there are 7 pseudo-characters is given by the UDHI bit being turned on within the PDU-type octet, taken together with the UDH length of "05" (the first octet within the UD). One octet for UDH length + 5 octets for UDH gives a total of 6 octets already used within the UD. That's 48 bits, and the next septet boundary occurs at 49 bits (7 septets at 7 bits each). As the default alphabet uses one character per septet, thats 7 leading characters we throw away when decoding the entire UD field. Important references: GSM 03.38, sections 4, 6.1.2.1, 6.2.1 GSM 03.40, section 9.2.3.24 John Thanks very much But I'm trying to translate (EC6176BD0C4ACF4134170E06) by using 7bit but i failed. and got this result (lCYkKARgA\) may u please help me? > Thanks very much > > But I'm trying to translate (EC6176BD0C4ACF4134170E06) by > using 7bit but i failed. > and got this result (lCYkKARgA\) That's the correct decode, but only if "EC6176BD0C4ACF4134170E06" is the whole UD field. Earlier, we worked out that your UD field contained a UDH, and that the whole UD field is "0500033A0202EC6176BD0C4ACF4134170E06". As I tried to say in a previous post, you can decode this longer string as if it were all text, and throw away the first 7 characters. What remains will be the actual 13-character text you want. Doing this will _automatically_ align the decode to the correct boundaries. If you want to decode just the "EC6176BD0C4ACF4134170E06", then you need to allow for the fact that the first character in your decode is the eighth septet (character) of the whole UD field. And the first octet "EC" of the part which interests you here is the seventh octet of the UD. Numbering the octets in the whole UD for reference, and expanding them to binary, we get: 1 05 00000101 2 00 00000000 3 03 00000011 4 3A 00111010 5 02 00000010 6 02 00000010 7 EC 11101100 8 61 01100001 9 76 01110110 10 BD 10111101 11 0C 00001100 12 4A 01001010 13 CF 11001111 14 41 01000001 15 34 00110100 16 17 00010111 17 0E 00001110 18 06 00000110 We're now decoding from octet 7 ("EC") above, numbering the resulting characters from 1. I stress again that the decode aligns to the start of the whole UD field, not the start of the part after the UDH. I'm numbering the bits in each octet from 1 on the right to 8 on the left. char # from octet, bits bit pattern value 1 7, 2-8 1110110 v 2 8, 1-7 1100001 a 3 9, 1-6 & 8, 8 110110 0 l 4 10, 1-5 & 9, 7-8 11101 01 u 5 11, 1-4 & 10, 6-8 1100 101 e 6 12, 1-3 & 11, 5-8 010 0000 <space> 7 13, 1-2 & 12, 4-8 11 01001 i 8 14, 1 & 13, 3-8 1 110011 s 9 14, 2-8 0100000 <space> 10 15, 1-7 0110100 4 11 16, 1-6 & 15, 8 010111 0 . 12 17, 1-5 & 16, 7-8 01110 00 8 13 18, 1-4 & 17, 6-8 0110 000 0 I hope you can understand my English when you've got the worked result to look at. John Thanks very much; I want ask u about Decoding: why it = 11 (xxxxxxx3D "11"xxxxxxx) not : 00 7bit //04 8bit //08 16 And how I can know if PDU data contains pseudo-characters ?? sorry for frequent questions.. > I want ask u about Decoding: > > why it = 11 (xxxxxxx3D "11"xxxxxxx) > not : 00 7bit //04 8bit //08 16 That "11" is the DCS (data coding scheme) octet. In binary, it's "00010001". Working through those bits from left to right: 00 data coding: general 0 SMS is not compressed 1 the right most 2 bits indicate the message class 00 message is encoded using 7-bit default alphabet 01 message class 1, ME specific The message class indicates the intended "destination" of the SMS once received. The two bits gives us 4 possible classes, from class 0 to class 3, as follows: class 0: if possible, display the message immediately on the screen, and don't store it anywhere. class 1: ME (handset/modem/device) specific. Store the message in the phone memory if possible. class 2: SIM specific. Store the message on the SIM if possible. class 3: TE (terminal equipment) specific. If possible, pass the message directly to another piece of equipment that is connected to the phone. This will be connected via a serial cable (RS232 or USB), IrDA, or Bluetooth. GSM 03.38 has this to say about class 1: "When a mobile terminated message is Class 1, the MS shall send an acknowledgement to the SC when the message has successfully reached the MS and can be stored. The MS shall normally store the message in the ME by default, if that is possible, but otherwise the message may be stored elsewhere, e.g. in the SIM. The user may be able to override the default meaning and select their own routing." As to why the sender used DCS = "11" instead of "00", I can't answer that. Effectively, there'd be no difference in the result. > And how I can know if PDU data contains pseudo-characters ?? They'll be there every time the UD contains a UDH. And that information is given to you by the UDHI (user data header indicator) bit being turned on within the PDU-type octet. The standards sometimes refer to the PDU-type octet as the "first octet" (or just "<fo>"), because it's the first octet after the SCA (service centre address). UDHI is the second bit from the left in the PDU-type octet. In your PDU, the PDU-type octet was "40" hex, or "01000000" binary. So UDHI = 1, and therefore the UD contains a UDH. The length of the UDH is given by UDHL (user data header length). This is the first octet in the UD. In your case, it is "05" (hex). This means that the UD contains 5 octets of UDH, plus the 1 octet for the UDHL itself. That's 6 octets of UD taken by UDH. But the text doesn't start immediately after the UDH, because the text must be padded to a septet boundary. Given 48 bits (6 octets) of UDH, the next septet boundary is at bit 49 (7 * 7). And bit 49 of the UD is where my decode started, although it was aligned all the way back to the UDHL. > sorry for frequent questions.. That's OK. They were questions for me once too :) John Thanks Jone very much And I want ask u about: Do u have any PHP script to read PDU ?? > Thanks Jone very much > > And I want ask u about: > > Do u have any PHP script to read PDU ?? No, sorry. John Thanks vey much Is: " That "11" is the DCS (data coding scheme) octet. In binary, it's "00010001". Working through those bits from left to right: " That is: DCS (data coding scheme) octet ,, Or Hex?? 11 in Octel = 1001 11 in Hex = 10001 ?? thanks again > Thanks vey much > Is: [quoted text clipped - 9 lines] > > ?? It's an octet, so it's 8 bits. In most other contexts an octet is called a "byte". Octets are always represented in hexadecimal. So your DCS value is "11" hex. Each digit in this hex representation is 4 bits. So each hex "1" is "0001" binary, making your DCS "00010001" binary. Of course that's "10001" binary if you suppress the leading zeros, but I find it less confusing to see them when doing decodes. John Many Thanks jon, I have anther querstion about: How I can decode Sender ID if it like following (it's not hex but it 7bit How I can know that): 07911989414057500414D032584C4683DD7239580C00087011914060240060062706440633064406270645002006390644064A06430645002006480 thank again > How I can decode Sender ID if it like following (it's not hex > but it 7bit How I can know that): It's encoded in exactly the same way as 7-bit text in a User Data field. In other words, using the packing algorithm from GSM 03.38, section 6.1.2.1.1. The unpacked septets (7-bit characters) then get looked up in the table from GSM 03.38, section 6.2.1. The Originator Address field from your message is 14D032584C4683DD7239580C. It decodes like this: 14 OA length: 14 hex (20 decimal) semi-octets D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5) 32584C4683DD7239580C OA string "20124079901", as follows: Numbering the octets of 7-bit data from 1 to 10 gives us this binary data: 1 32 00110010 2 58 01011000 3 4C 01001100 4 46 01000110 5 83 10000011 6 DD 11011101 7 72 01110010 8 39 00111001 9 58 01011000 10 0C 00001100 The decode goes like this: Numbering the bits in a octet from 1 on the right to 8 on the left, the first septet consists of octet 1, bits 1 to 7: 0110010, = "2" (from lookup in GSM 03.38, 6.2.1). The second septet contains octet 2, bits 1 to 6 and octet 1, bit 8: 0110000, "0". Putting the whole 10 octets (encoding 11 septets) into columns we get: septet from octet, bits bit pattern value 1 1, 1-7 0110010 2 2 2, 1-6 & 1, 8 011000 0 0 3 3, 1-5 & 2, 7-8 01100 01 1 4 4, 1-4 & 3, 6-8 0110 010 2 5 5, 1-3 & 4, 5-8 011 0100 4 6 6, 1-2 & 5, 4-8 01 10000 0 7 7, 1 & 6, 3-8 0 110111 7 8 7, 2-8 0111001 9 9 8, 1-7 0111001 9 10 9, 1-6 & 8, 8 011000 0 0 11 10, 1-5 & 9, 7-8 01100 01 1 John Hi John, I have 3 different problem 1. I can not get 'normal text' for this message : 06912618010000640B912618819088F200F5702110805300826C06050423F40000424547494E3A56434152440D0A56455253494F4E3A322E310D0A5245563A3230303731313235543033353935325A0D0A4E3A3B4172656B2D5374616E6C65793B3B3B0D0A54454C3B43454C4C3A30383838313135353333330D0A454E443A56434152440D0A another sample message : 07912618485400F9440B912618274067F100F5601002021061828406050423F40000424547494E3A56434152440D0A56455253494F4E3A322E310D0A4E3A48656E64726F3B0D0A54454C3B43454C4C3A2B363539333637333132310D0A4F52473A36332048756D6520417665202330322D30312048696C6C7669657720477265656E20436F6E646F202862697320393633290D0A454E443A56434152440D0A Can you explain me, how to get the 'normal text' for that PDU 2. I need to get text for Originator Address. The Originator Address must be TELKOMSEL. How to get that Originator Address text and do you have any link about the documentation for this. Message : 07912618018758F30410D0D42273F96C4E8B4C00008040422191328297D0323BEC3E9FC36E50968E6629EBED301D24ABBD60B4170C070ABAC96150BBEC26C3E9EBB01B749687E9E93908076ABBE920717A1C968741F3F23CDC0E83A865F6FADD9E97D92E10B42C47A7E975F739EC0685C96110390D0AAFD1693948CC7683E8E1731A1D76834C207A593E2ED3C36B109C0C92A7DDE374D80D8297E5E3F03A0C0FBB01 3. When I try to get total parts of message using your explanation, it gets 53. Actually, In my mobile phone only about 3 or 4 concatenated message. How to get the right total parts of message ? The message : 06912618010000600C91261892931174000040306102947400A006080400350201CCB7BD0C4ACF41F0303D5D76D341613719949E83D66937990562BFED65507A0E72BFE9207539CC7ED7E7A0B71C247E87E774739DBD03A5E9A0F41CE47ED34161B9FC7D0EBBE9A0B71C24AF93CB2E970BC47CDBCB2071392C9F83C26C36888E4EBBCF7316485C66A7CBF6F21C1466B3417474DA7D9EB340E837BC0C0AB3D9203A3AED3ECF59 Thank you, Best regards, Martha > Hi John, > > I have 3 different problem > 1. I can not get 'normal text' for this message : I'll handle your two messages in your part 1 query seperately. I seriously doubt that these two messages are meant to be human-readable. They're 8-bit data, specifically addressed to a particular "machine" port on the destination handset. Nevertheless, I have begun the decoding process for the first message as follows: 06912618010000 SCA 64 PDU-type (hex) 01100100 PDU-type (binary) as follows: 0 reply path (not set) 1 UDHI (UDHI is set - UD has a UDH) 1 SRI (set - delivery acknowlegment requested) 00 spare 1 MMS (no more messages waiting delivery) 00 MTI (SMS type "MT" = SMS deliver = a "received" message) 0B912618819088F2 OA (originator address) 00 PID F5 DCS (hex) 11110101 DCS (binary) as follows: 1111 data coding/message class 0 spare bit (must be zero) 1 message data is 8-bit 01 ME-specific (for phone, not SIM) 70211080530082 SCTS (1 Dec 07, 08:35:00, GMT + 7 hours) 6C UDL, 6C hex = 108 decimal 06 UDHL, the next 6 octets are UDH (header) 05 application port addressing, 16-bit address 04 information element length (4 octets follow) 23F4 destination port, 9204 decimal - GSM 03.40 says: "As allocated by IANA (http://www.IANA.com/)" 0000 originator port 42 B (these are all just 8-bit ASCII values) 45 E 47 G 49 I 4E N 3A : 56 8 43 C 41 A 52 R 44 D 0D <carriage return> 0A <line feed> 56 8 45 E 52 R 53 S 49 I 4F O 4E N 3A : 32 2 2E . 31 1 I'll leave the rest of these two messages to you to decode. John I wrote: > 42 B > 45 E [quoted text clipped - 20 lines] > 2E . > 31 1 The two char 56 hex above, which I decoded as "8", should decode to "V". According to http://mobile.act.cmis.csiro.au/comp3410/assignment.asp this "port 23F4" message is an address book update. The URL has much good detail on this type of SMS. John Hi john Thanks very much I'll try and if any prob. I'll back thanks OK john, But is it like D0 always in alphanumeric sender id ? in (D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5) ) > OK john, > > But is it like D0 always in alphanumeric sender id ? > > in (D0 OA encoding: alphanumeric (GSM 03.40, 9.1.2.5) ) Yes, type-of-address "D0" is always alphanumeric, always using the 7-bit default alphabet, and always encoded in exactly the same way as a 7-bit message text. The other two common type-of-address (hex) values are: 91 international format. Always begins with the country code. In other words, you understand that the number begins with "+". 81 national format. No country code is present - just a number within a country. John That is good. Thanks Very Much John .. > 2. I need to get text for Originator Address. The Originator > Address must be TELKOMSEL. How to get that Originator Address > text and do you have any link about the documentation for > this. Message : OK, the OA (originator address) element for this next message is: 10D0D42273F96C4E8B4C 10 OA is 10 hex (16 decimal) semi-octets long D0 type of address (hex) 11010000 type of address (binary) as follows: 1 reserved (must be "1") 101 alphanumeric (7-bit default alphabet) 0000 must be "0000" when leading bits are "1101" "D42273F96C4E8B4C" carries the encoded OA, which does indeed decode to "TELKOMSEL". The decoding of the OA element is covered in GSM 03.40, section 9.1.2.5. This is where the OA length and type-of-address are covered in detail. Because type-of-address is alphanumeric in this case (type = "D0"), you must decode it according to GSM 03.38 section 6.1.2.1.1 "Packing of 7-bit characters", and section 6.2.1 (default alphabet lookup table). You can download these GSM technical standards from www.etsi.org or www.3gpp.org and other sources you can find using google. "D42273F96C4E8B4C" decodes to "TELKOMSEL" using exactly the same mechanical procedure as "32584C4683DD7239580C" decodes to "20124079901" in the example I worked for alfarok in a recent post. In this case, I decoded it using a program. > 3. When I try to get total parts of message using your > explanation, it gets 53. Actually, In my mobile phone only > about 3 or 4 concatenated message. How to get the right total > parts of message ? The message : In the next message, the UDHI bit is set within the PDU-type octet (as is correct for a concatenated message). There's nothing special about the PID or the UDH (both are "00"). So I'll go straight to the UDH field, beginning with the UDL: A0 UDL: A0 hex = 160 decimal septets 06 UDHL, the next 6 octets are UDH (header) 08 concatenated short message using 16-bit numbering 04 information element length (4 octets follow) 0035 16-bit message number, 35 hex (53 decimal) 02 message has 2 parts 01 this is part 1 For the detailed explanation, please see GSM 03.40, sections 9.2.3.24 and 9.2.3.24.8. John Hi John, Thank you for your comprehensive answer above. It helps me much. I have 1 next question 1. How to set PDU, so the receiver can receive the sender not as a phone number, but a string (like TELKOMSEL). I don't find any explanation about this issue in PDU Format for SMS-SUBMIT in 03.40 article. Thank you, Best regards, Martha > Hi John, > [quoted text clipped - 5 lines] > any explanation about this issue in PDU Format for SMS-SUBMIT > in 03.40 article. You cannot set the originator address of messages submitted "over the air". The originator address is always set by the SMSC with which the SMS is lodged, and to the best of my knowledge is always set to the actual sender's number. To have any chance of controlling the content of the originator address field, you must establish a relationship with a commercial message centre direct lodgement bureau service, and submit messages using a protocol such as SMPP over TCP/IP. I referred someone in another thread to http://en.wikipedia.org/wiki/Short_message_peer-to-peer_protocol and that article should give you some useful terms for a search engine. John |
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.