How to with 7bit encoding in concatenated sms messages

Where

11- udl

05- udhl

00- IE

03- IEL

03- reference number

03 - total number of SMS

03 - 3/3 sms

Fill bits has to be added after header in order to get (7 bit)

septet boyndary says GSM spesification 03.40 before starting the actual 7 bit data. This is to avoid shifting. 8 seven bit characters can be put in 7 octets. There are phones which do not understand headers and they can still make sence of the message after the header too this way. So the first A2 is the last octet of the 7 octet

sequence and the coding should be according to that since the

user data header takes only 6 octets from the beginning of normal

user data.

A2D229B56ABD62B35A - UD

BR

M, Forum Nokia

 

Hello,

I am trying to send messages > 160chars in length via sms using 7bit encoding. For this, I made out that some fill bits are added and the 7bit encoded string is shift left a certain number of times.

Text: ABCDEFG

Original encoded string 41 e1 90 58 34 1e 01

If user data header is present they become 82 c2 21 b1 68 3c 02

UDH-050403160201(6octets)

 

Since there are 6 octets and it requires one more bit to form a septet, you are shifting each byte of original encoded string by 1. This is fine, but how do you make out what your LSB in each byte is? Sometimes it is 0, other times it is one. Can someone tell me what is the logic being followed here?

 

 

 

Field 1 (1 octet): Length of User Data Header, in this case 05.

Field 2 (1 octet): Information Element Identifier, equal to 00 (Concatenated short messages, 8-bit reference number)

Field 3 (1 octet): Length of the header, excluding the first two fields; equal to 03

Field 4 (1 octet): 00-FF, CSMS reference number, must be same for all the SMS parts in the CSMS

Field 5 (1 octet): 00-FF, total number of parts. The value shall remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole information element

Field 6 (1 octet): 00-FF, this part's number in the sequence. The value shall start at 1 and increment for every short message which makes up the concatenated short message. If the value is zero or greater than the value in Field 5 then the receiving entity shall ignore the whole information element. [ETSI Specification: GSM 03.40 Version 5.3.0: July 1996]

It is possible to use a 16 bit CSMS reference number in order to reduce the probability that two different concatenated messages are sent with identical reference numbers to a receiver. In this case, the User Data Header shall be:

 

Field 1 (1 octet): Length of User Data Header (UDL), in this case 6.

Field 2 (1 octet): Information Element Identifier, equal to 08 (Concatenated short messages, 16-bit reference number)

Field 3 (1 octet): Length of the header, excluding the first two fields; equal to 04

Field 4 (2 octets): 0000-FFFF, CSMS reference number, must be same for all the SMS parts in the CSMS

Field 5 (1 octet): 00-FF, total number of parts. The value shall remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole information element

Field 6 (1 octet): 00-FF, this part's number in the sequence. The value shall start at 1 and increment for every short message which makes up the concatenated short message. If the value is zero or greater than the value in Field 5 then the receiving entity shall ignore the whole information element. [ETSI Specification: GSM 03.40 Version 5.3.0: July 1996]

Example of the UDH for an sms split into two parts:

 

05 00 03 CC 02 01 [ message ]

05 00 03 CC 02 02 [ message ]

Note. if a UDH is present and the data encoding is the default 7-bit alphabet, the user data must be 7-bit word aligned after the UDH[2]. This means up to 6 bits of zeros need to be inserted at the start of the [message].

 

E.g. with a UDH containing a single part,

 

05 00 03 CC 01 01

the UDH is a total of (number of octets x bit size of octets) 6 x 8 = 48 bits long. Therefore a single bit of padding has to be prepended to the message. The UDH is therefore (bits for UDH / bits per septet) = (48 + 1)/7 = 7 septets in length.

 

With a message of "hello world", the [message] is encoded as

 

D0 65 36 FB 0D BA BF E5 6C 32

whereas without padding, the [message] would be

 

E8 32 9B FD 06 DD DF 72 36 19

and the UDL is 7 (header septets) + 11 (message septets) = 18 septets.