Long received SMS being split and out of order

[Zachary Marchbank]

I'm not sure if this is specific to receiving messages from Verizon customers, but when I do text this one person from Verizon and they send a long message, it splits it up into multiple messages and they all show up out of order in the conversation view. I've tried the SMS Time Fix app, but I don't know if I'm using it correctly. Either way, it's not working. Is there a way to fix this or possibly change the character limit so I can receive in one big block of text? It makes conversations so hard to read when I had to figure out which message goes where. I'm running AOKP's latest 4.2 ROM. It does it on stock ICS and Jelly bean too. Any help would be much appreciated.

 

[repligation]

I have had this same experience with a friend who is a Verizon customer and sends "missiles" of text that always go over the 160 character limit for SMS and often go past 320. Once that happens the message becomes an MMS and they get delivered in the order in which they make it through the MMS queue rather than the order in which they were sent.

I think this has to do with the APN settings with cross carrier mms.

 

[Almeuit]

There isn't anything you can really do. This is due to the carriers.. ATT is GSM technology and it can handle huge text messages so that's why you can send a massive text to a friend on ATT and it all shows as one... Whereas a verizon or Sprint customer will "split" these texts as you mentioned. This is because CDMA technology (what Verizon and Sprint use) can only handle a 160 character text before it has to "break" it into multiples of 160 each.

When I send a long text on Sprint on my screen it looks normal.. But I know it splits it up. The only thing to help the order its received is for the person sending it (your friend) to have a third party messaging app that will split the messages before going to the carrier. For example you see below that I use ChompSMS and it has this feature.. So if I send bigger than 160 character text messages the app automatically splits it and send it one by one to the carrier.. That way the carrier then sends it one by one to the person and then they stay in order.

Sent from my Sprint S3 using AC forums

 

[repligation]

Good news for the future is that the cdma split will not occur on LTE which is based on the gsm standard . . . unless you are a Verizon iPhone 5 user, which has its LTE antenna integrated with the cdma antenna instead of separate antennas like on the gs3.

code division sucks, but Verizon is doing a decent job of LTE rollout.

 

[Alex Rod]

That's not true because when I had an iPhone that never happened at all. Mine get split up but not out of order on my nexus 6.

 

[Solandri]

There isn't anything you can really do. This is due to the carriers.. ATT is GSM technology and it can handle huge text messages so that's why you can send a massive text to a friend on ATT and it all shows as one... Whereas a verizon or Sprint customer will "split" these texts as you mentioned. This is because CDMA technology (what Verizon and Sprint use) can only handle a 160 character text before it has to "break" it into multiples of 160 each.

Old topic, but replying to this because this is the #1 search result on Google.

I don't think GSM or CDMA has anything to do with it. In this T-Mobile post here, you can see someone complaining about the same problem in texts from a T-Mobile phone to an AT&T phone. Both T-Mobile and AT&T are GSM networks, so the problem also happens in purely GSM to GSM text messages.
https://support.t-mobile.com/message/380255#380255

As best as I've been able to figure out, the problem is that SMS is limited to 140 bytes (160 characters for 7-bit ASCII text). This isn't a CDMA limitation - the GSM spec for SMS sets the message length at a maximum 140 bytes. So regardless of your carrier, if you try to send a text message longer than that, it has to be broken up into pieces. That in itself isn't a problem - the entire Internet works the same way The problem arises from two things:

• SMS is typically sent over a packet network - that is, each piece is like a separate envelope in the mail with just a destination address. Each envelope is guaranteed to get to the destination, but it's not guaranteed to take the same path as all the other envelopes. So the order you drop the envelopes in the mailbox may not be the order they arrive in at the recipient's mailbox.
• Each piece has its own timestamp, but the timestamp is just 7 bytes long (the standard is so old the term "byte" hadn't been invented yet, so they were called octets). Only one byte encodes the time in seconds, and it only does it in integer seconds (that is, all the extra values above 59 are never used).
  https://en.wikipedia.org/wiki/GSM_03.40#Time_Format

This is a problem, as when a long text is broken up into 140 byte pieces, it's done almost instantly by computer and so each piece has the exact same timestamp. There is no way to put these pieces back in the correct order again.

When you send these pieces within a single carrier's network, there's a high probability each piece will take the exact same path, so they arrive in the correct order, and your phone reassembles them in the proper order. But when you're sending texts between carriers, there's a greater chance the pieces will arrive out of order, and you get a multi-part text whose parts are scrambled. Correcting this would require somehow encapsulating all the pieces of the text into a single packet, which means every carrier out there would have to agree on how to do this encapsulation. You might as well just create a new SMS standard at that point. (Which they kinda did with MMS - you can bypass this problem by setting the option for your phone to send long text messages as MMS. But unfortunately it doesn't work when people who don't have this option set send long text messages to you.)

The overall impression I'm getting is that we are suffering today because the folks who put together the original GSM spec weren't very competent.

• They wasted 76% of the octet's capacity by only encoding seconds as integer digits instead of fractional seconds.
• They didn't foresee the possibility of multiple SMSes being sent with the same timestamp but whose order was important. They could've added an extra octet to give each piece a sequential number - what Internet Protocols do. Heck, they could've used the extra 2 bits in the seconds octect to store the sequence number. 6 bits = 64 values, which is enough for 0-59 seconds. Leaving 2 bits (0-3) for an ordering sequence for SMSes sent in the same second.
• They enshrined TDMA as the standard. TDMA is woefully inefficient with bandwidth because it has to assign bandwidth to phones which might not use it. That's why when cellular data suddenly became important, CDMA won the GSM vs CDMA war. GSM ended up incorporating CDMA into its data spec. Most implementations of 3G data on GSM phones (HSPA, HSDPA) used CDMA or wideband CDMA. If it weren't for CDMA, the data speeds on GSM phones would probably be around 200 kbps today. Even LTE (which mostly uses OFDMA) would've come to market later because it relies on a lot of the same principles as CDMA - using orthogonal frequencies instead of orthogonal codes. So CDMA served as the proof of concept for OFDMA.

 

[Scott L Kelly]

Which they kinda did with MMS - you can bypass this problem by setting the option for your phone to send long text messages as MMS.

Thanks for your post. This all makes much more sense, along the lines I expected was the issue. But I'm still a little stuck, myself: I've had issues in the past where it went both ways - both myself and the recipient, on different networks, had the issue of longer texts being broken up. Now I have a friend who just told me my texts to her get broken up, even though I see her texts fine. Regardless... more to the point: I can't find anywhere on my Galaxy S4 that lets me force outgoing messages to be MMS. Am I correct in understanding that's what you meant, that this should be an option? My phone is just running the stock OS/ROM/etc. No mods. I don't expect that anyone should know every phone, but if you have any ideas it would be an amazing help. Thanks.

 

[jenstruk]

You are right on the money here and the first correct and intelligent answer I have seen online regarding this issue! It is an ongoing and extremely frustrating problem for many users. Many T-Mobile customers have friends and family who use Verizon, Sprint or AT&T and those people constantly receive scrambled texts. They blame T-Mobile or the particular phone model and ilt is incredibly hard to explain this is not the issue. It does not help that there are people who think they know the problem is CDMA vs GSM incompatibility, publish their theories on the web everywhere and they are incorrect. What a shame that YOU were not in charge of the pioneering cellular code data from the get-go, then we need not have this discussion at all!

Old topic, but replying to this because this is the #1 search result on Google.

I don't think GSM or CDMA has anything to do with it. In this T-Mobile post here, you can see someone complaining about the same problem in texts from a T-Mobile phone to an AT&T phone. Both T-Mobile and AT&T are GSM networks, so the problem also happens in purely GSM to GSM text messages.
https://support.t-mobile.com/message/380255#380255

As best as I've been able to figure out, the problem is that SMS is limited to 140 bytes (160 characters for 7-bit ASCII text). This isn't a CDMA limitation - the GSM spec for SMS sets the message length at a maximum 140 bytes. So regardless of your carrier, if you try to send a text message longer than that, it has to be broken up into pieces. That in itself isn't a problem - the entire Internet works the same way The problem arises from two things:

• SMS is typically sent over a packet network - that is, each piece is like a separate envelope in the mail with just a destination address. Each envelope is guaranteed to get to the destination, but it's not guaranteed to take the same path as all the other envelopes. So the order you drop the envelopes in the mailbox may not be the order they arrive in at the recipient's mailbox.
• Each piece has its own timestamp, but the timestamp is just 7 bytes long (the standard is so old the term "byte" hadn't been invented yet, so they were called octets). Only one byte encodes the time in seconds, and it only does it in integer seconds (that is, all the extra values above 59 are never used).
  https://en.wikipedia.org/wiki/GSM_03.40#Time_Format

This is a problem, as when a long text is broken up into 140 byte pieces, it's done almost instantly by computer and so each piece has the exact same timestamp. There is no way to put these pieces back in the correct order again.

When you send these pieces within a single carrier's network, there's a high probability each piece will take the exact same path, so they arrive in the correct order, and your phone reassembles them in the proper order. But when you're sending texts between carriers, there's a greater chance the pieces will arrive out of order, and you get a multi-part text whose parts are scrambled. Correcting this would require somehow encapsulating all the pieces of the text into a single packet, which means every carrier out there would have to agree on how to do this encapsulation. You might as well just create a new SMS standard at that point. (Which they kinda did with MMS - you can bypass this problem by setting the option for your phone to send long text messages as MMS. But unfortunately it doesn't work when people who don't have this option set send long text messages to you.)

The overall impression I'm getting is that we are suffering today because the folks who put together the original GSM spec weren't very competent.

• They wasted 76% of the octet's capacity by only encoding seconds as integer digits instead of fractional seconds.
• They didn't foresee the possibility of multiple SMSes being sent with the same timestamp but whose order was important. They could've added an extra octet to give each piece a sequential number - what Internet Protocols do. Heck, they could've used the extra 2 bits in the seconds octect to store the sequence number. 6 bits = 64 values, which is enough for 0-59 seconds. Leaving 2 bits (0-3) for an ordering sequence for SMSes sent in the same second.
• They enshrined TDMA as the standard. TDMA is woefully inefficient with bandwidth because it has to assign bandwidth to phones which might not use it. That's why when cellular data suddenly became important, CDMA won the GSM vs CDMA war. GSM ended up incorporating CDMA into its data spec. Most implementations of 3G data on GSM phones (HSPA, HSDPA) used CDMA or wideband CDMA. If it weren't for CDMA, the data speeds on GSM phones would probably be around 200 kbps today. Even LTE (which mostly uses OFDMA) would've come to market later because it relies on a lot of the same principles as CDMA - using orthogonal frequencies instead of orthogonal codes. So CDMA served as the proof of concept for OFDMA.

 

[sherambo]

"more to the point: I can't find anywhere on my Galaxy S4 that lets me force outgoing messages to be MMS."

Regarding above comment from Scott Kelly in this thread.... I have a Samsung Galaxy 6. If I know that someone I'm sending a text to doesn't have an iPhone, chances are the long text I send will be fragmented at their end. So before I send the text to that person, I click on "more" at the top. It opens up a box of options. If you have "message options" available to you, click on that. Another box of options open, one of which says "create slideshow". Click on that and it will convert your text to an MMS. Press done and send.

 

[nirmeshs]

As far as I remember, there was an extension to SMS call EMS (https://en.wikipedia.org/wiki/Enhanced_Messaging_Service) which never had wide adoption. However, some of the features, specifically some User Data Headers (https://en.wikipedia.org/wiki/User_Data_Header) were supported by most of the GSM operators. The first UDH is for concatenation and I have personally seen it work manually (manually created two SMS with appropriate UDH headers; sent them out of order and seen them appear on the phone in order).

I do not really understand why CDMA never supported this since it seems more of a device level feature than a network level one but I have seen the same thing not work on CDMA network / devices although the SMS payload that reaches the CDMA devices is exactly the same as the one that reached GSM devices.

Please note that all my testing has been done in India around three years ago. Also, not all UDH seem to work. I have seen message concatenation and delivery to specific ports work but have not been able to get text formatting working.

Old topic, but replying to this because this is the #1 search result on Google.

I don't think GSM or CDMA has anything to do with it. In this T-Mobile post here, you can see someone complaining about the same problem in texts from a T-Mobile phone to an AT&T phone. Both T-Mobile and AT&T are GSM networks, so the problem also happens in purely GSM to GSM text messages.
https://support.t-mobile.com/message/380255#380255

As best as I've been able to figure out, the problem is that SMS is limited to 140 bytes (160 characters for 7-bit ASCII text). This isn't a CDMA limitation - the GSM spec for SMS sets the message length at a maximum 140 bytes. So regardless of your carrier, if you try to send a text message longer than that, it has to be broken up into pieces. That in itself isn't a problem - the entire Internet works the same way The problem arises from two things:

• SMS is typically sent over a packet network - that is, each piece is like a separate envelope in the mail with just a destination address. Each envelope is guaranteed to get to the destination, but it's not guaranteed to take the same path as all the other envelopes. So the order you drop the envelopes in the mailbox may not be the order they arrive in at the recipient's mailbox.
• Each piece has its own timestamp, but the timestamp is just 7 bytes long (the standard is so old the term "byte" hadn't been invented yet, so they were called octets). Only one byte encodes the time in seconds, and it only does it in integer seconds (that is, all the extra values above 59 are never used).
  https://en.wikipedia.org/wiki/GSM_03.40#Time_Format

This is a problem, as when a long text is broken up into 140 byte pieces, it's done almost instantly by computer and so each piece has the exact same timestamp. There is no way to put these pieces back in the correct order again.

When you send these pieces within a single carrier's network, there's a high probability each piece will take the exact same path, so they arrive in the correct order, and your phone reassembles them in the proper order. But when you're sending texts between carriers, there's a greater chance the pieces will arrive out of order, and you get a multi-part text whose parts are scrambled. Correcting this would require somehow encapsulating all the pieces of the text into a single packet, which means every carrier out there would have to agree on how to do this encapsulation. You might as well just create a new SMS standard at that point. (Which they kinda did with MMS - you can bypass this problem by setting the option for your phone to send long text messages as MMS. But unfortunately it doesn't work when people who don't have this option set send long text messages to you.)

The overall impression I'm getting is that we are suffering today because the folks who put together the original GSM spec weren't very competent.

• They wasted 76% of the octet's capacity by only encoding seconds as integer digits instead of fractional seconds.
• They didn't foresee the possibility of multiple SMSes being sent with the same timestamp but whose order was important. They could've added an extra octet to give each piece a sequential number - what Internet Protocols do. Heck, they could've used the extra 2 bits in the seconds octect to store the sequence number. 6 bits = 64 values, which is enough for 0-59 seconds. Leaving 2 bits (0-3) for an ordering sequence for SMSes sent in the same second.
• They enshrined TDMA as the standard. TDMA is woefully inefficient with bandwidth because it has to assign bandwidth to phones which might not use it. That's why when cellular data suddenly became important, CDMA won the GSM vs CDMA war. GSM ended up incorporating CDMA into its data spec. Most implementations of 3G data on GSM phones (HSPA, HSDPA) used CDMA or wideband CDMA. If it weren't for CDMA, the data speeds on GSM phones would probably be around 200 kbps today. Even LTE (which mostly uses OFDMA) would've come to market later because it relies on a lot of the same principles as CDMA - using orthogonal frequencies instead of orthogonal codes. So CDMA served as the proof of concept for OFDMA.