On UMTS, a short message travels on the CS domain as NAS signalling, not as user data. The RRC layer only carries it in DownlinkDirectTransfer and UplinkDirectTransfer messages. Inside those, three protocol layers each add their own header and their own acknowledgement. This page first explains those layers, and then walks through two MT SMS captures from a test equipment. The first is a plain SMS. The second is a class 0 SMS with a status report request and a reply path.
- How is an MT SMS carried over UMTS ?
- Case 1 : MT SMS - No Class, No Status Report Requested, No Reply Path
- Case 2 : MT SMS - Class 0, Status Report Requested, Reply Path
- What changes between the two cases ?
- Reference
How is an MT SMS carried over UMTS ?
Every capture on this page has four NAS messages, but only one short message. The reason is that SMS is built from three layers, and two of them have their own acknowledgement. So let's separate the layers before reading the logs.
The lowest layer is the CM sublayer of 24.011, whose messages are CP-DATA, CP-ACK and CP-ERROR. CP-ACK confirms only that a CP-DATA arrived. The middle layer is the relay layer of 24.011, whose messages are RP-DATA, RP-ACK, RP-ERROR and RP-SMMA. RP-ACK confirms that the short message was accepted. The top layer is the transfer layer of 23.040, which defines the TPDU, here an SMS-DELIVER from the service centre and an SMS-DELIVER-REPORT from the UE. Each layer is carried in the user data field of the layer below it.
Layer |
Specification |
Messages in the captures |
What its acknowledgement means |
CM sublayer, CP |
24.011, protocol discriminator 1001 |
CP-DATA, CP-ACK |
CP-ACK : the CP-DATA arrived |
Relay layer, RP |
24.011 |
RP-DATA, RP-ACK |
RP-ACK : the short message was accepted |
Transfer layer, TP |
23.040 |
SMS-DELIVER, SMS-DELIVER-REPORT |
Carried inside RP-ACK or RP-ERROR |
So an MT SMS always has the same four steps. The network sends CP-DATA with RP-DATA, and the UE confirms it with CP-ACK. The UE then sends its own CP-DATA with RP-ACK, and the network confirms that with CP-ACK. The sender of each CP-DATA starts timer TC1* and repeats the CP-DATA if no CP-ACK arrives in time. On the UE side, timer TR2M, 12 to 20 seconds, limits how long the UE may take to produce the RP-ACK.
An MO SMS mirrors this flow. The UE sends CP-DATA with RP-DATA, and the TPDU inside is an SMS-SUBMIT. The network answers with CP-ACK and then with CP-DATA carrying RP-ACK, which holds an SMS-SUBMIT-REPORT. The UE confirms that with a final CP-ACK. On the UE side, timer TR1M, 35 to 45 seconds, limits the wait for the RP-ACK. The same CP and RP messages can also run over the PS domain, through GMM instead of MM. The captures on this page use the CS domain, which is why the RRC messages carry cn-DomainIdentity cs-domain.
Two acknowledgements, two meanings : A CP-ACK without an RP-ACK means that the message arrived but the UE has not accepted it yet.The TI flag shows the direction of the transaction : The network starts the transaction, so its messages carry TI flag 0 and the UE answers with TI flag 1.RRC only carries the SMS : cn-DomainIdentity cs-domain is the only SMS related field at RRC level.
Case 1 : MT SMS - No Class, No Status Report Requested, No Reply Path
This is the plain case, with every optional feature of the SMS-DELIVER switched off. It gives the baseline for Case 2. The test equipment plays the network and the service centre, and it sends the text "MT SMS" to the UE.
01) < In Idle Mode or In Connected Mode >
02) < Send a SMS (from Network) to Test UE >
03) < Various Protocol Sequence depending on Situation >
04) UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
05) UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
Steps 01 to 03 depend on the state of the UE. In idle mode the network pages the UE and sets up an RRC connection and an MM connection first. In connected mode it can use the existing connection. The four SMS messages themselves are the same in both cases.
04) UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
This one message carries the whole short message, nested three layers deep inside RRC. The decoder prints the layers one after another: first CP-DATA, then RP-DATA, and then the SMS-DELIVER TPDU. The raw RRC bytes follow at the end.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.dl.dcch (Radio Resource Control (RRC) protocol)
DL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 2848d6b8 [bit length 32, 0010 1000 0100 1000 1101 0110 1011 1000 decimal value 675862200]
rrc-MessageSequenceNumber: 0
message: downlinkDirectTransfer (5)
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 090121010004819999990018040a81214365870900005140...
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 33
RPDU (not displayed)
GSM A-I/F RP - RP-DATA (Network to MS)
Message Type RP-DATA (Network to MS)
RP-Message Reference
RP-Message Reference: 0x00 (0)
RP-Originator Address - (999999)
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x00)
.... 0001 = Numbering plan identification: ISDN/Telephony Numbering
(ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x01)
BCD Digits: 999999
RP-Destination Address
Length: 0
RP-User Data
Length: 24
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-DELIVER
0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
.0.. .... = TP-UDHI: The TP UD field contains only the short message
..0. .... = TP-SRI: A status report shall not be returned to the SME
.... .1.. = TP-MMS: No more messages are waiting for the MS in this SC
.... ..00 = TP-MTI: SMS-DELIVER (0)
TP-Originating-Address - (1234567890)
Length: 10 address digits
1... .... : No extension
.000 .... : Type of number: (0) Unknown
.... 0001 : Numbering plan: (1) ISDN/telephone (E.164/E.163)
TP-OA Digits: 1234567890
TP-PID: 0
00.. .... : defines formatting for subsequent bits
..0. .... : no telematic interworking, but SME-to-SME protocol
...0 0000 : the SM-AL protocol being used between the SME and the MS (0)
TP-DCS: 0
00.. .... = Coding Group Bits: General Data Coding indication (0)
Special case, GSM 7 bit default alphabet
TP-Service-Centre-Time-Stamp
Year 15, Month 04, Day 07
Hour 13, Minutes 13, Seconds 29
Timezone: GMT + 5 hours 0 minutes
TP-User-Data-Length: (6) depends on Data-Coding-Scheme
TP-User-Data
SMS text: MT SMS
DL-DCCH (Hex) : 94 24 6B 5C 01 40 04 61 20 24 20 20 00 90 33 33 33 20 03 00 81 50 24 28 6C B0 E1 20 00 0A 28 0E 06 26 32 40 40 C9 A5 4D 1B 53 80 40
Let's follow the nas-Message bytes. 09 is protocol discriminator 9 for SMS with TI flag 0, and 01 is CP-DATA. 21 is the CP-User data length, 33 octets. The RP-DATA follows. 01 is the RP message type RP-DATA from network to MS, and 00 is the RP-Message Reference. 04 81 99 99 99 is the RP-Originator Address, which is the address of the service centre, 999999. 00 is an empty RP-Destination Address, which is how this direction always sends it. 18 is the RP-User Data length, 24 octets.
The TPDU starts with 04. Its TP-MTI is 00 for SMS-DELIVER, and TP-MMS is 1, so no more messages are waiting in the service centre. TP-SRI and TP-RP are 0. 0A 81 21 43 65 87 09 is the TP-Originating-Address, 10 digits, 1234567890. TP-PID is 0, and TP-DCS is 0, the GSM 7 bit default alphabet with no message class. The 6 characters of "MT SMS" take 6 octets after 7 bit packing. So the TPDU is 1 + 7 + 1 + 1 + 7 + 1 + 6 = 24 octets, which matches the RP-User Data length.
05) UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
The UE confirms at the CM sublayer that the CP-DATA arrived. This is not yet an acceptance of the short message. Without it, the network repeats the CP-DATA when TC1* expires.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.ul.dcch (Radio Resource Control (RRC) protocol)
UL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: b8adcbba [bit length 32, 1011 1000 1010 1101 1100 1011 1011 1010
decimal value 3098397626]
rrc-MessageSequenceNumber: 1
message: uplinkDirectTransfer (27)
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 8904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
UL-DCCH : DC 56 E5 DD 0E C0 00 C4 82 00
The whole NAS message is two octets, 89 04. The TI flag is now 1, because the UE answers inside a transaction that the network started. The TIO stays 0, so this CP-ACK belongs to the CP-DATA of step 04.
06) UE -> NW : uplinkDirectTransfer + SMS : CP-DATA
This is the real answer to the short message. The UE puts an RP-ACK into a new CP-DATA and tells the service centre that it has accepted the SMS-DELIVER. The RP-ACK carries an SMS-DELIVER-REPORT with almost nothing in it.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.ul.dcch (Radio Resource Control (RRC) protocol)
UL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 1b631b7a [bit length 32, 0001 1011 0110 0011 0001 1011 0111 1010
decimal value 459479930]
rrc-MessageSequenceNumber: 2
message: uplinkDirectTransfer (27)
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 890106020041020000
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 6
RPDU (not displayed)
GSM A-I/F RP - RP-ACK (MS to Network)
Message Type RP-ACK (MS to Network)
RP-Message Reference
RP-Message Reference: 0x00 (0)
RP-User Data
Element ID: 0x41
Length: 2
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-DELIVER REPORT
.0.. .... = TP-UDHI: The TP UD field contains only the short message
.... .0.. = TP-MMS: More messages are waiting for the MS in this SC
.... ..00 = TP-MTI: SMS-DELIVER REPORT (0)
TP-Parameter-Indicator
0... .... : No extension
.000 0... : Reserved
.... .0.. : TP-UDL not present
.... ..0. : TP-DCS not present
.... ...0 : TP-PID not present
UL-DCCH : 8D B1 8D BD 16 C0 04 44 80 83 01 00 20 81 00 00 00
The NAS message is 89 01 06 02 00 41 02 00 00. After the CP header, 06 is the CP-User data length. 02 is RP-ACK from MS to network, and 00 is the RP-Message Reference, the same value as in the RP-DATA of step 04. 41 is the IEI of the optional RP-User Data, with a length of 2. The TPDU is 00 00. The first octet gives TP-MTI 00, SMS-DELIVER-REPORT, and the second is a TP-Parameter-Indicator of 0, so TP-PID, TP-DCS and TP-UDL are all absent.
Note one line in the decode. The decoder shows "TP-MMS: More messages are waiting" for the SMS-DELIVER-REPORT. 23.040 defines no TP-MMS in an SMS-DELIVER-REPORT. There bit 2 is simply unused and set to 0, so this line is a decoder artefact and has no meaning.
07) UE <- NW : downlinkDirectTransfer + SMS : CP-ACK
The network closes the SMS transaction with a CP-ACK for the CP-DATA of step 06. After this message, both sides can release the MM connection, and the SMS delivery is complete.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.dl.dcch (Radio Resource Control (RRC) protocol)
DL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 536feda8 [bit length 32, 0101 0011 0110 1111 1110 1101 1010 1000
decimal value 1399844264]
rrc-MessageSequenceNumber: 1
message: downlinkDirectTransfer (5)
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 0904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
DL-DCCH : A9 B7 F6 D4 09 40 00 21 20 80
The RP-Message Reference links steps 04 and 06 : The service centre matches the RP-ACK to its RP-DATA by this value, 0 in both.TP-DCS 0 is the most common value : It means the GSM 7 bit default alphabet and no message class, so the UE stores the message by its own rules.The lengths nest exactly : CP-User data 33 = 9 octets of RP header + 24 octets of TPDU, and the TPDU fields add up to 24.
Case 2 : MT SMS - Class 0, Status Report Requested, Reply Path
This case sends the text "MT SMS 2" with three options switched on: message class 0, a status report for the sender and a reply path. All three live in the SMS-DELIVER TPDU, so only step 04 differs from Case 1.
01) < In Idle Mode or In Connected Mode >
02) < Send a SMS (from Network) to Test UE >
03) < Various Protocol Sequence depending on Situation >
04) UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
05) UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
04) UE <- NW : downlinkDirectTransfer + SMS : CP-DATA
Compare this decode with step 04 of Case 1. The CP and RP layers are the same except for the lengths. The differences are in the first octet of the TPDU, in TP-DCS and in the user data.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.dl.dcch (Radio Resource Control (RRC) protocol)
DL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 45c8f692 [bit length 32, 0100 0101 1100 1000 1111 0110 1001 0010
decimal value 1170798226]
rrc-MessageSequenceNumber: 0
message: downlinkDirectTransfer (5)
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 090122010004819999990019a40a81214365870900105140...
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 34
RPDU (not displayed)
GSM A-I/F RP - RP-DATA (Network to MS)
Message Type RP-DATA (Network to MS)
RP-Message Reference
RP-Message Reference: 0x00 (0)
RP-Originator Address - (999999)
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x00)
.... 0001 = Numbering plan identification: ISDN/Telephony Numbering
(ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x01)
BCD Digits: 999999
RP-Destination Address
Length: 0
RP-User Data
Length: 25
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-DELIVER
1... .... = TP-RP: TP Reply Path parameter is set in this SMS SUBMIT/DELIVER
.0.. .... = TP-UDHI: The TP UD field contains only the short message
..1. .... = TP-SRI: A status report shall be returned to the SME
.... .1.. = TP-MMS: No more messages are waiting for the MS in this SC
.... ..00 = TP-MTI: SMS-DELIVER (0)
TP-Originating-Address - (1234567890)
Length: 10 address digits
1... .... : No extension
.000 .... : Type of number: (0) Unknown
.... 0001 : Numbering plan: (1) ISDN/telephone (E.164/E.163)
TP-OA Digits: 1234567890
TP-PID: 0
00.. .... : defines formatting for subsequent bits
..0. .... : no telematic interworking, but SME-to-SME protocol
...0 0000 : the SM-AL protocol being used between the SME and the MS (0)
TP-DCS: 16
00.. .... = Coding Group Bits: General Data Coding indication (0)
00.. .... : General Data Coding indication
..0. .... : Text is not compressed
...1 .... : Message class is defined below
.... 00.. : Character set: GSM 7 bit default alphabet
.... ..00 : Message Class: Class 0
TP-Service-Centre-Time-Stamp
Year 15, Month 04, Day 07
Hour 13, Minutes 41, Seconds 28
Timezone: GMT + 5 hours 0 minutes
TP-User-Data-Length: (8) depends on Data-Coding-Scheme
TP-User-Data
SMS text: MT SMS 2
DL-DCCH (Hex) : A2 E4 7B 49 01 40 04 81 20 24 40 20 00 90 33 33 33 20 03 34 81 50 24 28 6C B0 E1 20 02 0A 28 0E 06 22 90 40 41 09 A5 4D 1B 53 90 4C 80
The first octet of the TPDU is now A4 instead of 04. Bit 7 is TP-RP = 1, so a reply path exists. Bit 5 is TP-SRI = 1, so the service centre will return a status report to the SME that sent the message. Bit 2 is still TP-MMS = 1. TP-DCS is 16, which is 0x10. Bit 4 of TP-DCS is 1, so bits 1 and 0 carry a message class, and their value 00 means class 0. Bits 3 and 2 are 00, the GSM 7 bit default alphabet.
"MT SMS 2" has 8 characters, which take 7 octets after 7 bit packing. So the TPDU grows to 25 octets, the RP-User Data length is 25, and the CP-User data length is 22 hex, 34. The status report is a matter between the service centre and the sender. The UE does nothing extra for it. The reply path means that a reply from this UE may go through the same service centre, the one in RP-Originator Address 999999. The class 0 means that the UE shows the text on the screen at once and does not store it by default. The SMS Class page explains the classes in detail.
05) UE -> NW : uplinkDirectTransfer + SMS : CP-ACK
The CP-ACK is the same two octets as in Case 1, 89 04. The class and the other TPDU options are invisible at the CM sublayer, so this message cannot differ between the two cases.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.ul.dcch (Radio Resource Control (RRC) protocol)
UL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: bfa07cf9 [bit length 32, 1011 1111 1010 0000 0111 1100 1111 1001
decimal value 3214966009]
rrc-MessageSequenceNumber: 1
message: uplinkDirectTransfer (27)
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 8904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
UL-DCCH : DF D0 3E 7C 8E C0 00 C4 82 00
06) UE -> NW : uplinkDirectTransfer + SMS : CP-DATA
The RP-ACK is also identical to Case 1, octet for octet. A class 0 message gets its acknowledgement as soon as it reaches the UE, so the UE confirms it in the same way as a stored message.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.ul.dcch (Radio Resource Control (RRC) protocol)
UL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 47c1e8a5 [bit length 32, 0100 0111 1100 0001 1110 1000 1010 0101
decimal value 1203890341]
rrc-MessageSequenceNumber: 2
message: uplinkDirectTransfer (27)
uplinkDirectTransfer
cn-DomainIdentity: cs-domain (0)
nas-Message: 890106020041020000
GSM A-I/F DTAP - CP-DATA
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-DATA (0x01)
CP-User Data
Length: 6
RPDU (not displayed)
GSM A-I/F RP - RP-ACK (MS to Network)
Message Type RP-ACK (MS to Network)
RP-Message Reference
RP-Message Reference: 0x00 (0)
RP-User Data
Element ID: 0x41
Length: 2
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-DELIVER REPORT
.0.. .... = TP-UDHI: The TP UD field contains only the short message
.... .0.. = TP-MMS: More messages are waiting for the MS in this SC
.... ..00 = TP-MTI: SMS-DELIVER REPORT (0)
TP-Parameter-Indicator
0... .... : No extension
.000 0... : Reserved
.... .0.. : TP-UDL not present
.... ..0. : TP-DCS not present
.... ...0 : TP-PID not present
UL-DCCH : 8D B1 8D BD 16 C0 04 44 80 83 01 00 20 81 00 00 00
Check the raw bytes of this capture against its decode. The UL-DCCH line is identical to the one in Case 1, step 06. After the first bit, its first 32 bits give a messageAuthenticationCode of 1b631b7a, which is the Case 1 value. The decode above shows 47c1e8a5. So the hex line of this step was copied from Case 1 and does not belong to this decode. The capture is left as it was.
07) UE <- NW : downlinkDirectTransfer + SMS : CP-ACK
The network ends the transaction exactly as in Case 1. Only the integrity check fields and the rrc-MessageSequenceNumber differ, because they change with every RRC message.
Decoded message from a test equipment log,
DLT: 147, Payload: rrc.dl.dcch (Radio Resource Control (RRC) protocol)
DL-DCCH-Message
integrityCheckInfo
messageAuthenticationCode: 94a77955 [bit length 32, 1001 0100 1010 0111 0111 1001 0101 0101
decimal value 2494003541]
rrc-MessageSequenceNumber: 1
message: downlinkDirectTransfer (5)
downlinkDirectTransfer: r3 (0)
r3
downlinkDirectTransfer-r3
rrc-TransactionIdentifier: 0
cn-DomainIdentity: cs-domain (0)
nas-Message: 0904
GSM A-I/F DTAP - CP-ACK
Protocol Discriminator: SMS messages
.... 1001 = Protocol discriminator: SMS messages (0x09)
0... .... = TI flag: allocated by sender
.000 .... = TIO: 0
DTAP Short Message Service Message Type: CP-ACK (0x04)
DL-DCCH : CA 53 BC AA 89 40 00 21 20 80
All three options sit in the SMS-DELIVER : Class, status report and reply path change only step 04.Class 0 does not change the answer : The UE acknowledges a class 0 message with the same RP-ACK as any other message.Check hex against decode : The messageAuthenticationCode is the easiest field to compare, because it starts right after the first bit.
What changes between the two cases ?
Putting the two step 04 decodes side by side shows how little of the message the three options touch. Every difference is in the TPDU, and the lengths change only because the text is two characters longer.
Field |
Case 1 |
Case 2 |
Meaning in Case 2 |
TPDU first octet |
04 |
A4 |
TP-RP and TP-SRI set |
TP-RP |
0 |
1 |
Reply path exists |
TP-SRI |
0 |
1 |
A status report goes back to the sender |
TP-DCS |
0 |
16 |
Class 0, GSM 7 bit default alphabet |
TP-User-Data-Length |
6 |
8 |
"MT SMS 2" has 8 characters |
RP-User Data length |
24 |
25 |
One more octet of packed text |
CP-User data length |
33 |
34 |
Follows the RP length |
Steps 05 to 07 |
- |
- |
Same NAS content in both cases |
What the table cannot show is the effect in the UE. In Case 1 the UE stores the message and shows it in the inbox. In Case 2 the UE shows it on the screen at once and may keep it only if the user saves it. The status report is sent later by the service centre to the original sender, and it never appears in the UE log. To see a failure instead of a success, look for RP-ERROR in step 06, with an RP-Cause such as 22, memory capacity exceeded.
24.011 lists the RP-Cause values that the UE may send in an RP-ERROR for an MT SMS. The table below gives them. Most of them report a protocol problem, so in a test log they usually point to a malformed RP-DATA from the test equipment rather than to the UE.
RP-Cause |
Meaning |
22 | Memory capacity exceeded |
81 | Invalid short message transfer reference value |
95 | Semantically incorrect message |
96 | Invalid mandatory information |
97 | Message type non-existent or not implemented |
98 | Message not compatible with short message protocol state |
99 | Information element non-existent or not implemented |
111 | Protocol error, unspecified |
24.011 treats any other value as cause 111. Cause 22 is the one that changes the network behaviour. After it, the network waits for the UE to report free memory with RP-SMMA before it tries again.
The CP and RP layers do not know about the options : They carry the TPDU unchanged, so only their length fields move.A status report request does not change the UE behaviour : TP-SRI informs the UE that the sender asked for a report, and the service centre sends that report.A failed delivery shows in step 06 : RP-ERROR replaces RP-ACK there, and its cause tells you why the UE rejected the message.
Reference
- 3GPP TS 24.011 v20.0.0 : Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface
- 3GPP TS 23.040 v20.0.0 : Technical realization of the Short Message Service (SMS)
- 3GPP TS 23.038 v20.0.0 : Alphabets and language-specific information
- 3GPP TS 25.331 v19.0.1 : Radio Resource Control (RRC); Protocol specification