3G/UMTS

 

 

 

SMS Class

 

An MT SMS can tell the UE what to do with it after it arrives. The UE may show it at once, keep it in the phone, put it on the USIM, or pass it to a connected device. This instruction is the message class. It is optional, and most person-to-person SMS carry no class at all. This page lists the four classes, shows where the class sits in the TP-DCS octet, and explains how the class changes the acknowledgement that the UE sends back.

What does each class tell the UE ?

The class is a hint about the destination of the message, not about its content. So the same text can arrive as class 0 or class 1, and only the place where it ends up changes. There are four different classes (types) of SMS as described below.

Class 0

: The type of SMS to be displayed on the mobile screen without being saved in the message store or on the SIM card; unless explicitly saved by the mobile user.

Class 1

: The type of SMS to be stored in the device memory or the SIM card.

Class 2

: The type of SMS that carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgment to the service center. An error message is sent to the service center if this transmission is not possible.

Class 3

: The type of SMS to be forwarded from the receiving entity to an external device. The delivery acknowledgment is sent to the service center regardless of whether or not the message was forwarded to the external device.

3GPP TS 23.038 names class 1 "ME-specific", class 2 "(U)SIM-specific" and class 3 "TE-specific". For class 1 and class 3 it adds the words "default meaning". This means that the user may change the routing of these two classes in the phone settings. Class 0 and class 2 have no such default meaning, so the UE follows them as written.

For class 1, the UE stores the message in the ME if it can. Only when that is not possible does it use another store, such as the USIM. For class 2, the destination is the SMS data field of the USIM. Class 2 is also the class that the (U)SIM Data download mechanism uses. In that case TP-PID is set to "(U)SIM Data download", and the ME passes the whole message to the USIM instead of showing it. For class 3, the TE is a device connected to the UE, such as a PC that uses the AT commands of 27.005 to read messages.

  • No class is the normal case : A person-to-person SMS usually has TP-DCS 0x00, and the UE then stores it by its own rules.
  • Class 0 is sometimes called a flash SMS : The UE shows it on the screen immediately and does not store it unless the user saves it.
  • Class 2 always ends up in the USIM : This is why the network uses it for data that belongs to the USIM rather than to the user.

Where is the class coded in the SMS ?

The class has no field of its own in the SMS-DELIVER TPDU. It shares the TP-Data-Coding-Scheme octet with the alphabet, so you have to decode TP-DCS to find it. Three coding groups can carry a class, and the rest of the groups carry none.

The upper four bits of TP-DCS select the coding group. In the General Data Coding group, 00xx, bit 4 says whether bits 1 and 0 carry a class at all. Bits 3 and 2 give the alphabet, and bit 5 says whether the text is compressed. The Automatic Deletion group, 01xx, uses bits 5 to 0 in the same way. In the Data coding/message class group, 1111, the class is always present. Bit 2 then selects the GSM 7 bit default alphabet or 8 bit data, and bit 3 is reserved. The Message Waiting Indication groups, 1100 to 1110, carry no class.

 

TP-DCS

Coding group

Alphabet

Message class

0x00

General Data Coding, bit 4 = 0

GSM 7 bit default alphabet

No class

0x10

General Data Coding, bit 4 = 1

GSM 7 bit default alphabet

Class 0

0x11 / 0x12 / 0x13

General Data Coding, bit 4 = 1

GSM 7 bit default alphabet

Class 1 / Class 2 / Class 3

0x14 to 0x17

General Data Coding, bit 4 = 1

8 bit data

Class 0 to Class 3

0x18 to 0x1B

General Data Coding, bit 4 = 1

UCS2

Class 0 to Class 3

0xF0 to 0xF3

Data coding/message class

GSM 7 bit default alphabet

Class 0 to Class 3

0xF4 to 0xF7

Data coding/message class

8 bit data

Class 0 to Class 3

 

The table lists only the uncompressed values. Setting bit 5 in the 00xx group gives the compressed versions, and the 01xx group repeats the same layout from 0x40. Note the special case at the top. 23.038 defines 0x00 as the GSM 7 bit default alphabet with no message class, so 0x00 and 0x10 differ only in the class. The SMS page shows both in a live log. Case 1 there has TP-DCS 0, and Case 2 has TP-DCS 16, which is 0x10 and so a class 0 message.

  • Bit 4 is the switch in the General Data Coding group : With bit 4 at 0, bits 1 and 0 are reserved and the message has no class.
  • Two codings give the same class : 0x10 and 0xF0 both mean class 0 in the GSM 7 bit default alphabet, so check both groups when you filter a log.
  • UCS2 needs the 00xx group : The 1111 group has no UCS2 value, so a class 0 message in UCS2 uses 0x18.

How does the class change the acknowledgement ?

The class matters most when something goes wrong, for example when the memory is full. The UE acknowledges an MT SMS with RP-ACK, or rejects it with RP-ERROR, inside a CP-DATA. The class decides when the UE may send the RP-ACK and which RP-Cause it uses when it cannot.

For class 0, the UE shows the message and sends the acknowledgement as soon as the message reaches the MS. Free memory in the ME or the USIM does not matter here. This only holds if the UE can display it. Some UEs cannot display short messages, and on others the user has disabled immediate display. Such a UE treats the message as if it had no class, and the normal memory full rules apply.

For class 1 and class 3, the UE acknowledges when the message has reached the MS and can be stored. For class 3 the UE does not wait for the TE. So an RP-ACK for a class 3 message does not prove that the message reached the connected device. The class 3 description above says the same.

Class 2 has the strictest rule. The UE has to transfer the message to the USIM before it sends the acknowledgement. If the USIM is full but the phone still has other free SMS memory, the UE answers "protocol error, unspecified". If all SMS memory is full, the UE answers "memory capacity exceeded". The only exception is a (U)SIM Data download message on a UE that supports the (U)SIM Application Toolkit.

 

Class

The UE sends RP-ACK when

The UE stores it in

If it cannot be stored

0

The message reaches the MS, even with no free memory

Nowhere, unless the user saves it

Not applicable while the UE can display it

1

The message reaches the MS and can be stored

ME by default, otherwise for example the USIM

Normal memory full handling

2

The message is stored in the USIM

SMS data field of the USIM

RP-Cause 111 if other memory is free, RP-Cause 22 if all memory is full

3

The message reaches the MS and can be stored, without waiting for the TE

For transfer to the TE

Normal memory full handling

 

RP-Cause 22 is "Memory capacity exceeded" and RP-Cause 111 is "Protocol error, unspecified" in 24.011. After a memory full rejection, the UE sets the memory capacity exceeded notification flag in the USIM. When memory becomes free again, the UE reads this flag and sends RP-SMMA. RP-SMMA tells the network that the UE can receive short messages again, so the network can alert the service centre to send the waiting messages.

  • Class 0 never fails on memory : A display-capable UE acknowledges a class 0 message even when all its SMS memory is full.
  • An RP-ACK does not always mean delivery to the end point : For class 3 it only means the message reached the MS, not the TE.
  • Class 2 errors carry two different causes : RP-Cause 111 means that only the USIM is full, and RP-Cause 22 means that the UE has no SMS memory left at all.

Reference

  • 3GPP TS 23.038 v20.0.0 : Alphabets and language-specific information
  • 3GPP TS 23.040 v20.0.0 : Technical realization of the Short Message Service (SMS)
  • 3GPP TS 24.011 v20.0.0 : Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface