Talk:Concatenated SMS

I would love to know more technical information about Concatenated SMSes, like how they are constructed. --Devnevyn (talk) 14:59, 2 April 2008 (UTC)[reply]

Filled in what I read on http://www.activexperts.com/activsms/sms/multipart/ on the topic. I'm really no expert, so if someone could confirm or write about other methods, that'd be great. For example, [1] says that the UDH should begin with a five-bit header length field, although that doesn't make much sense since there is already a UDH header length field in byte #01--Devnevyn (talk) 15:29, 2 April 2008 (UTC)[reply]

I don't think this really needs its own article. We already have an article on Short message service technical realisation (GSM), so this should be merged there, which would also allow covering eg. the other functions of the UDH. Jpatokal (talk) 18:36, 2 April 2008 (UTC)[reply]

153?

While the figure 153 appears to be accurate, the explaination of why you're limited to 153 appears to be incomplete. If you use 5 bytes for the header leaving you 135 bytes you can in theory send 154 7 bit characters (135*8=1080 bits; 1080/7=154.28571428571428571428571428571 characters). My guess is that you need an extra byte perhaps to to 'convert' to 7 bit text mode or something Nil Einne (talk) 13:43, 31 May 2008 (UTC)[reply]

The header is 6 bytes long (6 fields of one octet), not 5, leaving you with 134 bytes or 153 7 bit characters. --Martvefun (talk) 19:44, 25 October 2012 (UTC)[reply]

The reason for 153

Nil Einne said: 153? While the figure 153 appears to be accurate, the explaination of why you're limited to 153 appears to be incomplete. If you use 5 bytes for the header leaving you 135 bytes you can in theory send 154 7 bit characters (135*8=1080 bits; 1080/7=154.28571428571428571428571428571 characters). My guess is that you need an extra byte perhaps to to 'convert' to 7 bit text mode or something Nil Einne (talk) 13:43, 31 May 2008 (UTC)

About the problem of 153, I think the reason for why you are limited to 153 is: there is one octet in TP-User Data Header which indicates user data header length, so actually you use 6 bytes for the whole header, now it is leaving you only 134 bytes for the user data. Therefore, only 134*8/7=153.1 characters can be used for per PDU of concatenated SMS. Any suggestion is welcome!

The article states that the CSMS reference number may be 8 or 16 bits (1 or 2 octets) long, therefore the header may be 5 or 6 octets long. If the header is 6 octets long, that leaves 134 octets for the message's content. 134 octets * 8 bits per octet = 1072 bits. 1072 bits / 7 bits per character = 153 characters. Hence, 153 characters per part of the message.

Perhaps the article misleads by labelling the fields "Byte 00" to "Byte 04" when in fact "Byte 02" is usually more than one byte; a 16-bit CSMS reference number. (It would help if I knew the facts!) SkiSkywalker (talk) 04:25, 15 June 2009 (UTC)[reply]

SkiSkywalker is correct. The maximum length of text is 153 7-bit characters. For an authorative reference see 3GPP 23.040 section 9.2.3.24.1. Willem Dekker (talk) 8:42, 29 June 2009 (UTC)

Thanks for the clarification. BTW, the 154 figure didn't come from me [2] since as I mentioned in my comment, I know from experience the 153 figure is correct even if the lack of the UDH at the time meant 154 made more sense Nil Einne (talk) 21:06, 16 February 2010 (UTC)[reply]

PDU vs Text Mode CSMS

It is possible to send CSMS via text mode:

at+cmgf=1^M0
at+csmp=113,167,0,8^M0
atv1^M
OK
at+cmgs="+375298077782"^M
> 05000307020200200057006F0072006C00640021^Z^M
+CMGS: 13

OK
at+cmgs="+375298077782"^M
> 05000307020100480065006C006C006F002C^Z^M
OK

In +csmp command: 113 = 0b0111 0001 bit #6 in octet is the UDH Information in the text mode setup command first byte. 8 = UCS2 charset (this works for me)

In +cmgs: 00200057006F0072006C00640021 = ' World!'

00480065006C006C006F002C = 'Hello,'

UDH is as described above, where 07 is message ID, 02 is length, finally 02 and 01 are seq. numbers.

While the first part was sent last, whole message looks like so:

Number: +375293774507 Message: Hello, World! Time: 08.08.2012 13:53:11

Test was done by GSM hardware:

ati^M
Cinterion
BG2-W
REVISION 01.002

padding?

Padding usually means adding bits. But you can't add bit(s) to "E8329BFD06DDDF723619" to get "D06536FB0DBABFE56C32"
E8329BFD06DDDF723619 = 11101000001100101001101111111101000001101101110111011111011100100011011000011001
D06536FB0DBABFE56C32 = 11010000011001010011011011111011000011011011101010111111111001010110110000110010
(in bold, indicated faults still occuring with removal of a bit instead of adding one (and in which case... where did the that bit go?)) What's the padding algorithm used? Qube0 (talk) 09:55, 31 January 2013 (UTC)[reply]

OK, I think I figured it out: when converting to from ascii-7 to packed-8, you start by putting 1 bit (a zero) in the least significant bit of the first byte. bitwise (writing a character as 7 bits "n6 n5 n4 n3 n2 n1 n0"), you normally get

"b0 a6 a5 a4 a3 a2 a1 a0" "c1 c0 b6 b5 b4 b3 b2 b1" "d2 d1 d0 c6 c5 c4 c3 c2" ...

while with 1 bit padding (lets call it X) you get

"a6 a5 a4 a3 a2 a1 a0 X" "c0 b6 b5 b4 b3 b2 b1 b0" "d1 d0 c6 c5 c4 c3 c2 c1" ... Qube0 (talk) 10:54, 31 January 2013 (UTC)[reply]

GSM extended table

Another thing to consider is that concatenated messages cannot be split between an escape (0x1b) and extension table character, eg a ] character at position 153 (or 154 depending). — Preceding unsigned comment added by 41.161.9.27 (talk) 08:06, 13 July 2015 (UTC)[reply]

Reassembly problems.

There's a known bug with some implementations of concatenated SMS.[3] The multiple parts of a concatenated SMS message can arrive in any order, and one or more parts may not arrive at all. So message reassembly has to keep unmatched message parts until all the parts show up.

The problem is that messages have a CSMS number that's only 8 bits, and thus is reused. Message parts are matched by sending phone number and CSMS number. If there are unmatched message parts in storage, an incoming message with the same sending phone number and CSMS number may be incorrectly reassembled, using a piece of an old message. Un-assembled message parts ought to be retained only for some limited length of time, but for some phone implementations, they're retained for the life of the phone's storage. So a message part from months ago can be misused.

Even worse, once the new message has been mis-reassembled, when the correct message part arrives later, it's stored for later use. So once this problem has happened to a phone, it persists.

Now to find a WP:RS source for this. John Nagle (talk) 04:37, 26 November 2015 (UTC)[reply]

John Nagle - Well, the app store pages for the apps that offer solutions are RS in this context. Your link mentions or links to a few. Addressed. --Elvey^(t•c) 21:40, 26 July 2016 (UTC)[reply]

Not widely used due to incompatibilities and network support

I added a fact claim to this [4] as I find it questionable. Maybe this is true in the US or something (where SMS were never as popular as in lots of Asia etc), but I can say in both Malaysia and NZ most phones and networks seemed to have no problem. Heck even sending messages between the 2 since 2002 or so. Definitely I never heard of anyone avoiding concatenated SMS because receive phone or network might not support. Of course messages can be lost just as they are. The claim made later "In the late 2000s to early 2010s, this feature was adopted more widely" is probably true but not for the earlier reason. I suspect the bigger factor was the rise in smart phones meaning sending longer messages (including less SMS speak) and reading them is easier so people used them more. (Not that typing was that slow with predictive typing but still some people are better than others.) But even before that, I'm fairly sure many people sent them on occasion since it generally worked, most people just send them without thinking. Heck with a number of phones, it wasn't even that clear if it was concatenated. I tended to be a bit OC about maximising SMS space, at least when I was paying per SMS so I knew about these sort of things. (Of course keyboard phones were popular in some areas before the iPhone craze but people using them often sent messages in other forms. Nowadays with the rise of other messages services on smart phones that's true in many areas too but I guess there was a short time in between.) P.S. It may be in the late 90s or earlier, support was poor. I don't know enough to comment. The trouble is the way our article is worded, it'll lead people to believe concatenated was very rarely used due to be poorly supported before the late 2000s and early 2010s which IMO is definitely not the case from a worldwide view. Nil Einne (talk) 05:38, 7 August 2016 (UTC)[reply]

Pre-smartphone devices in the US often did not reassemble multipart SMS messages. Twilio only added reassembly support in the last year. (I was beating on them for years to fix that.) John Nagle (talk) 06:33, 7 August 2016 (UTC)[reply]

Most != all.

If you're thinking that Concatenated SMS works fine on all modern smartphones, you're mistaken. I'm in the US, and I find sending SMS from a recent iPhone to a recent Android (From AT&T to Verizon, the two largest platforms and carriers) results in long messages arriving in short pieces.--Elvey^(t•c) 11:01, 12 August 2016 (UTC)[reply]

PDU Mode SMS

PDU mode and Concatenated SMS have nothing to do with each other. You can send a non-concatenated SMS to a mobile terminal in PDU mode, and you can send a concatenated SMS to some terminals in text mode. This section of the article should probably just be removed. 2A01:4B00:8810:A700:6D41:9E3B:E80C:54D0 (talk) 14:53, 27 April 2019 (UTC)[reply]