Concatenated SMS

In the cellular phone industry, mobile phones and their networks sometimes support concatenated short message service (or concatenated SMS) to overcome the limitation on the number of characters that can be sent in a single SMS text message transmission (which is usually 160). Using this method, long messages are split into smaller messages by the sending device and recombined at the receiving end. Each message is then billed separately. When the feature works properly, it is nearly transparent to the user, appearing as a single long text message. Previously, due to incompatibilities between providers and lack of support in some phone models, there was not widespread use of this feature.

In the late 2000s to early 2010s, this feature was adopted more widely. Not only do many handsets support this feature, but support for the feature also exists amongst SMS gateway providers. The way concatenation works in GSM and UMTS networks is specified in SMS Point to Point specification, 3GPP TS 23.040.

On networks which do not support Concatenated SMS (neither the standard scheme nor the simplified one), the message is delivered as individual SMS text messages rather than one concatenated message.

When part of a standard Concatenated SMS is not received, or received more than once, the receiving device's database can get corrupted, leading to ongoing problems with future messages between the same phones. Free tools are available to clean up an afflicted device's database.

PDU Mode SMS

In technical terms, the concatenated SMS could also be referred to as a PDU Mode SMS. The number of parts that a multi-part or PDU mode SMS message may contain depends technically upon a header message but mostly upon the device sending or receiving the SMS and also upon the service provider.

In theory, the concatenated SMS may consist of up to 255 separate SMS messages that are concatenated in order to create a single long SMS message. Because of the nature of the SMS, the chance that these parts of the SMS message arrive in order is slim and therefore a strategy is implemented in order for the original long message to be reconstructed.

Sending a concatenated SMS using a User Data Header

One way of sending concatenated SMS (CSMS) is to split the message into 153 7-bit character parts (134 octets), and sending each part with a User Data Header (UDH) tacked onto the beginning. A UDH can be used for various purposes and its contents and size varies accordingly, but a UDH for concatenating SMSes look like this:

• 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 06.
• 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. 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

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

as you need to prepend the least significant bits of the next 7bit character whereas without padding, the [message] would be

 C8 32 9B FD 06 DD DF 72 36 19

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

See also

• User Data Header
• GSM 03.38
• GSM 03.40