concatenated SMS (long SMS) problems on Motorola C139 with AT&T / Tracfone

John Henderson

2013-09-01 22:13:26 UTC

Post by g***@gmail.com
Hoping perhaps someone in this group can shed some light on a problem I've been having.
Periodically (but more frequently within the last few months) I get an "incomplete concatenated message" error when I try to open a long incoming text message. My inbox shows multiple messages; trying to open any of them gives that error. Clearly it's a long message which got split up and, for whatever reason, can't be put back together again.
This is on a Motorola C139 with Tracfone service; the actual carrier that Tracfone hooked me up with is AT&T, though I guess with Tracfone, I may sometimes be using other carriers without knowing it. I got the phone & service in 2008.
Tracfone support has not been able to help; nothing including them "resetting my texting setup" (not sure what it means or what they really did) to a master reset of the phone, made any difference. I was able to get them to do an online chat with AT&T but the latter didn't see any problems in my area. So Tracfone thinks it's a problem with the phone (but won't replace it since it's no longer under warranty) and Motorola won't give me any support since they say the carrier is responsible for texting functionality.

The carrier is responsible for delivering the parts of a split message
to your phone. Your phone manufacturer is responsible for the
process of reassembly for display.

The manufacturer of the sending phone is responsible for correctly
splitting the concatenated message into parts in the first place.

The 3GPP standards do require that the phone store all the parts exactly
as received (without reassembly).

Post by g***@gmail.com
If I understand correctly, messages may be sent with either 7-bit or 16-bit encoding?

For the record, 8-bit is also possible, but can be ignored as it isn't
used for text by ant manufacturer I'm aware of.

Post by g***@gmail.com
I had a thought which might explain what I'm seeing, but wanted to check with

technically-minded folks. Is it possible that the 16-bit method was
only introduced after my phone and its firmware were designed? Thus, I
can get 7-bit encoded message ok, but not 16-bit? I'm trying to find
information regarding when the 16-bit scheme was introduced, but
haven't had any luck.

The 3GPP standards usually pre-date manufacturers implementation by
several years. Many innovations never find their way into production.

But more importantly, the actual implementation of more unusual features
is often quite bug-ridden (by the device manufacturers).

On that note, I would hope that you'd be shown the individual parts of
any concatenated message where either some of the parts or missing, or
the whole cannot be reassembled due to the original splitting (sender's
phone) being badly-formed.

That is made possible by 3GPP 23.040 (the standard covering this). It
ensures that the individual parts of any concatenated message can be
displayed correctly on a phone which does not implement the
concatenation mechanism.

I recall 16-bit SMS being alive and well developed in the 3GPP specs
more than 10 years ago.

16-bit unicode is generally used only when a text contains non-European
characters. That covers a lot more than ordinary printable ASCII.

Post by g***@gmail.com
An observation which makes me think it may be only an issue with 16-bit encoding is that there's one person in particular whose text messages give me the problem more frequently than any else. I've noticed that it takes fewer characters in one of their messages for Tracfone to charge me for 2 messages instead of 1; thus I'm assuming they're likely in 16-bit format.

The text payload in an SMS is 140 bytes. That's 160 7-bit characters,
or 140 8-bit, or 70 16-bit. Once those thresholds are reached, the
payload per individual part is a little less that that, because the
cross-referencing info eats into the 140-byte User Data field.

Post by g***@gmail.com
If anyone has any thoughts or advice, I'd really appreciate it.

If your phone is "dumb" (not a smart-phone), there's a good chance that
it will support AT commands over a serial (typically USB) interface. In
that case, it should be possible to read off the incoming parts of the
SMSs and see if any parts are missing. And also check that the parts
which have been received are well-formed.

John