Multi-Part SMS in Text Mode

10 thoughts on “Multi-Part SMS in Text Mode

  1. Hi there,

    I know the official way to handle multi-part SMS is to work in PDU mode, but I wanted to ask if there is a secure way to get it working in text mode too?

    Sending long SMS in text mode works quite well, the modem seems to automatically split and encode the parts.

    But receiving is a bit more problematic. So if I send myself a long SMS (e.g. 200 characters) in text mode (UCS2 encoded), I receive two SMS. These two SMS contain a header and the sent text in GSM 7bit encoding.

    My Question now is, how is this header defined, and how it can be reliably recognized?

    I have here two examples of headers of two-part SMS received in different environments.

    05 00 03 AB 02 01
    05 00 03 AB 02 02

    06 08 04 0D 38 02 01
    06 08 04 0D 38 02 02

    The first field obviously defines the length of the header, the last two fields define the part count and current part index. And the two fields (or only maybe one) before the last two seem to have an increasing number for each received SMS.

    But what is the meaning of the second and (optional third) field, can there be additional fields?

     

    Is this header documented somewhere?

     

    And is there a secure method ,when in text mode, to distinguish if an incoming SMS is a single part UCS2 encoded text, or a multi-part GSM 7-Bit encoded message, besides guessing that it seems to look like a multi-part header?

     

    Thank you very much,
    Friedrich


    1. Hi,
      when
      an SMS has an header (not only if its a concatenated message) even if
      text mode is selected the module shows the message PDU (as specified in
      3GPP TS 27.005) .
       
      So in the first case:
      05 00 03 AB 02 01
       
      "05" indicates the header length
      "00" means that it’s a concatenated message with 8-bit message reference number
      "03" is the length of the Information element that follows
      "AB"
      is the message reference number of the concatenated message (1 octet so
      it’s a modulo 256 counter indicating the reference number)
      "02" Maximum number of short messages in the concatenated message
      "01" Sequence number of the current short message.
       
      In the second case:
      06 08 04 0D 38 02 01
       

      "06" indicates the header length
      "08" means that it’s a concatenated message with 16-bit message reference number
      "04" is the length of the Information element that follows
      "0D"
      "38" is the message reference number of the concatenated message (2
      octets so it’s a modulo 65536 counter indicating the reference number)
      "02" Maximum number of short messages in the concatenated message
      "01" Sequence number of the current short message.
       

      You can find all the things I explained in the 3GPP TS 23.040.

       
      In
      text mode to know if a message is part of a concatenated message or not
      you can first set command AT+CSDH=1 then when you read the message
      (with AT+CMGR command ) there are additional SMS parameters.
      Parameter
      <fo> can tell you if the message has an header: for example if
      its value is 4 it means that there is no header, if its value is 68 then
      the message has an header. You can also use parameter <dcs> to
      know which is the SMS coding (UCS2 or 7-bit default).
      For more details you can refer to "Telit_AT_Commands_Reference_Guide.pdf"
       
      If you have any other question you can ask me.

      1. Thank you very much,

        when setting AT+CSDH=1

        I get the fo values.

        But when sending myself an SMS which arrives in four parts, the first two parts and the last one had fo=68, but the third one had fo=64, is this usual?

        I still have two SMS related questions:

        1.) I just tried to send myself in text mode an SMS with cyrillic characters (UTF8 encoded to UCS2), but I receive a repetetive string of mostly accented e. Is there something I have to consider when sending SMS with certain characters sets?

        Example:
        Sending
        UTF8: ?????? ??????????
        UCS2: 0420043E04410441043804380020044204350445043D043E043B043E043304380438

        Receiving:

        UCS2: 00E900E900E900E900E900E9002100E900E900E900E900E900E900E900E900E900E9
        UTF8: éééééé!éééééééééé

        2.) Is it possible to send a class 0 SMS when in Text Mode? In the reference guide I only found references to SMS classes for the CNMI and CPMS commands?

        Thank you very much for your help.

      2. Thank you very much,

        when setting AT+CSDH=1

        I get the fo values.

        But when sending myself an SMS which arrives in four parts, the first two parts and the last one had fo=68, but the third one had fo=64, is this usual?

        I still have two SMS related questions:

        1.) I just tried to send myself in text mode an SMS with cyrillic characters (UTF8 encoded to UCS2), but I receive a repetetive string of mostly accented e. Is there something I have to consider when sending SMS with certain characters sets?

        Example:
        Sending
        UTF8: ?????? ??????????
        UCS2: 0420043E04410441043804380020044204350445043D043E043B043E043304380438

        Receiving:
        UCS2: 00E900E900E900E900E900E9002100E900E900E900E900E900E900E900E900E900E9
        UTF8: éééééé!éééééééééé

        2.) Is it possible to send a class 0 SMS when in Text Mode? In the reference guide I only found references to SMS classes for the CNMI and CPMS commands?

        Thank you very much for your help.

        1. I already found the solution for 1).

          I had to use

           

          AT+CSMP=17,167,0,8

           

          to set the data coding scheme.

          I’m not yet sure if I have to use the same dcs field for setting the SMS class type.

          1. Hi,
            regarding <fo> it’s correct that this parameter has different values: if bit2 is 0 indicates that there are more messages in the Service Center  to be sent to module. When bit2 is 1 then no more messages are waiting in the SC.
             
            1) To send cyrillic characters in text mode you need to set <dcs>="UCS2" of SMS. In this case even if the text mode is set you have to enter characters in exadecimal mode.
            Example:
            at+csmp?
            +CSMP: 17,167,0,0
            OK
            at+csmp=17,167,0,26
            OK
            at+cmgf=1
            OK
            at+cmgs="+39329xxxxxxx"
            > 0420043E04410441043804380020044204350445043D043E043B043E043304380438
            +CMGS: 29
            OK
            at+cmgl="ALL"
            +CMGL: 1,"REC READ","+39329xxxxxxx","Roby","14/03/18,09:48:50+04"
            SMS test with app
            +CMGL: 2,"REC READ","+39329xxxxxxx","Roby","14/03/18,14:34:59+04"
            SMS test with app
            +CMGL: 3,"REC READ","+39329xxxxxxx","Roby","14/03/21,11:23:08+04"
            06080400010201E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E
            87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E17038
            1C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C0E87C3E1
            70381C0E87C3E170381C0E87C3E170381C0E87C3
            +CMGL: 4,"REC READ","+39329xxxxxxx","Roby","14/03/21,11:23:09+04"
            06080400010202E170381C0E87C3E170381C0E87C3E170381C0E87C3E170381C06
            +CMGL: 5,"REC READ","+39329xxxxxxx","Roby","14/03/25,09:17:45+04"
            0420043E04410441043804380020044204350445043D043E043B043E043304380438
            +CMGL: 6,"REC UNREAD","+39329xxxxxxx","Roby","14/03/25,09:20:05+04"
            0420043E04410441043804380020044204350445043D043E043B043E043304380438
            OK
            Since every character has 2 bytes the maximum number of characters of the SMS is 70 instead of 160.
             
            2) It’s possible to send Class 0 message in text mode. You have to set the last parameter of command AT+CSMP as follows:
             
            Class 0 GSM default: at+csmp=17,167,0,16
            Class 0 UCS2 : at+csmp=17,167,0,24
             
            You can find other details on AT+CSMP command description.
             
            I hope this answer your questions. Let me know if it worked.

          2. Hi there,

            I still have a question regarding (multi-part) SMS in text mode:

            SMS behaviour is configured:
            AT+CMGF=1
            AT+CSMP=17,167,0,8
            AT+CSDH=1
            AT+CSCS=UCS2

             

            When I now receive a multipart sms in UCS2 format, everything seems to be okay.
            But when I receive a message with dcs=0 (default alphabet) there is still something I don’t understand.

            Here is the start of the first part of a multi-part SMS:
            I’m receiving a long string of testtesttesttest …

            050003630201 E8E5399D5E9ED3E9E5399D5E9ED3E9E5399D5E9ED3E9E53
            dcs=0
            fo=68

            If I do the 7bit decoding on E8E5399D5E9ED3E9E5399D5E9ED3E9E5399D5E9ED3E9E53 I’m getting garbage. If I start at the second byte E5, it decodes correctly (with the exception of the first character, which I can transcode correctly if I shift the first byte 0xE8 one bit to the right and get 0x74 which is the character t). This behaviour is the same for all message parts. Is this always the case when receiving multipart SMS with default alphabet, and is this documented somewhere?

            And when I’m receiving a single part SMS which was sent using default alphabet, I get dcs=0,fo=4 in the CMGR response, but the message is always encoded in UCS2 (testtest = 00740065007300740074006500730074), does the modem convert it automatically without changing the dcs or is it some feature of the message center? How can I be sure which data coding scheme it is in?

             

            Thank you very much,
            Friedrich

          3. Hi,
            if
            the concatenated message is 7-bit data is used and the header does not
            finish on a septet boundary then fill bits are inserted after the last
            Information Element Data. This is your case, that’s why the first
            character is coded in a "diferent" way. You can refer to 3GPP TS 23.040
            and 3GPP TS 23.038 specifications.
             
            Concerning
            the single part SMS, from the SMS configuration you sent me I can see
            that you set AT+CSCS=UCS2 so every text string (not only SMS text) is
            shown into hexadecimal mode.
            In
            case of SMS dcs set to USC2 or 8-bit the texts is shown into
            hexadecimal mode anyway even if AT+CSCS setting is different form UCS2.
            The SMS coding scheme used is that reported in dcs, AT+CSCS sets only
            the representation mode of the "text string" parameters of the AT
            commands.

          4. Thanks,

            I think I understand now. The 7 bit alignment starts on the first byte of the header, not on the first byte of the actual message part.

             

            Best Regards,

            Friedrich