0

I try to read multipart sms in PDU mode. The message was in 3 parts

Below are PDUs I got by using command AT+CMGF=0 and AT+CMGL=4

Part1:07914150740250F7440B917130263521F600005140723295528AA005C01B5B0301B2E53C194D46A3C96834196D169BD16833DA8C368BCD62B3D82C368BCD62B3586C169BC566B1596C169BC562B3D82C368BCD62B3D82C368BCD62B3DBEC769BDD66B7D90D328B41663768DC0699DD66B7D96D769BDD66B7D96D76BBCD6EB3DBEC36BBCD6EB3DBEC36BBCD6EF7D96D769BDD67F7D96D769FDD67B7FBEC3EBBCFEEB3DB7D769FDD

Part2:07912160130320F8440B917130263521F600005140723295528AA005C01B5B0302CE6EB3DBEC56AB41D9729E8C26A3D164349A8C368BCD68B4196D469BC566B1596C169BC566B1592C368BCD62B3D82C368BCD62B1596C169BC566B1596C169BC566B1D96D76BBCD6EB3DBEC0699C520B31B346E83CC6EB3DBEC36BBCD6EB3DBEC36BBDD66B7D96D769BDD66B7D96D769BDD66B7FBEC36BBCDEEB3FBEC36BBCFEEB3DB7D769FDD

Part3:07914140540500F9440B917130263521F600005140723295528A1805C01B5B0303CEEEB3DB7D769FDD67B7D96D76ABD5

*According to my understanding, in order to identify if it's a multipart message I have to check if TP-UDHI is set where it's the sixth bit in first octet. In this case it's not set.

*The bold part of the PDU was the Data Header

*I thought in order to indicate this is a concatenate message it has to be 00 instead of C0?

Please correct me if I get it wrong..

Question 1: Why is the TP-UDHI not set in this case first octet was 07?

Question 2: Why the first octet in UDH is not 00 instead of C0?

Matt Aldridge
  • 2,037
  • 16
  • 21
June Leow
  • 102
  • 1
  • 16

1 Answers1

0

Ok answering question 1) You missed spotting that right at the start of the PDU there is the SMSC address. So in fact your PDU header octet is 44. This indicates that there is a UDH present in the PDU.

This is the SMSC address:

07914150740250F7

Directly thereafter is the PDU header 44.

Regarding question 2) things get a little more complicated. Right now I am not spotting that the UDH contains any indication of a concatenated SMS. Don't forget that the UDH is not just for concatenated messages. It can contain lots of other information based on the 3GPP ETSI spec 03.40.

After a closer look it looks like either the SMS was strangely encoded on the sending side or the mobile operator messed around with the UDH. You were correct isolating the UDH as:

C01B5B0302

Based upon the byte prior then the UDH length should be 5 bytes. But the first IEI (Information Element) is misleading. C0 defines the IEI as a SC specific IEI and not a concatenated IEI. Then the next by 1B says the IEI data should be 27 bytes long which contradicts the UDH length of 5.

So from my perspective something mangled the UDH (which can happen with mobile operators, sms aggregators, or even bad encoders).

If you would play around with what you have removing C01B and replacing with 0003 to ensure the 8-bit concat reference:

00035b0301
00035B0302
00035B0303

Then you would end up with a UDH telling you that the MR is 91 and the parts a correctly specified.

Matt Aldridge
  • 2,037
  • 16
  • 21
  • Thank you so much for your reply! The message was sent from my phone directly and read from my GSM modem. What could be the reason of this? The modem or my phone? Is the AT command I used to read message okay? – June Leow May 02 '15 at 17:28
  • Normally phones get the encoding right so it's either the mobile operators in-between or something with your modem (assuming my hand decoding is correct). Does the phone and modem have the same mobile operator? What modem are you using? – Matt Aldridge May 02 '15 at 17:32
  • No, my phone's operator was AT&T while the modem running T-Mobile SIM card. I'm using wavecom modem. – June Leow May 03 '15 at 00:45
  • I insert the SIM from modem to a phone and resend the message again. The message appears as a whole one in the phone nicely. Maybe this has something to do with the modem? Any AT command I have to issue before reading the inbox by any chance? – June Leow May 03 '15 at 00:53
  • I've dealt with Wavecom's before but not had this issue. Although I used unsolicited display of the PDU's via AT+CNMI=2,2,0,1,0. To get the PDU's you have to watch the terminal output of the modem though. Before executing that CNMI command make sure you grab your old settings by using AT+CNMI? Would recommend trying that out and seeing what happens when you receive the SMS's to rule out the Wavecomm storing the concat incorrectly in memory. – Matt Aldridge May 03 '15 at 10:03
  • Will try that out. Since you answer my original question, I marked your thread as answer. – June Leow May 04 '15 at 04:03
  • Random thought, both phone and modem are in GSM network right? There isn't any CDMA involved? – Matt Aldridge May 04 '15 at 15:12
  • Should be both in GSM. – June Leow May 05 '15 at 04:31
  • Try to send another message from another phone of my friends (probably T-Mobile). Do the reading from modem again, and this time the message appears as one big chunk of PDU instead of 3. No idea why previous message appears as three chunks. – June Leow May 05 '15 at 04:32
  • I have the impression either AT&T or T-Mobile are decoding and re-encoding your SMS differently in your initial Question. Trying to setup a test here to see if I can reproduce. – Matt Aldridge May 05 '15 at 05:31
  • Feel free to send me a mail (go onto my profile and click my website link). I can provide you some more direct support if you are up for that. – Matt Aldridge May 05 '15 at 06:23
  • Sorry for the late reply. I was busy with work. Gonna try other SIM and operator later on. Thanks for your offer, I will let you know once i got to test it out. – June Leow May 07 '15 at 02:51