CWTS TSM 04.11 v1.0.

0 (2000-12)

China Wireless Telecommunication Standard;

3G digital cellular telecommunications system;
Point-to-Point (PP) Short Message Service (SMS)
support on mobile radio interface

TSM
 2 TSM 04.11 V1.0.0 (2000-12)

Contents
Intellectual Property Rights ................................................................................................................................ 6
Foreword ............................................................................................................................................................ 6
1 Scope ........................................................................................................................................................ 6
1.1 Normative references ......................................................................................................................................... 6
1.2 Abbreviations..................................................................................................................................................... 7
2 Overview of Short Message Service (SMS) support................................................................................ 7
2.1 Protocols and protocol architecture ................................................................................................................... 7
2.2 Use of channels .................................................................................................................................................. 8
2.3 Layer 2 SAPI 3 handling for circuit switched TD-SCDMA.............................................................................. 9
2.4 Layer 2 (LLC) packet switched TD-SCDMA support ...................................................................................... 9
3 Service definition ................................................................................................................................... 10
3.1 General............................................................................................................................................................. 10
3.2 Service provided by the CM-sublayer ............................................................................................................. 10
3.2.1 Definition of primitives on the UE side ..................................................................................................... 11
3.2.1.1 MNSMS-ABORT-REQuest ................................................................................................................. 11
3.2.1.2 MNSMS-DATA-REQuest ................................................................................................................... 11
3.2.1.3 MNSMS-DATA-INDication ................................................................................................................ 11
3.2.1.4 MNSMS-ESTablish-REQuest .............................................................................................................. 12
3.2.1.5 MNSMS-ESTablish-INDication .......................................................................................................... 12
3.2.1.6 MNSMS-ERROR-INDication .............................................................................................................. 12
3.2.1.7 MNSMS-RELease-REQuest ................................................................................................................ 12
3.2.2 Definition of primitives on the network side ............................................................................................. 12
3.2.2.1 MNSMS-ABORT-REQuest ................................................................................................................. 12
3.2.2.2 MNSMS-DATA-REQuest ................................................................................................................... 13
3.2.2.3 MNSMS-DATA-INDication ................................................................................................................ 13
3.2.2.4 MNSMS-ESTablish-REQuest .............................................................................................................. 13
3.2.2.5 MNSMS-ESTablish-INDication .......................................................................................................... 13
3.2.2.6 MNSMS-ERROR-INDication .............................................................................................................. 13
3.2.2.7 MNSMS-RELease-REQuest ................................................................................................................ 13
3.3 Service provided by SM-RL ............................................................................................................................ 13
3.3.1 Definition of primitives on the UE side ..................................................................................................... 14
3.3.1.1 SM-RL-DATA-REQuest...................................................................................................................... 14
3.3.1.2 SM-RL-DATA-INDication .................................................................................................................. 14
3.3.1.3 SM-RL-MEMORY-AVAILABLE-REQuest ....................................................................................... 14
3.3.1.4 SM-RL-REPORT-REQest ................................................................................................................... 15
3.3.1.5 SM-RL-REPORT-INDication .............................................................................................................. 15
3.3.2 Definition of primitives on the network side ............................................................................................. 15
3.3.2.1 SM-RL-DATA-REQuest...................................................................................................................... 15
3.3.2.2 SM-RL-DATA-INDication .................................................................................................................. 15
3.3.2.3 SM-RL-MEMORY-AVAILABLE-INDication ................................................................................... 15
3.3.2.4 SM-RL-REPORT-REQuest ................................................................................................................. 16
3.3.2.5 SM-RL-REPORT-INDication .............................................................................................................. 16
4 CM-procedures ....................................................................................................................................... 16
4.1 General............................................................................................................................................................. 16
4.2 Short Message Control states........................................................................................................................... 16
4.2.1 SMC-CS states at the UE side of the radio interface ................................................................................. 16
4.2.1.1 Mobile Originating Case ...................................................................................................................... 16
4.2.1.1.1 MO-Idle (State 0) ............................................................................................................................ 16
4.2.1.1.2 MO-MM-connection pending (State 1) .......................................................................................... 16
4.2.1.1.3 MO-Wait for CP-ACK (State 2) ..................................................................................................... 16
4.2.1.1.4 MO-MM-connection established (State 3) ..................................................................................... 16
4.2.1.2 Mobile Terminating case ...................................................................................................................... 17
4.2.1.2.1 MT-Idle (State 0) ............................................................................................................................ 17
 3 TSM 04.11 V1.0.0 (2000-12)

4.2.1.2.2 MT-Wait for CP-ACK (State 2) ..................................................................................................... 17

4.2.1.2.3 MT-MM-connection established (State 3) ...................................................................................... 17
4.2.2 SMC-GP states at the UE side of the radio interface ................................................................................. 17
4.2.2.1 Mobile Originating Case ...................................................................................................................... 17
4.2.2.1.1 MO-Idle (State 0) ............................................................................................................................ 17
4.2.2.1.2 MO-Wait for CP-ACK (State 1) ..................................................................................................... 17
4.2.2.1.3 MO-Wait for CP-Data (State 2) ...................................................................................................... 17
4.2.2.2 Mobile Terminating case ...................................................................................................................... 17
4.2.2.2.1 MT-Idle (State 0) ............................................................................................................................ 17
4.2.2.2.2 MT-Wait for RP-ACK (State 1) ..................................................................................................... 18
4.2.2.2.3 MT-Wait for CP-ACK (State 2) ..................................................................................................... 18
4.2.3 SMC-CS states at the network side of the radio interface .......................................................................... 18
4.2.3.1 Mobile Originating Case ...................................................................................................................... 18
4.2.3.1.1 MO-Idle (State 0) ............................................................................................................................ 18
4.2.3.1.2 MO-Wait for CP-ACK (State 2) ..................................................................................................... 18
4.2.3.1.3 MO-MM-connection established (State 3) ..................................................................................... 18
4.2.3.2 Mobile Terminating Case ..................................................................................................................... 18
4.2.3.2.1 MT-Idle (State 0) ............................................................................................................................ 18
4.2.3.2.2 MT-MM-connection pending (State 1) ........................................................................................... 18
4.2.3.2.3 MT-Wait for CP-ACK (State 2) ..................................................................................................... 18
4.2.3.2.4 MT-MM-connection established (State 3) ...................................................................................... 19
4.2.4 SMC-GP states at the network side of the radio interface ......................................................................... 19
4.2.4.1 Mobile Originating Case ...................................................................................................................... 19
4.2.4.1.1 MO-Idle (State 0) ............................................................................................................................ 19
4.2.4.1.2 MO-Wait for RP-ACK (State 1) ..................................................................................................... 19
4.2.4.1.3 MO-Wait for CP-ACK(State 2) ...................................................................................................... 19
4.2.4.2 Mobile Terminating Case ..................................................................................................................... 19
4.2.4.2.1 MT-Idle (State 0) ............................................................................................................................ 19
4.2.4.2.2 MT-Wait for CP-ACK (State 1) ..................................................................................................... 19
4.2.4.2.3 MT-Wait for CP DATA (State 2) ................................................................................................... 19
4.3 Short Message Control procedures .................................................................................................................. 20
4.3.1 MM-connection establishment for circuit switched mode ......................................................................... 20
4.3.2.1 RPDU transfer for circuit switched mode ........................................................................................... 20
4.3.2.2 RPDU transfer for packet switched mode ............................................................................................ 21
4.3.3 Release of MM and CM connections ......................................................................................................... 21
4.3.4 Abnormal cases .......................................................................................................................................... 21
4.4 Concatenating short message or notification transfers .................................................................................... 22
5 SM-RL-procedures ................................................................................................................................. 23
5.1 General............................................................................................................................................................. 23
5.2 Transition states of SMR entity ....................................................................................................................... 23
5.2.1 SMR-states at the UE-side of the radio interface ....................................................................................... 23
5.2.1.1 Idle (State 0) ......................................................................................................................................... 23
5.2.1.2 Wait for RP-ACK (State 1) .................................................................................................................. 23
5.2.1.3 Wait for RETRANS TIMER (State 4) ................................................................................................. 23
5.2.2 SMR-states at the network side of the radio interface................................................................................ 23
5.2.2.1 Idle (State 0) ......................................................................................................................................... 23
5.2.2.2 Wait for RP-ACK (State 1) .................................................................................................................. 23
5.2.2.3 Wait to send RP-ACK (State 3)............................................................................................................ 24
5.3 Short Message Relay procedures ..................................................................................................................... 24
5.3.1 TPDU relaying ........................................................................................................................................... 24
5.3.2 Notification relaying .................................................................................................................................. 24
5.3.2.1 UE side ................................................................................................................................................. 24
5.3.2.1.1 Idle state .......................................................................................................................................... 24
5.3.2.1.2 Wait for RP-ACK state ................................................................................................................... 25
5.3.2.1.3 Wait for RETRANS Timer state ..................................................................................................... 25
5.3.2.2 Network side......................................................................................................................................... 25
5.3.2.2.1 Idle state .......................................................................................................................................... 25
5.3.2.2.2 Wait to Send RP-ACK state............................................................................................................ 25
5.3.3 Abnormal cases .......................................................................................................................................... 26
 4 TSM 04.11 V1.0.0 (2000-12)

6 Message functional definitions and content ........................................................................................... 26

6.1 General............................................................................................................................................................. 26
6.2 Messages for short message or notification transfer on CM............................................................................ 26
6.2.1 CP-DATA .................................................................................................................................................. 26
6.2.2 CP-ACK ..................................................................................................................................................... 26
6.2.3 CP-ERROR ................................................................................................................................................ 27
6.3 Messages for short message and notification transfer on SM-RL ................................................................... 27
6.3.1 RP-DATA .................................................................................................................................................. 27
6.3.1.1 RP-DATA (Network to User Equipment) ............................................................................................ 27
6.3.1.2 RP-DATA (User Equipment to Network) ............................................................................................ 27
6.3.2 RP-SMMA ................................................................................................................................................. 28
6.3.3 RP-ACK ..................................................................................................................................................... 28
6.3.4 RP-ERROR ................................................................................................................................................ 28
7 Message format and information elements coding ................................................................................. 29
7.1 CP-messages .................................................................................................................................................... 29
7.1.1 General ....................................................................................................................................................... 29
7.1.2 Protocol Discriminator and Transaction Identifier..................................................................................... 29
7.1.3 Message type .............................................................................................................................................. 29
7.1.4 Other required information elements ......................................................................................................... 29
7.1.4.1 CP-User data element ........................................................................................................................... 29
7.1.4.2 CP-Cause element ................................................................................................................................ 30
7.2 RP-messages .................................................................................................................................................... 30
7.2.1 General ....................................................................................................................................................... 30
7.2.2 Message type indicator (MTI) .................................................................................................................... 31
7.2.3 Message reference ...................................................................................................................................... 31
7.2.4 Other required information elements ......................................................................................................... 31
7.2.4.1 Originator address element ................................................................................................................... 31
7.2.4.2 Destination address element ................................................................................................................. 32
7.2.4.3 RP-User data element ........................................................................................................................... 32
7.2.4.4 RP-Cause element ................................................................................................................................ 33
8 Handling of unknown, unforeseen, and erroneous protocol data ........................................................... 35
8.1 General............................................................................................................................................................. 35
8.2 CP Error Handling ........................................................................................................................................... 35
8.2.1 Message too short....................................................................................................................................... 36
8.2.2 Unknown or unforeseen transaction identifier ........................................................................................... 36
8.2.3 Unknown or unforeseen message type ....................................................................................................... 36
8.2.4 Non-semantical mandatory information element errors ............................................................................. 36
8.2.5 Messages with semantically incorrect contents.......................................................................................... 37
8.3 RP Error Handling ........................................................................................................................................... 37
8.3.1 Message too short....................................................................................................................................... 37
8.3.2 Unknown or unforeseen Message Reference ............................................................................................. 37
8.3.3 Unknown or unforeseen message type ....................................................................................................... 37
8.3.4 Non-semantical mandatory information element errors ............................................................................. 38
8.3.5 Messages with semantically incorrect contents.......................................................................................... 38
 5 TSM 04.11 V1.0.0 (2000-12)

11 Timers .................................................................................................................................................... 38
Annex A (informative): Arrow diagrams ..................................................................................................... 39
Annex B (normative): SDL-description of the CM-layer ............................................................................ 42
B.1 Introduction ............................................................................................................................................ 42

Annex C (informative): Arrow diagrams ..................................................................................................... 54

Annex D (normative): SDL-description of the short message relay layer ................................................. 60
D.1 Introduction ............................................................................................................................................ 60
Annex E (informative): Cause definition ...................................................................................................... 68
Annex F (informative): LAPDm SAPI 3 handling for short message service ........................................... 73
Annex G (informative): History .................................................................................................................... 80
 6 TSM 04.11 V1.0.0 (2000-12)

Intellectual Property Rights

Foreword
This Technical Specification (TS) defines the Short Message Service (SMS) support on mobile radio interface within
the TD-SCDMA telecommunications system.

The contents of this Technical Specification (TS) are subject to continuing work within CWTS WG2. it will be re-
released by CWTS with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x indicates the TSM Release;

y the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections,
updates, etc.;

z the third digit is incremented when editorial only changes have been incorporated in the specification.

Proposed national transposition dates

Date of latest announcement of this TS (doa): xx months after CWTS publication

Date of latest publication of new National Standard xx months after doa

or endorsement of this TS (dop/e):

Date of withdrawal of any conflicting National Standard (dow): xx months after doa

1 Scope
This Technical Specification (TS) specifies the procedures used across the mobile radio interface by the signalling layer
3 function Short Message Control (SMC) and Short Message Relay function (SM-RL) for both circuit switched and
packet switched modes.

1.1 Normative references

The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or non
specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies.

- A non-specific reference to a TS shall also be taken to refer to later versions published as TS with the same
number.
 7 TSM 04.11 V1.0.0 (2000-12)

- For this Release document, references to TSM documents are for Release versions (version x.y.z);
references to GSM documents are for Release 1997 versions (version 6.x.y).

[1] TSM 01.04: "China Wireless Telecommunication Standard; 3G digital cellular

telecommunications system; TD-SCDMA System for Mobile(TSM); Abbreviations and
acronyms".

[2] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the
Short Message Service (SMS) Point-to-Point (PP)".

[3a] TSM 03.60: "China Wireless Telecommunication Standard; 3G digital cellular

telecommunications system; General Packet Radio Service; Service description".

[3] TSM 04.06: "China Wireless Telecommunication Standard; 3G digital cellular

telecommunications system; User Equipment - Base Station System (UE - BSS) interface Data
Link (DL) layer specification".

[4] GSM 04.07: " 3G digital cellular telecommunications system; Mobile radio interface signalling
layer 3; General aspects".

[5] TSM 04.08: "China Wireless Telecommunication Standard; 3G digital cellular

telecommunications system; Mobile radio interface layer 3 specification".

[6a] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio
Service (GPRS); Logical Link Control (LLC)".

[6] ISO 7498: "Information processing systems - Open Systems Interconnection - Basic Reference
Model".

1.2 Abbreviations
Abbreviations used in this TS are listed in TSM 01.04.

2 Overview of Short Message Service (SMS) support

The purpose of the Short Message Service is to provide the means to transfer messages between a TD-SCDMA User
Equipment (UE) and a Short Message Entity via a Service Centre, as described in GSM 03.40. The terms
"MO" - Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the direction in which the short
message is sent.

This TS (Technical Specification) describes the procedures necessary to support the Short Message Service between the
UE and the MSC or SGSN and vice versa, as described in GSM 03.40.

The procedures are based on services provided by the Mobility Management sublayer as described in
TSM 04.07/04.08 for circuit switched services and the Logical Link Control layer described in TSM 04.64 for packet
switched services.

2.1 Protocols and protocol architecture

The hierarchical model in Figure 2.1a shows the layer structure of the MSC and the UE.

MSC UE

SM-AL
SM-TL
SM-RL SMR <⎯⎯⎯⎯⎯⎯ SM-RP protocol ⎯⎯⎯⎯⎯> SMR
CM-sublayer SMC <⎯⎯⎯⎯⎯⎯ SM-CP protocol ⎯⎯⎯⎯⎯> SMC
MM-sublayer
 8 TSM 04.11 V1.0.0 (2000-12)

RR-sublayer

Figure 2.1a/TSM 04.11: Protocol hierarchy for circuit switched service

The hierarchical model in Figure 2.1b shows the layer structure of the SGSN and the UE.

SGSN UE

SM-AL
SM-TL
SM-RL SMR <⎯⎯⎯⎯⎯⎯ SM-RP protocol ⎯⎯⎯⎯⎯> SMR
CM-sublayer SMC <⎯⎯⎯⎯⎯⎯ SM-CP protocol ⎯⎯⎯⎯⎯> SMC
LLC-sublayer
GRR-sublayer

Figure 2.1b/TSM 04.11: Protocol hierarchy for packet switched service

The CM-sublayer, in terms of the Short Message Service Support, provides services to the Short Message Relay Layer.

On the UE-side the Short Message Relay Layer provides services to the Short Message Transfer Layer. The Short
Message Relay Layer is the upper layer on the network side (MSC or SGSN), and the SM-user information elements
are mapped to TCAP/MAP.

The peer protocol between two SMC entities is denoted SM-CP, and between two SMR entities, SM-RP.

Abbreviations:

SM-AL Short Message Application Layer

SM-TL Short Message Transfer Layer
SM-RL Short Message Relay Layer
SM-RP Short Message Relay Protocol
SMR Short Message Relay (entity)
CM-sub Connection Management sublayer
SM-CP Short Message Control Protocol
SMC Short Message Control (entity)
MM-sub: Mobility Management sublayer
RR-sub: Radio Resource Management sublayer
LLC-sub Logical Link Control sublayer
GRR-sub Packet switched service Radio Resource sublayer

2.2 Use of channels

Table 2.1/TSM 04.11 summarizes the use of channels for the short message service for circuit switched mode. Arrows
indicate changes of channel.

Table 2.1/TSM 04.11: Channels used for short message transfer over circuit switched services

Channel dependency Channel used

TCH not allocated SDCCH; FACCH
TCH not allocated -> TCH allocated SDCCH; FACCH -> SACCH
TCH allocated SACCH,
TCH allocated -> TCH not allocated SACCH -> FACCH; SDCCH

The short message service for packet switched mode shall be supported by a PDTCH.
 9 TSM 04.11 V1.0.0 (2000-12)

2.3 Layer 2 SAPI 3 handling for circuit switched TD-SCDMA

General rule:

The Radio Resource Management (RR reference TSM 04.08) in the User Equipment and on the network side (i.e. in
the BSC) shall establish the acknowledged mode of operation on SAPI 3 whenever needed, i.e. when a message
requiring SAPI 3 transfer shall be transmitted.

RR shall control the layer 2 also for SAPI 3, and keep knowledge of the mode.

The network side may initiate release of the acknowledged mode for SAPI 3 either explicitly (by the use of DISC- and
UA-frames, see TSM 04.06) or indirectly by channel release (see TSM 04.08).

This means:

- the User Equipment side will initiate establishment of SAPI 3 acknowledged mode in the case of mobile
originating short message transfer;

- the network side will initiate establishment of SAPI 3 acknowledged mode in the case of mobile terminating
short message transfer;

- the network side may choose to keep the channel and the acknowledged mode of operation to facilitate transfer
of several short messages for or from the same User Equipment. The queuing and scheduling function for this
should reside in the MSC.

2.4 Layer 2 (LLC) packet switched TD-SCDMA support

It shall be possible for a packet switched mode-attached UE of any class (A, B, C) to send and receive short messages
over packet switched radio channels.

Packet switched mode shall use the unacknowledged mode of LLC frame transfer as described in GSM04.64, and shall
use SAPI 7 to identify the SMS Logical Link Entity within the LLC layer.

A description of the different packet switched mode UE classes can be found in TSM 03.60, and a brief overview is
given below:-

- Class A/B UEs may be able to send and receive short messages using either the MM sublayer (using SACCH,
FACCH or SDCCH) or the LLC layer (using PDTCH).

- Class C UEs may be able to send and receive short messages using only the LLC layer (using the PDTCH). The
capability for packet switched mode -attached class-C UEs to receive and transmit SMS messages is optional.

The GSMS entity for packet switched mode class A/B UE is shown in Figure 3. The GSMS shall communicate with
the MM entity via the GMMSMS-SAP for packet switched mode Class A/B MO SMS, in order to ascertain which
transport service to use.

SMS delivery via packet switched mode is normally a more radio resource efficient method than SMS delivery via
CS, i.e. circuit switched mode. The delivery path for MO SMS is selected by the UE.
 10 TSM 04.11 V1.0.0 (2000-12)

MNSMS-SAP

SMSMM

SMC-GP SMC-CS

LLSMS-SAP MMSMS-SAP

GMMSMS-SAP

Figure 3/TSM 04.11: GSMS entity for packet switched mode Class A/B UE

3 Service definition

3.1 General
The layer service is described as a set of service primitives. These service primitives are abstractions and attempt to
capture only those details of the interaction between the entities that are aspects of the layer service itself. A service
primitive neither specifies nor constrains the implementation of entities or the interface between them.

The general syntax of a primitive and the initials of them are in line with the 04-series of TSM and GSM Technical
Specifications.

NOTE: In order to limit the number of primitives and state definitions to a reasonable amount, a description
method has been chosen which does not claim to be totally in line with the formal description method of
the layered ISO reference model (ISO 7498) for Open Systems Interconnection.

3.2 Service provided by the CM-sublayer

In order to support the Short Message Service, the CM-sublayer provides services to the Short Message Relay Layer.

The CM-sublayer services are provided using layer specific functions and lower layer services offered to the
CM-sublayer, controlled by short message service control entities called SMCs.

An SMC entity in the UE communicates with an SMC entity in the MSC or SGSN by means of a peer protocol, SM-CP
(Short Message Service Control Protocol). The arrow diagrams in annex A give an overview of the messaging on the
CM-sublayer during a short message transfer.

A User Equipment supporting the Short Message Service shall have a minimum of two SMC entities per service type
(i.e. two for CS (Circuit Switched mode) and two for PS (Packet Switched mode)). This enables the UE to receive MT
messages during an MO message transfer.

To ensure that an UE having the minimum of two SMC entities is able to receive MT messages during an MO message
transfer, and to send MO messages during MT message transfer, parallel message transfer in the same direction is
prohibited. This means that the SMC entities shall not simultaneously perform messaging in the same direction. The
rules for concatenation of message transfers are described in subclause 5.4.

The MSC or SGSN shall have a minimum of two SMC entities available each during an MT message transfer to a user
equipment, one being reserved for MO message transfer. In an MO message transfer, the MSC or SGSN shall have one
SMC entity reserved for handling of an MT message.
 11 TSM 04.11 V1.0.0 (2000-12)

3.2.1 Definition of primitives on the UE side

This subclause defines the service primitives used on the UE side. Table 3.1/TSM 04.11 gives an overview of the
service primitives and main parameter linked to the primitives. All necessary control parameters to be used in the Short
Message Service are defined in clause 7. All MNSMS service primitives defined in this subclause are passed to an
SMC-entity.

Table 3.1/TSM 04.11: MNSMS service primitives on the UE-side

SERVICE PRIMITIVES PARAMETER

NAME TYPE
MNSMS-ABORT- Req Cause
MNSMS-DATA Req MT RPDU
Ind MO RPDU
MNSMS-EST- Req MO RPDU
Ind MT RPDU
MNSMS-ERROR- Ind Cause
MNSMS-REL- Req Cause

3.2.1.1 MNSMS-ABORT-REQuest
A request from an SMR entity to release a CM-connection in abnormal cases.

When the CM-sublayer receives this request, and if the MM connection exists, it shall form and send the CP-ERROR
message. Irrespective of whether or not the CP-ERROR message was sent, the CM-sublayer shall then release the lower
layer services.

3.2.1.2 MNSMS-DATA-REQuest
A request from an SMR entity to send a RPDU on the established CM-connection.

The SMC entity forms the CP-DATA message, the user information element being the RPDU, and transfers the
message by means of the lower layer services.

NOTE: After reception of an incoming RP-DATA, the SMR entity typically returns the acknowledgement
RP-ACK, or an error indication, RP-ERROR, to the Service Centre.

3.2.1.3 MNSMS-DATA-INDication
An indication used by the SMC entity to pass the user information element (RPDU) of a received CP-DATA message
to SM-RL.

NOTE: The RPDU is typically an RP-ACK or an RP-ERROR. Normally this service is used to report the
outcome of either a MO message transfer attempt or a mobile station memory available notification
attempt.
 12 TSM 04.11 V1.0.0 (2000-12)

3.2.1.4 MNSMS-ESTablish-REQuest
A request from an SMR entity to establish a CM-connection. The request contains a RP-DATA UNIT as a parameter. It
implies the:

- establishment of a CM-connection for this SMR entity;

- forming of the CP-DATA message containing the RPDU; and

- passing of CP-DATA to the MM-sublayer.

3.2.1.5 MNSMS-ESTablish-INDication
An indication used by the SMC entity to pass the SM-user information (RPDU) of a received CP-DATA message to
SM-RL. It implies completion of the establishment of the CM-connection for this SMR entity.

3.2.1.6 MNSMS-ERROR-INDication
An indication used by the SMC entity to pass error information to SM-RL. The error information may be local or
relayed by the CP-ERROR message.

Use of this service primitive implies release of both CM and MM-connection.

3.2.1.7 MNSMS-RELease-REQuest
A request to release the CM-connection (if it still exists).

Use of this service primitive implies release of the associated CM and MM-connections.

3.2.2 Definition of primitives on the network side

This subclause defines the service primitives used on the network side.

Table 3.2/TSM 04.11 gives an overview of the service primitives and linked main parameter. All MNSMS service
primitives defined in this subclause are passed to an SMC-entity.

Table 3.2/TSM 04.11: MNSMS service primitives on the network side

SERVICE PRIMITIVES PARAMETER

NAME TYPE
MNSMS-ABORT- Req Cause
MNSMS-DATA Req MO RPDU
Ind MT RPDU
MNSMS-EST- Req MT RPDU
Ind MO RPDU
MNSMS-ERROR- Ind Cause
MNSMS-REL- Req Cause

3.2.2.1 MNSMS-ABORT-REQuest
A request from an SMR entity to release a CM-connection in abnormal cases.

When the CM-sublayer receives this request, it may form and send the CP-ERROR message to release the connection.
Irrespective of whether or not the CP-ERROR message was sent, the CM-sublayer shall then release the lower layer
services.
 13 TSM 04.11 V1.0.0 (2000-12)

3.2.2.2 MNSMS-DATA-REQuest
A request from an SMR entity to send a RPDU on the established CM-connection.

The SMC entity forms the CP-DATA message, the user information element being the RPDU, and transfers the
message by means of the lower layer services.

NOTE: After reception of an incoming RP-DATA or RP-SMMA the RPDU typically returns the
acknowledgement, RP-ACK, or an error indication RP-ERROR, to the User Equipment.

3.2.2.3 MNSMS-DATA-INDication
An indication used by the SMC entity to pass the user information element (RPDU) of a received CP-DATA message
to SM-RL.

NOTE: The RPDU is typically an RP-ACK or an RP-ERROR. Normally this is used to report the outcome of a
MT messaging attempt.

3.2.2.4 MNSMS-ESTablish-REQuest
A request from an SMR entity to transmit a RPDU, containing the SM-user information element; it implies the:

- establishment of a CM-connection for this SMR entity;

- forming of the CP-DATA message containing the RPDU; and

- passing of CP-DATA to the MM-sublayer.

3.2.2.5 MNSMS-ESTablish-INDication
An indication used by the SMC entity to pass the SM-user information (RPDU) of a received CP-DATA message to
SM-RL; it implies completion of the establishment of the CM-connection for this SMR entity.

3.2.2.6 MNSMS-ERROR-INDication
An indication used by the SMC entity to pass error information to SM-RL. The error information may be local or
relayed by the CP-ERROR message.

Use of the service primitive implies release of both CM and MM-connection.

3.2.2.7 MNSMS-RELease-REQuest
A request to release the CM-connection (if it still exists).

Use of this service implies release of the associated CM and MM-connections.

3.3 Service provided by SM-RL

In order to support the Short Message Service, the Short Message Relay Layer provides services to the Short Message
Transfer Layer.

The Short Message Relay Layer services are provided using layer specific functions and lower layer services offered to
the Short Message Relay Layer, controlled by short message control entities called SMRs.

An SMR entity in the UE communicates with an SMR entity in the MSC by means of a peer protocol, SM-RP (Short
Message Relay Protocol). The arrow diagrams in annex C give an overview of the messaging on the Short Message
Relay Layer used for the Short Message Service. The diagrams in annex C indicate a layer RL. This is not a layer, but
the functional interface to the fixed network. The SM-RL is the upper layer in the MSC. Consequently the service
primitives passed between SM-RL and RL indicate the interworking function.
 14 TSM 04.11 V1.0.0 (2000-12)

The requirements on the SM-RL are the same as for the CM-sublayer. This means that there is exactly one SMR entity
for each SMC entity, operating as described in subclause 3.2.

3.3.1 Definition of primitives on the UE side

This subclause defines the service primitives used on the UE side. Table 3.3/TSM 04.11 gives an overview of the
service primitives and linked main parameters. All SM-RL service primitives defined in this subclause are passed on an
SM-RL-connection.

Table 3.3/TSM 04.11: SM-RL service primitives on the user equipment side

SERVICE PRIMITIVES PARAMETER

NAME TYPE
SM-RL-DATA- Req MO SMS-TPDU
Ind MT SMS-TPDU
SM-RL-MEMORY Req See subclause 3.3.1.3
AVAILABLE
SM-RL-REPORT- Req See subclause 3.3.1.4
Ind See subclause 3.3.1.5

3.3.1.1 SM-RL-DATA-REQuest
A request from the SM-TL entity to pass the SMS-TPDU and necessary control information to SM-RL; it implies:

- establishment of an SM-RL connection for MO message transfer;

- forming of the RP-DATA message, containing the SMS-TPDU;

- transfer of the RP-DATA message as an RPDU in an MNSMS-EST-Req.

The purpose of this service is to relay the SMS-TPDU from the user equipment to the peer entity in the MSC.

3.3.1.2 SM-RL-DATA-INDication
An indication used by the SMR entity to pass the SMS-TPDU and necessary control information of a received
RP-DATA message to SM-TL.

3.3.1.3 SM-RL-MEMORY-AVAILABLE-REQuest
When received without a parameter, this is a request from the SM-TL entity to pass the necessary control information
to SM-RL; it implies:

- establishment of an SM-RL-connection for transfer of the notification to the network that the mobile has
memory available to receive one or more short messages;

- forming the RP-SM-MEMORY-AVAILABLE message; and

- transfer of the RP-SM-MEMORY-AVAILABLE message as an RPDU in an MNSMS-EST-Req.

 15 TSM 04.11 V1.0.0 (2000-12)

The SM-TL entity may abort the transmission of an RP-SM-MEMORY-AVAILABLE message by use of a
SM-RL-MEMORY-AVAILABLE-REQuest with the added parameter, SMS-MEM-NOTIF-ABORT, being present.
This parameter is, of course, defined only on the interface between the SM-TL and SMR entities within the user
equipment. Use of this request with the added parameter will have no effect on messages already given to the lower
layers for transmission, but will only abort retransmission of the RP-SM-MEMORY-AVAILABLE message by the
SMR entity.

3.3.1.4 SM-RL-REPORT-REQest
A request used by the SM-TL to relay the RP-ACK or RP-ERROR message from the user equipment to the network.
This implies transfer of the RP-ACK or RP-ERROR message as an RPDU in an MNSMS-DATA-Req.

3.3.1.5 SM-RL-REPORT-INDication
An indication used by the SMR entity to pass an acknowledgement (RP-ACK) or error information to SM-TL. The
error information may be local or relayed by the RP-ERROR message; it consists of an appropriate cause and
optionally extended diagnostic information.

3.3.2 Definition of primitives on the network side

This subclause defines the service primitives used on the network side.

Table 3.4/TSM 04.11 gives an overview of the service primitives and linked main parameter. All SM-RL service
primitives defined in this subclause are passed on an SM-RL-connection.

Table 3.4/TSM 04.11: SM-RL service primitives on the network side

SERVICE PRIMITIVES PARAMETER

NAME TYPE
SM-RL-DATA- Req MT SMS-TPDU
Ind MO SMS-TPDU
SM-RL-MEMORY Ind None
AVAILABLE
SM-RL-REPORT- Req See subclause 3.3.2.4
Ind See subclause 3.3.2.5

3.3.2.1 SM-RL-DATA-REQuest
A request from RL to pass the SMS-TPDU to SM-RL; it implies:

- establishment of a SM-RL-connection for MT message transfer;

- forming of the RP-DATA message, containing the SMS-TPDU; and

- transfer of the RP-DATA message as an RPDU in an MNSMS-EST-Req.

The purpose of this service is to relay the SMS-TPDU from the MSC to the peer entity in the user equipment.

3.3.2.2 SM-RL-DATA-INDication
An indication used by the SMR entity to pass the SMS-TPDU of a received RP-DATA message to RL.

3.3.2.3 SM-RL-MEMORY-AVAILABLE-INDication
An indication used by the SMR entity to pass to RL the notification to the network that the mobile has memory
available to receive one or more short messages.
 16 TSM 04.11 V1.0.0 (2000-12)

3.3.2.4 SM-RL-REPORT-REQuest
A request used by RL (the network interworking function) to relay the RP-ACK or RP-ERROR message from the
network to the user equipment. This implies transfer of the RP-ACK or RP-ERROR message as an RPDU in an
MNSMS-DATA-Req.

3.3.2.5 SM-RL-REPORT-INDication
An indication used by the SMR entity to pass an acknowledgement (RP-ACK) or error information to RL. The error
information may be local or relayed by the RP-ERROR message.

4 CM-procedures

4.1 General
This clause describes the procedures used by the SMC entity on the Connection Management sublayer. An SMC entity
communicates with a corresponding peer entity using an MM-connection for circuit switched mode or the LLC layer
for packet switched mode.

Multiple MM-connections may be established at the same time, allowing parallel transactions. The description of the
procedures is related to one single transaction.

For circuit switched mode, the CM-procedures described can only be performed if an MM-connection has been
established between the user equipment and the network. For packet switched mode, no MM-connection has to be
established, and thus the CM procedures for packet switched mode reflect this. Detailed SDL diagrams for SMC
entities are contained in annex B.

4.2 Short Message Control states

The state transition diagrams for the MO and MT SMC entities on both the UE side and network side are contained in
annex B.

4.2.1 SMC-CS states at the UE side of the radio interface

4.2.1.1 Mobile Originating Case

The states described in this clause are for an SMC entity in an UE handling mobile originating short message transfer
and notification to the network that the mobile has memory available to receive one or more short messages (referred to
below as "notification").

4.2.1.1.1 MO-Idle (State 0)

This state exists when the MO-SMC entity is in idle mode, or when an MO short message transfer or notification ends
in a normal or abnormal way.

4.2.1.1.2 MO-MM-connection pending (State 1)

This state exists when the MO-SMC has requested the establishment of an MM-connection.

4.2.1.1.3 MO-Wait for CP-ACK (State 2)

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message.

4.2.1.1.4 MO-MM-connection established (State 3)

This state exists when the MO-SMC has:
 17 TSM 04.11 V1.0.0 (2000-12)

- received the acknowledgement, CP-ACK; or

- received the message CP-DATA (including sending of the associated CP-ACK).

4.2.1.2 Mobile Terminating case

The states described in this subclause are for an SMC entity in an UE handling mobile terminating short message
transfer.

4.2.1.2.1 MT-Idle (State 0)

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or
abnormal way.

4.2.1.2.2 MT-Wait for CP-ACK (State 2)

This state exists after the MT-SMC has initiated the transfer of a CP-DATA message.

4.2.1.2.3 MT-MM-connection established (State 3)

This state exists when the MT-SMC has:

- received the acknowledgement, CP-ACK; or

- received the message CP-DATA (including sending of the associated CP-ACK).

4.2.2 SMC-GP states at the UE side of the radio interface

4.2.2.1 Mobile Originating Case

The states described in this clause are for an SMC-GP entity in a packet switched mode UE handling mobile
originating short message transfer and notification to the network that the mobile has memory available to receive one
or more short messages (referred to below as "notification").

4.2.2.1.1 MO-Idle (State 0)

This state exists when the MO-SMC entity is in idle mode, or when an MO short message transfer or notification ends
in a normal or abnormal way.

4.2.2.1.2 MO-Wait for CP-ACK (State 1)

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message.

4.2.2.1.3 MO-Wait for CP-Data (State 2)

This state exists when the MO-SMC has received the acknowledgement, CP-ACK.

4.2.2.2 Mobile Terminating case

The states described in this subclause are for an SMC-GP entity in a packet switched mode UE handling mobile
terminating short message transfer.

4.2.2.2.1 MT-Idle (State 0)

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or
abnormal way.
 18 TSM 04.11 V1.0.0 (2000-12)

4.2.2.2.2 MT-Wait for RP-ACK (State 1)

This state exists after the MT-SMC has received the message CP-DATA (including sending of the associated CP-ACK)

4.2.2.2.3 MT-Wait for CP-ACK (State 2)

This state exists when the MT-SMC has initiated the transfer of the CP DATA message.

4.2.3 SMC-CS states at the network side of the radio interface

4.2.3.1 Mobile Originating Case

The states described in this subclause are for an SMC entity in an MSC handling both mobile originating short message
transfer and notification to the network that the mobile has memory available to receive one or more short messages
(referred to below as "notification").

4.2.3.1.1 MO-Idle (State 0)

This state exists when the MO-SMC entity is in idle mode, or when a short message transfer or notification ends in a
normal or abnormal way.

4.2.3.1.2 MO-Wait for CP-ACK (State 2)

This state exists after the MO-SMC has initiated the transfer of a CP-DATA message.

4.2.3.1.3 MO-MM-connection established (State 3)

This state exists when the SMC has:

- received the acknowledgement, CP-ACK; or

- received the message CP-DATA (including sending of the associated CP-ACK).

4.2.3.2 Mobile Terminating Case

The states described in this subclause are for an SMC entity in an MSC handling mobile terminating short message
transfer.

4.2.3.2.1 MT-Idle (State 0)

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or
abnormal way.

4.2.3.2.2 MT-MM-connection pending (State 1)

This state exists when the MT-SMC has requested an MM-connection for mobile terminating short message transfer.

4.2.3.2.3 MT-Wait for CP-ACK (State 2)

This state exists after the SMC has initiated the transfer of a CP-DATA message.
 19 TSM 04.11 V1.0.0 (2000-12)

4.2.3.2.4 MT-MM-connection established (State 3)

This state exists when the SMC has:

- received the acknowledgement, CP-ACK; or

- received the message CP-DATA (including sending of the associated CP-ACK).

4.2.4 SMC-GP states at the network side of the radio interface

4.2.4.1 Mobile Originating Case

The states described in this subclause are for an SMC-GP entity in an SGSN handling both mobile originating short
message transfer and notification to the network that the mobile has memory available to receive one or more short
messages (referred to below as "notification").

4.2.4.1.1 MO-Idle (State 0)

This state exists when the MO-SMC entity is in idle mode, or when a short message transfer or notification ends in a
normal or abnormal way.

4.2.4.1.2 MO-Wait for RP-ACK (State 1)

This state exists after the MO-SMC has received the message CP-DATA (including sending of the associated
CP-ACK).

4.2.4.1.3 MO-Wait for CP-ACK(State 2)

This state exists when the SMC has received the RP acknowledgement, RP-ACK

4.2.4.2 Mobile Terminating Case

The states described in this subclause are for an SMC-GP entity in an SGSN handling mobile terminating short
message transfer.

4.2.4.2.1 MT-Idle (State 0)

This state exists when the MT-SMC entity is in idle mode, or when a short message transfer ends in a normal or
abnormal way.

4.2.4.2.2 MT-Wait for CP-ACK (State 1)

This state exists after the SMC has initiated the transfer of a CP-DATA message.

4.2.4.2.3 MT-Wait for CP DATA (State 2)

This state exists when the SMC has received the acknowledgement, CP-ACK.
 20 TSM 04.11 V1.0.0 (2000-12)

4.3 Short Message Control procedures

The procedures needed for short message control are:

- connection establishment procedures;

- RP Data Unit (RPDU) transfer procedures;

- connection release procedures; and

- procedures for abnormal cases.

The procedures of subclause 4.3 are described with respect to one particular instance of an SMC entity. Different SMC
entities are identified by their Transaction Identifier. Messages with Transaction Identifiers that do not correspond to
this particular instance of the SMC entity are not treated by it.

4.3.1 MM-connection establishment for circuit switched mode

When an SMC entity is in the Idle state and transfer of an RPDU is requested, the peer to peer connection between the
MM-sublayers in the UE and the network (MSC) has to be established.

The SMC entity on the originating side requests the MM-sublayer to establish an MM-connection, and enters the
MM-Connection Pending state.

After completion of the MM-connection establishment, a confirmation is given to the originating side to indicate that
the MM sublayer is ready for RPDU transfer.

The MM-connection establishment is indicated to the SMC entity at the destination side when the CP-DATA message
has been received by the MM-sublayer (in line with TSM 04.08). The destination side SMC entity then sends a
CP-ACK and enters the MM-Connection Established state.

4.3.2.1 RPDU transfer for circuit switched mode

When an SMC entity in the MM-Connection Pending state is informed that an MM-connection has been established,
the SMC entity forwards the CP-DATA message containing the RPDU, sets the timer TC1* and enters the Wait for
CP-ACK state.

The value of TC1* may vary with the length of the CP-DATA message and the channel type that is being used for its
transmission. However, the value of TC1* shall be sufficiently great to allow the lower layers to transmit the
CP-DATA and CP-ACK messages and to allow for some retransmissions of layer 2 frames.

If an SMC entity in the Wait for CP-ACK state gets an indication that the CP-DATA message has probably been lost
(e.g. due to dedicated channel assignment, handover, assignment failure, handover failure, or a SAPI 3 data link failure)
then, as an implementation option, that SMC entity may reduce the time until expiry of TC1*.

If the timer TC1* expires in the Wait for CP-ACK state, the CP-DATA message is retransmitted and the state Wait for
CP-ACK is re-entered. The maximum number of CP-DATA message retransmissions is an implementation option but
shall be either 1, 2 or 3. If the timer TC1* expires after the maximum number of retransmission attempts, an error
indication is passed to SM-RL and an MM-connection release request is passed to the MM-sublayer. The Idle state is
then entered.

On receipt of the CP-ACK message in the Wait for CP-ACK state, the SMC resets the timer TC1* and enters the
MM-Connection Established state.

When receiving a CP-DATA message in the MM-Connection Established state, the SMC entity checks the parameters
relevant to the CP protocol. If these are valid, the RPDU is passed to the SM-RL, the CP-ACK message is sent and the
state MM-Connection Established is re-entered.

If an SMC entity in the Idle state is unable to accept a CP-DATA message, it sends a CP-ERROR message followed by
an MM-connection release request and then enters the Idle state.
 21 TSM 04.11 V1.0.0 (2000-12)

When receiving a MNSMS-DATA-Req primitive in the MM-Connection Established state, the SMC entity forwards a
CP-DATA message containing the RPDU to the MM-sublayer, sets the timer TC1* and enters the Wait for CP-ACK
state.

4.3.2.2 RPDU transfer for packet switched mode

When an SMC-GP entity is in the Idle state and transfer of an RPDU is requested, the SMC-GP entity on the
originating side forwards the CP-DATA message to the LLC sublayer. This contains the RPDU, and also the SMC-GP
entity sets the timer TC1* and enters the Wait for CP-ACK state.

The value of TC1* may vary with the length of the CP-DATA. However, the value of TC1* shall be sufficiently great
to allow the lower layers to transmit the CP-DATA and CP-ACK messages and to allow for some re-transmissions of
layer 2 frames.

If an SMC entity in the Wait for CP-ACK state gets an indication that the CP-DATA message has probably been lost
then, as an implementation option, that SMC-GP entity may reduce the time until expiry of TC1*.

If the timer TC1* expires in the Wait for CP-ACK state, the CP-DATA message is retransmitted and the state Wait for
CP-ACK is re-entered. The maximum number of CP-DATA message re-transmissions is an implementation option but
shall be either 1, 2 or 3. If the timer TC1* expires after the maximum number of retransmission attempts, an error
indication is passed to SM-RL. The Idle state is then entered.

On receipt of the CP-ACK message in response to the CP-DATA (RP DATA) message in the Wait for CP-ACK state,
the SMC-GP resets the timer TC1* and enters the Wait for CP DATA state.

On receipt of the CP-ACK message in response to the CP-DATA (RP ACK) message in the Wait for CP-ACK state,
the SMC-GP resets the timer TC1* and enters the Idle State.

When receiving a CP-DATA message form the LLC sublayer, the SMC-GP entity checks the parameters relevant to the
CP protocol. If these are valid, the RPDU is passed to the SM-RL, the CP-ACK message is sent.

If an SMC entity in the Idle state is unable to accept a CP-DATA message, it sends a CP-ERROR message and then
enters the Idle state.

4.3.3 Release of MM and CM connections

With the exception of error situations, release of the MM and CM connection is controlled by the SM-RL.

When an SMC entity in the Wait for CP-ACK state receives a release request from SM-RL, this request is stored until
the next state (either MM Connection Established or Idle) is entered. If the Idle state is entered, the request is discarded.
If the MM Connection Established state is entered, or if the SMC entity receives a release request from SM-RL in this
state, an MM-connection release request is sent to the MM-sublayer and the SMC entity enters the Idle state.

4.3.4 Abnormal cases

Abnormal cases that shall be handled by the SMC entity in any state can be classified into five cases:

- Upper Layer Abort: Errors occurring in the SM-RL may cause the SM-RL to send an MNSMS-ABORT Request
to the SMC entity.

- CP-Layer Abort: Errors occurring within the SMC entity itself may require termination of all activities related to
that transaction identifier.

- Lower Layer Abort: Errors occurring within the layers beneath the CP-layer may cause an MMSM-ERROR
Indication or a GMMSMS-ERROR Indication to be sent to the SMC entity.

- CP-Layer Protocol Errors: Errors occurring within the protocol exchange between the SMC entities may result
in the sending of a CP-ERROR message between the entities.

- Lower Layer Release: Events occurring within the layers beneath the CP layer may cause an MMSM-REL
Indication to be sent to the SMC entity.
 22 TSM 04.11 V1.0.0 (2000-12)

When the CM-sublayer in the network receives an Upper Layer Abort, it may form and send the CP-ERROR message
to release the connection. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection release
request, without indication of release cause, is passed to the MM-sublayer. The SMC entity in the network then enters
the Idle state.

When the CM-sublayer in the UE receives an Upper Layer Abort and if the MM connection exists, it shall form and
send the CP-ERROR message. Irrespective of whether or not the CP-ERROR message was sent, an MM-connection
release request, without indication of release cause, is passed to the MM-sublayer. The SMC entity in the user
equipment then enters the Idle state.

In the case of a CP-Layer Abort, an error indication is passed to SM-RL. If possible, a CP-ERROR message is sent to
the partner SMC entity to indicate the error situation. Then the SMC entity enters the Idle state.

In the case of a Lower Layer Abort, the SMC entity passes an error indication to SM_RL, an MM-connection release
request is passed to the MM-sublayer, and the SMC entity immediately enters the Idle state.

In the case of the reception of a CP-ERROR message from the partner SMC entity, an error indication is passed to
SM-RL, an MM-connection release request, without indication of release cause, is passed to the MM-sublayer, and the
SMC entity enters the Idle state.

In the case of a lower layer release, the SMC entity passes an MNSMS-ERROR Indication to SM-RL and then enters
the Idle state.

In all cases, if the timer TC1* is running, it is reset.

Due to structure of message flow on SAPI 0 and 3 it is possible that the CP-ACK of a short message transfer might not
be received (e.g. due to handover). If the first CP-ACK (acknowledging the CP-DATA that carried the first RPDU) is
not received the reception of CP-DATA may be interpreted as the reception of the awaited CP-ACK and CP-DATA
message.

4.4 Concatenating short message or notification transfers

If an entity has more than one short message or notification to send, then it is useful to maintain the Radio Resource
(RR) connection in between transfers for circuit switched mode. For mobile terminated short messages this is simple
because the network decides when, and whether, to release the RR connection. However, for mobile originated
transfers, the network does not know whether or not the mobile has more messages to transfer.

If another short message or a memory available notification is to be sent, an originating SMR entity in the UE may
choose to continue to use the same RR connection. When the UE chooses to use the same RR connection, then:

- the UE shall transmit a CM SERVICE REQUEST for the new CM connection before the final CP-ACK (e.g. the
one that acknowledges the CP-DATA that carried the RP-ACK) for the old MM connection is transmitted;

- before transmission of the first CP-DATA on the new MM connection, the UE shall transmit the CP-ACK for
the old MM connection;

- the Transaction Identifier used on the new MM connection shall be different to that used on the old MM
connection; and

- the UE shall not initiate establishment of the new MM connection before the final CP-DATA (e.g. the one
carrying the RP-ACK) has been received.

NOTE: When an UE sends successive memory available notifications and/or mobile originated short messages
on different RR connections, the UE is strongly recommended to use different Transaction Identifiers for
the old and new MM connections.

Due to the structure of message flow on SAPIs 0 and 3 it is possible that the final CP-ACK of a short message transfer
may not be received (e.g. due to transmission errors and/or handovers). For mobile terminated transfers, if the CP-ACK
is lost, the reception of a CP-DATA with a different transaction identifier and carrying an RPDU shall be interpreted as
the implicit reception of the awaited CP-ACK followed by the reception of the new CP-DATA message. For mobile
originated transfers, if the CP-ACK is lost, the reception of a CM SERVICE REQUEST followed by a CP-DATA with
a different transaction identifier and carrying an RPDU shall be interpreted as the implicit reception of the awaited
CP-ACK followed by the reception of the new CP-DATA message.
 23 TSM 04.11 V1.0.0 (2000-12)

5 SM-RL-procedures

5.1 General
This clause describes the procedures used by the SMR entity for short message and notification support on the Short
Message Relay Layer. An SMR entity communicates with a corresponding peer entity using a CM-connection.

Multiple CM-connections may be established at the same time, allowing parallel transactions. There is a functional one
to one relation between the SMR entity and the SMC entity of the CM-sublayer. The descriptions of the procedures are
related to one single transaction.

The RL-procedures described in this subclause can only be performed if a CM-connection has been established
between the user equipment and the network. Detailed SDL-diagrams for short message control on SM-RL are
contained in annex D.

5.2 Transition states of SMR entity

The state transition diagram for the SMR entities on both UE-side and network side are contained in annex D.

5.2.1 SMR-states at the UE-side of the radio interface

The states described in this subclause are for a SMR entity in a UE, handling mobile originating- and mobile
terminating short messages and notification transfer.

5.2.1.1 Idle (State 0)

This state exists when the SMR entity is in idle mode, or when a short message or notification transfer ends in a normal
or abnormal way.

5.2.1.2 Wait for RP-ACK (State 1)

This state exists for mobile originating short message or notification transfer when the SMR has passed the RP-DATA
or RP-SMMA to the SMC entity and set the timer TR1M.

5.2.1.3 Wait for RETRANS TIMER (State 4)

This state exists for memory available notification when the SMR is waiting to retransmit the RP-SMMA message.
Timer TRAM has been set. The possibility of an abort of the sending of the memory available notification by the
SM-TL exists. No underlying connection exists.

5.2.2 SMR-states at the network side of the radio interface

The states described in this subclause are for a SMR entity in a MSC, handling mobile originating- and mobile
terminating short message and notification transfer.

5.2.2.1 Idle (State 0)

This state exists when the SMR entity is in idle mode, or when a short message transfer or notification end in a normal
or abnormal way.

5.2.2.2 Wait for RP-ACK (State 1)

This state exists for a mobile terminating short message transfer when the SMR has passed the RP-DATA message to
the SMC entity and set the timer TR1N.
 24 TSM 04.11 V1.0.0 (2000-12)

5.2.2.3 Wait to send RP-ACK (State 3)

The SMR entity will enter this state after passing a received RP-DATA or RP-SMMA message to RL and setting the
timer TR2N.

5.3 Short Message Relay procedures

The procedures needed for short message and notification relaying are:

- TP Data Unit (TPDU) relay procedures;

- notification relay procedures;

- procedures for abnormal cases.

5.3.1 TPDU relaying

When the SMR entity is in the Idle state and receives a request from SM-TL to relay a TPDU, it forms and transfers the
RP-DATA message (containing the TPDU), sets the timer TR1* and enters the state Wait for RP-ACK.

Retransmission of RP data units by the CM-sublayer is described in clause 6.

When the SMR entity is in the "Wait for RP-ACK" state, the following situations may occur:

a) reception of an RP-ACK or RP-ERROR message (containing the same reference number as the transmitted
RP-DATA message);

b) reception of an error indication from the CM-sublayer;

c) the timer TR1* expires.

In case a) or b), the timer TR1* is reset, a report indication is passed to SM-TL, a request to release the CM-connection
is passed to CM-sublayer, and the SMR entity enters the Idle state.

In case c), a request to abort the CM-connection is passed to the CM-sublayer, a report indication is passed to SM-TL,
and the SMR entity enters the Idle state.

When the SMR entity is in the Idle state and receives an MNSMS-EST-Ind containing a valid RP-DATA message, it
passes the SMS-TPDU to the SM-TL, starts timer TR2*, and enters the state "Wait to Send RP-ACK".

When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives the SM-RL-Report-Request,
the timer TR2* is reset, the RP-message (RP-ACK or RP-ERROR) is generated and relayed to the peer entity, a
CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state.

When the SMR entity is in the state "Wait to Send RP-ACK" and the SMR entity receives an error indication from the
CM-sublayer, the timer TR2* is reset, a report indication is passed to the SM-TL and the SMR entity enters the Idle
state.

When the SMR entity is in the state "Wait to send RP-ACK" and the timer TR2* expires, the SMR entity passes a
CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the SMR entity
enters the Idle state.

5.3.2 Notification relaying

5.3.2.1 UE side

5.3.2.1.1 Idle state

When the SMR entity in the UE in the Idle state receives a request from the SM-TL to relay a notification to the
network, it forms and transfers the RP-SMMA message, starts timer TR1M, and enters the state Wait for RP-ACK.
 25 TSM 04.11 V1.0.0 (2000-12)

5.3.2.1.2 Wait for RP-ACK state

When the SMR entity in the UE is in the Wait for RP-ACK state and it receives either:

- an RP-ACK (containing the same reference number as the last transmitted RP-SMMA message); or

- an RP-ERROR (containing the same reference number as the last transmitted RP-SMMA message) with a
permanent failure indication; or

- an error indication from the CP-sublayer;

then the UE shall reset timer TR1M, pass a report indication to SM-TL, give a CM-connection release request to the
CM-sublayer, and enter the Idle state. If set, timer TRAM and the RETRANS flag are also reset.

When the SMR entity in the UE is in the Wait for RP-ACK state and either:

- it receives an RP-ERROR (containing the same reference number as the last transmitted RP-SMMA message)
with a temporary failure indication; or

- timer TR1M expires;

then the UE shall examine the RETRANS flag:

- if the RETRANS flag is set (i.e. no more transmissions of the RP-SMMA message are permitted) then:

- the UE shall pass a report indication to SM-TL, give a CM-connection release request to the CM-sublayer,
reset the RETRANS flag, reset TR1M, and enter the Idle state.

- If the RETRANS flag is not set (i.e. at least another transmission of the RP-SMMA message is currently
permitted) then:

- the UE shall give a CM-connection release request to the CM-sublayer, set the RETRANS flag, reset TR1M,
start timer TRAM and enter the Wait for Retrans Timer state.

When the SMR entity in the UE is in the Wait for RP-ACK state and it receives an
SM-RL-MEMORY-AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the UE shall set the RETRANS
flag and reenter the Wait for RP-ACK state.

5.3.2.1.3 Wait for RETRANS Timer state

When the SMR entity in the UE is in the Wait for Retrans Timer state and timer TRAM expires then, the UE shall form
and transfer an RP-SMMA message, start timer TR1M, and enter the state Wait for RP-ACK. The RP-Message
Reference in this RP-SMMA message shall be different from that in the previous RP-SMMA message.

When the SMR entity in the UE is in the Wait for Retrans Timer state and it receives an
SM-RL-MEMORY-AVAILABLE-Req (SMS-MEM-NOTIF-ABORT) primitive, then the UE shall reset the
RETRANS flag, reset timer TRAM, pass a report indication to SM-TL, and enter the Idle state.

5.3.2.2 Network side

5.3.2.2.1 Idle state

When the SMR entity in the network is in the Idle state and receives an MNSMS-EST-Ind containing a valid
RP-SMMA message, it passes the SMS-TPDU to the SM-TL, starts timer TR2N, and enters the state "Wait to send
RP-ACK".

5.3.2.2.2 Wait to Send RP-ACK state

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives the
SM-RL-Report-Request, timer TR2N is reset, the RP-message (RP-ACK or RP-ERROR) is generated and relayed to
the UE, a CM-connection release request is passed to the CM-sublayer, and the SMR entity enters the Idle state.
 26 TSM 04.11 V1.0.0 (2000-12)

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the SMR entity receives an error
indication from the CM-sublayer, timer TR2N is reset, a report indication is passed to the SM-TL and the SMR entity
enters the Idle state.

When the SMR entity in the network is in the state "Wait to Send RP-ACK" and the timer TR2N expires, the SMR
entity passes a CM-connection abort request to the CM-sublayer, a report indication is passed to the SM-TL, and the
SMR entity enters the Idle state.

5.3.3 Abnormal cases

Format errors etc.:

If the SMR entity upon receipt of an RP-DATA or RP-SMMA message detects an erroneous condition which it
can act on, (e.g. format errors, invalid parameters etc.) it shall return an RP-ERROR message with an
appropriate cause value and possibly extended diagnostic information, release or abort the CM-connection, and
enter the Idle state.

6 Message functional definitions and content

6.1 General
The notation used is as used in TSM 04.08, and each definition includes:

a) A brief description of the message direction and use.

b) A table listing the information elements in the order of their appearance in the message. For each information
element the table indicates:

1) A reference to the (sub)clause/Technical Specification describing the information element.

2) The presence requirement indication (M, C, or O) for the IE as defined in TSM 04.07.

3) The format of the information element (T, V, TV, LV, TLV) as defined in TSM 04.07.

4) The length of the information element (or permissible range of lengths), in octets, in the messages.

6.2 Messages for short message or notification transfer on CM

This subclause describes the functional definition and content of the messages sent between two SMC entities.

There are three messages defined: CP-DATA, CP-ACK and CP-ERROR.

6.2.1 CP-DATA
The CP-DATA message is sent between an MSC and an UE, in both directions. The message contains the user data to
be relayed between the CM-users, and associated parameters. See table 6.1/ TSM 04.11.

Table 6.1/TSM 04.11: CP-DATA message content

Information element Reference Presence Format Length

Protocol discriminator TSM 04.07 M V 1/2 octet
Transaction identifier TSM 04.07 M V 1/2 octet
Message type Subclause 7.1.3 M V 1 octet
CP-User data Subclause 7.1.4.1 M LV ≤ 249 octets

6.2.2 CP-ACK
The CP-ACK message is sent between an MSC and an UE, in both directions, and is used to acknowledge the reception
of a CP-DATA message.
 27 TSM 04.11 V1.0.0 (2000-12)

See table 6.2/TSM 04.11.

Table 6.2/TSM 04.11: CP-ACK message content

Information element Reference Presence Format Length

Protocol discriminator TSM 04.07 M V 1/2 octet
Transaction identifier TSM 04.07 M V 1/2 octet
Message type Subclause 7.1.3 M V 1 octet

6.2.3 CP-ERROR
The CP-ERROR message is sent between an MSC and an UE, in both directions, and used to convey error information.
See table 6.3/TSM 04.11.

Table 6.3/TSM 04.11: CP-ERROR message content

Information element Reference Presence Format Length

Protocol discriminator TSM 04.07 M V 1/2 octet
Transaction identifier TSM 04.07 M V 1/2 octet
Message type Subclause 7.1.3 M V 1 octet
CP-Cause Subclause 7.1.4.2 M V 1 octet

6.3 Messages for short message and notification transfer on

SM-RL
This subclause describes the functional definition and content of the messages sent between two SMR entities.

There are 4 messages defined: RP-DATA, RP-SMMA, RP-ACK and RP-ERROR.

6.3.1 RP-DATA

6.3.1.1 RP-DATA (Network to User Equipment)

This message is sent in MSC -> UE direction. The message is used to relay the TPDUs. The information elements are
in line with GSM 03.40. See table 6.4/TSM 04.11.

Table 6.4/TSM 04.11: RP-DATA message content

Information element Reference Presence Format Length

RP-Message Type Subclause 7.2.2!! M V 3 bits
RP-Message Reference Subclause 7.2.3!! M V 1 octet
RP-Originator Address Subclause 7.2.4.1 M LV 3-12 octets
RP-Destination Address Subclause 7.2.4.2 M LV 1-12 octets
RP-User Data Subclause 7.2.4.3 M LV ≤ 234 octets

6.3.1.2 RP-DATA (User Equipment to Network)

This message is sent in UE -> MSC direction. The message is used to relay the TPDUs. The information elements are
in line with GSM 03.40. See table 6.5/TSM 04.11.
 28 TSM 04.11 V1.0.0 (2000-12)

Table 6.5/TSM 04.11: RP-DATA message content

Information element Reference Presence Format Length

RP-Message Type Subclause 7.2.2 M V 3 bits
RP-Message Reference Subclause 7.2.3 M V 1 octet
RP-Originator Address Subclause 7.2.4.1 M LV 1 octet
RP-Destination Address Subclause 7.2.4.2 M LV 1-12 octets
RP-User Data Subclause 7.2.4.3 M LV ≤ 234 octets

6.3.2 RP-SMMA
This message is sent by the user equipment to relay a notification to the network that the mobile has memory available
to receive one or more short messages. The information elements are in line with GSM 03.40. See table 6.6/TSM 04.11.

Table 6.6/TSM 04.11: RP-SMMA message content

Information element Reference Presence Format Length

RP-Message Type Subclause 72.2 M V 3 bits
RP-Message Reference Subclause 7.2.3 M V 1 octet

6.3.3 RP-ACK
This message is sent between the MSC and the user equipment in both directions and used to relay the
acknowledgement of a RP-DATA or RP-SMMA message reception. The information elements are in line with
GSM 03.40. See table 6.7/TSM 04.11.

Table 6.7/TSM 04.11: RP-ACK message content

IEI Information element Reference Presence Format Length

RP-Message Type Subclause 8.2.2!! M V 3 bits
RP-Message Reference Subclause 7.2.3 M V 1 octet
41 RP-User Data Subclause 7.2.4.3 O TLV ≤ 240 octets

6.3.4 RP-ERROR
This message is sent between the MSC and the user equipment in both directions and used to relay an error cause from
an erroneous short message or notification transfer attempt. The information elements are in line with GSM 03.40. See
table 6.8/TSM 04.11.

The contents of the cause field are given in subclause 7.2.4.4.

Table 6.8/TSM 04.11: RP-ERROR message content

IEI Information element Reference Presence Format Length

RP-Message Type Subclause 7.2.2!! M V 3 bits
RP-Message Reference Subclause 7.2.3!! M V 1 octet
RP-Cause Subclause 7.2.4.4 M LV 2-3 octets
41 RP-User Data Subclause 7.2.4.3 O TLV ≤ 240 octets
 29 TSM 04.11 V1.0.0 (2000-12)

7 Message format and information elements coding

7.1 CP-messages
7.1.1 General
The message format and information elements coding is in line with TSM 04.07 and TSM 04.08.

The message shall consist of the following parts:

a) protocol discriminator;

b) transaction identifier;

c) message type;

d) other required information elements.

This organization is illustrated in the example shown in figure 7.1/04.11

8 7 6 5 4 3 2 1
Transaction Id. Protocol Discr.
Message Type
Other Information Elements

Figure 7.1/TSM 04.11

7.1.2 Protocol Discriminator and Transaction Identifier

The Protocol Discriminator and Transaction Identifier is described in TSM 04.07.

7.1.3 Message type

The purpose of the message type, together with the protocol discriminator, is to identify the function of the message
being sent. The coding of message types is shown in table 7.1/TSM 04.11.

Table 7.1/TSM 04.11: Message types for short message and notification transfer on CM

8 7 6 5 4 3 2 1

0 0 0 0 0 0 0 1 CP-DATA
0 0 0 0 0 1 0 0 CP-ACK
0 0 0 1 0 0 0 0 CP-ERROR

7.1.4 Other required information elements

7.1.4.1 CP-User data element

The CP-User data element is used to carry the RPDU. It has an information element identifier, a length indicator and a
data field. The data field will contain the RPDUs. The maximum length of the data field is 255 octets. The layout is
indicated in figure 7.2/TSM 04.11.

8 7 6 5 4 3 2 1
 30 TSM 04.11 V1.0.0 (2000-12)

0 0 0 0 0 0 1
0 CP-User Data IEI 1 octet
Length indicator 1 octet
RPDU
Maximum length 248 octets ? octet

Figure7.2/TSM 04.11: CP-User data element layout

7.1.4.2 CP-Cause element

This element is included in the CP-ERROR message, the layout is given in figure 7.3/TSM 04.11. The error causes are
listed in table 7.2/TSM 04.11.

8 7 6 5 4 3 2 1
0 0 0 0 0 1 0
0 CP-Cause IEI 1 octet
0 Cause value 1 octet

Figure 7.3/TSM 04.11: CP-Cause element layout

Table 7.2/TSM 04.11: Content and coding of CP-Cause

Cause value Cause nr. Cause

7654321 #
0010001 17 Network failure
0010110 22 Congestion
1010001 81 Invalid Transaction Identifier value
1011111 95 Semantically incorrect message
1100000 96 Invalid mandatory information
1100001 97 Message type non-existent or not implemented
1100010 98 Message not compatible with the short message protocol state
1100011 99 Information element non-existent or not implemented
1101111 111 Protocol error, unspecified

All other cause values shall be treated as cause number 111.

7.2 RP-messages
7.2.1 General
The message shall consist of the following parts:

a) message type indicator;

b) message reference;

c) other required information elements.

This organization is illustrated in the example shown in figure 7.4/04.11:

8 7 6 5 4 3 2 1
 31 TSM 04.11 V1.0.0 (2000-12)

spare MTI
0 0 0 0 0
Message reference
Other Information Elements

Figure 7.4/TSM 04.11

7.2.2 Message type indicator (MTI)

The message type indicator, MTI, is a 3-bit field, located in the first octet of all RP-messages. The coding of the MTI is
defined by table 7.3/TSM 04.11.

Table 7.3/TSM 04.11: Coding of Message Type Indicator

Bit value Direction RP-Message

321
000 UE -> n RP-DATA
000 n -> UE Reserved
001 UE -> n Reserved
001 n -> UE RP-DATA
010 UE -> n RP-ACK
010 n -> UE Reserved
011 UE -> n Reserved
011 n -> UE RP-ACK
100 UE -> n RP-ERROR
100 n -> UE Reserved
101 UE -> n Reserved
101 n -> UE RP-ERROR
110 UE -> n RP-SMMA
110 n -> UE Reserved
111 UE -> n Reserved
111 n -> UE Reserved

7.2.3 Message reference

The message reference field contains a sequence number in the range 0 through 255, and is used to link an RP-ACK
message or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt.

7.2.4 Other required information elements

7.2.4.1 Originator address element

In the case of MT transfer this element contains the originating Service Centre address.

The RP-Originator Address information element is coded as shown in figure 7.5/TSM 04.11.

The RP-Originator Address is a type 4 information element. In the network to user equipment direction the minimum
value of the length octet is 2 and the maximum value is 11. In the user equipment to network direction the value of the
length octet of the element is set to 0.

8 7 6 5 4 3 2 1
RP-Originator Address IEI octet 1
Length of RP-Originator Address contents octet 2
1 ext type of number Numbering plan octet 3
 32 TSM 04.11 V1.0.0 (2000-12)

identification
Number digit 2 Number digit 1 octet 4
Number digit 4 Number digit 3 octet 5
:
:

Figure 7.5/TSM 04.11: RP-Originator Address information element

If the RP-Originator Address contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end
mark coded as "1111".

The contents of octets 3, 4, etc. are the same as those defined for the Called Party BCD Number IE defined in
TSM 04.08.

7.2.4.2 Destination address element

In the case of MO transfer, this element contains the destination Service Centre address.

The RP-Destination Address information element is coded as shown in figure 7.6/TSM 04.11.

The RP-Destination Address is a type 4 information element. In the user equipment to network direction the minimum
value of the length octet is 1 and the maximum value is 11. In the network to user equipment direction, the value of the
length octet of the element is set to 0.

8 7 6 5 4 3 2 1
RP-Destination Address number IEI octet 1
Length of RP-Destination Address contents octet 2
1 ext type of number Numbering plan octet 3
identification
Number digit 2 Number digit 1 octet 4
Number digit 4 Number digit 3 octet 5
:
:

Figure 7.6/TSM 04.11: RP-Destination Address information element

The number digit(s) in octet 4 precede the digit(s) in octet 5 etc. The number digit which would be entered first is
located in octet 4, bits 1 to 4.

If the RP-Destination Address contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end
mark coded as "1111".

Since the information element contains the complete RP-Destination Address there is no need for an additional
complete indication.

The contents of octets 3, 4, etc. are the same as those defined for the Called Party BCD Number IE defined in
TSM 04.08.

7.2.4.3 RP-User data element

The RP-User data field contains the TPDU and is mandatory in a RP-DATA message. RP-User data is also optionally
carried in an RP-Error message. The element has a variable length, up to 239 octets, the first octet sent being a length
indicator.
 33 TSM 04.11 V1.0.0 (2000-12)

RP-User data in an RP-Error message is conveyed as diagnostic information within the "SM-DeliveryFailureCause"
response to a MAP Forward-Short-Message procedure (see GSM 09.02). The diagnostic information may be sent in
both directions, and shall always be forwarded by the MSC if it is received.

8 7 6 5 4 3 2 1
1 0 0 0 0 0 1
0 RP-User Data IEI 1 octet
Length indicator 1 octet
TPDU
Maximum length 233 octets

Figure 7.7/TSM 04.11: RP-User data element layout

7.2.4.4 RP-Cause element

This element is a variable length element always included in the RP-ERROR message, conveying a negative result of a
RP-DATA message transfer attempt or RP-SMMA notification attempt. The element contains a cause value and
optionally a diagnostic field giving further details of the error cause.

The coding of the cause value is given in table 7.4/TSM 04.11. The mapping between error causes in TSM 04.11 and
GSM 09.02 (MAP) is specified in GSM 03.40. Parameters included in the return error from MAP (e.g. System Failure)
are mapped directly into the diagnostic field.

8 7 6 5 4 3 2 1
1 0 0 0 0 1 0
0 RP-Cause IEI 1 octet
Length indicator 1 octet
0 ext Cause value 1 octet
Cause value
Diagnostic field 1 octet *

Figure 7.7/TSM 04.11: RP-Cause element layout

 34 TSM 04.11 V1.0.0 (2000-12)

Table 7.4/TSM 04.11 (part 1): Cause values that may be contained in an RP-ERROR message
in a mobile originating SM-transfer attempt

Cause value Cause Cause

Class value number

7654321 #
0000001 1 Unassigned (unallocated) number
0001000 8 Operator determined barring
0001010 10 Call barred
0001011 11 Reserved
0010101 21 Short message transfer rejected
0011011 27 Destination out of order
0011100 28 Unidentified subscriber
0011101 29 Facility rejected
0011110 30 Unknown subscriber
0100110 38 Network out of order
0101001 41 Temporary failure
0101010 42 Congestion
0101111 47 Resources unavailable, unspecified
0110010 50 Requested facility not subscribed
1000101 69 Requested facility not implemented
1010001 81 Invalid short message transfer reference value
1011111 95 Semantically incorrect message
1100000 96 Invalid mandatory information
1100001 97 Message type non-existent or not implemented
1100010 98 Message not compatible with short message protocol
state
1100011 99 Information element non-existent or not implemented
1101111 111 Protocol error, unspecified
1111111 127 Interworking, unspecified

All other cause values shall be treated as cause number 41, "Temporary Failure".

Table 7.4/TSM 04.11 (part 2): Cause values that may be contained in an RP-ERROR message in a
mobile terminating SM-transfer attempt

Cause value Cause Cause

Class value number

7654321 #
0010110 22 Memory capacity exceeded
1010001 81 Invalid short message transfer reference value
1011111 95 Semantically incorrect message
1100000 96 Invalid mandatory information
1100001 97 Message type non-existent or not implemented
1100010 98 Message not compatible with short message protocol state
1100011 99 Information element non-existent or not implemented
1101111 111 Protocol error, unspecified

All other cause values shall be treated as cause number 111, "Protocol error, unspecified".
 35 TSM 04.11 V1.0.0 (2000-12)

Table 7.4/TSM 04.11 (part 3): Cause values that may be contained in an RP-ERROR message in a
memory available notification attempt

Cause value Cause Cause Cause

Class value number type

7654321 #
0011110 30 P Unknown Subscriber
0100110 38 T Network out of order
0101001 41 T Temporary failure
0101010 42 T Congestion
0101111 47 T Resources unavailable, unspecified
1000101 69 P Requested facility not implemented
1011111 95 P Semantically incorrect message
1100000 96 P Invalid mandatory information
1100001 97 P Message type non-existent or not implemented
1100010 98 P Message not compatible with short message protocol state
1100011 99 P Information element non-existent or not implemented
1101111 111 P Protocol error, unspecified
1111111 127 P Interworking, unspecified

All other cause values are treated as cause number 41, "Temporary failure".

Each cause is classified as "Temporary" or "Permanent", as indicated by T and P respectively in the cause type
column.

8 Handling of unknown, unforeseen, and erroneous

protocol data

8.1 General
This subclause specifies procedures for handling of unknown, unforeseen, and erroneous protocol data by the receiving
entity. These procedures are called "error handling procedures", but in addition to providing recovery mechanisms for
error situations they define a compatibility mechanism for future extensions of the protocols.

Most error handling procedures are mandatory for the UE but optional for the network. Detailed error handling
procedures in the network are implementation dependent and may vary from PLMN to PLMN.

In this subclause the following terminology is used:

- An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved",
or if its value part violates rules. However it is not a syntactical error that a type 4 IE specifies in its length
indicator a greater length than defined.

- A message is defined to have semantically incorrect contents if it contains information which, possibly
dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural
part of TSM 04.11.

8.2 CP Error Handling

Upon receiving a CP-ERROR message the SMC-CS entity (in any state) shall pass an error indication to SM-RL, pass
an MM-connection release request to the MM-sublayer, and enter the Idle State.

After sending a CP-ERROR message the SMC-CS entity (in any state) shall pass an MM-connection release request to
the MM sublayer and then enter the Idle State.
 36 TSM 04.11 V1.0.0 (2000-12)

Upon receiving a CP-ERROR message the SMC-GP entity (in any state) shall pass an error indication to SM-RL and
enter the Idle State.

After sending a CP-ERROR message the SMC-GP entity (in any state) shall enter the Idle State.

8.2.1 Message too short

When a message is received that is too short to contain a complete message type information element, that message
shall be ignored, see TSM 04.07.

8.2.2 Unknown or unforeseen transaction identifier

The User Equipment shall ignore a CP message (CP-DATA, CP-ACK, CP-ERROR) received with TI value "111".
Whenever a CP-ACK message is received specifying a Transaction Identifier which is not associated with an active SM
transfer, the user equipment shall discard the message and return a CP-ERROR message with cause #81, "Invalid
Transaction Identifier" using the received Transaction Identifier, if an appropriate connection exists. The User
Equipment shall ignore a CP-ERROR message that is received specifying a Transaction Identifier which is not
associated with an active SM transfer. The User Equipment shall ignore a CP-DATA message that is received
specifying a Transaction Identifier which is not associated with an active SM transfer and with transaction identifier
flag set to "1".

The same procedures may apply to the network.

8.2.3 Unknown or unforeseen message type

If the User Equipment receives a message with message type not defined for the PD or not implemented by the
receiver, it shall ignore the message and return a CP-ERROR message with cause #97 "message type non-existent or
not implemented", if an appropriate connection exists.

NOTE: A message type not defined for the PD in the given direction is regarded by the receiver as a message
type not defined for the PD, see TSM 04.07.

If the User Equipment receives a message not consistent with the protocol state, the User Equipment shall ignore the
message and return a CP-ERROR message with cause #98 "Message type not compatible with the short message
protocol state", if an appropriate connection exists.

The network may follow the same procedures.

8.2.4 Non-semantical mandatory information element errors

When on receipt of a message:

- an "imperative message part" error; or

- a "missing mandatory IE" error.

is diagnosed or when a message containing a syntactically incorrect mandatory IE is received, the user equipment shall
proceed as follows.

When the corresponding SM transfer is not seen as successfully transferred, i.e. the transaction is not completed, the
user equipment shall ignore the message and return a CP-ERROR message with cause #96 "invalid mandatory
information", if an appropriate connection exists.

When the SM transfer is seen as successfully transferred, the user equipment shall ignore the message and enter the Idle
State.

In the case that the message received is a CP-ERROR message, the user equipment shall ignore the message and enter
the Idle State.

The network may follow the applicable procedures defined in this subclause.
 37 TSM 04.11 V1.0.0 (2000-12)

8.2.5 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of
TSM 04.11 are performed. If however no such reactions are specified, the user equipment shall proceed as follows:

- When the corresponding SM transfer is not seen as successfully transferred, the user equipment shall ignore the
message and return a CP-ERROR message with cause value #95 "semantically incorrect message", if an
appropriate connection exists.

- When the SM transfer is seen as successfully transferred, the user equipment shall ignore the message and enter
the Idle State.

- In the case that the message received is a CP-ERROR message, the user equipment shall ignore the message and
enter the Idle State.

The network may follow the same procedure.

8.3 RP Error Handling

Upon receiving or sending an RP-ERROR message the SMR entity shall behave as described in the procedural
description in clause 5.

8.3.1 Message too short

When a message is received that is too short to contain a complete message type information element and Message
Reference, that message shall be ignored.

8.3.2 Unknown or unforeseen Message Reference

Whenever any RP-ACK message is received specifying a Message Reference which is not associated with an active
SM transfer, the user equipment shall discard the message and return an RP-ERROR message with cause #81, "Invalid
short message transfer reference value" using the received Message Reference, if an appropriate connection exists.

When an RP-ERROR message is received specifying a Message Reference which is not associated with an active SM
transfer, the user equipment shall discard the message.

When the user equipment's SMR entity is not in the Idle state, and it receives an RP-DATA message specifying a
Message Reference which is not associated with the active SM transfer, then it shall either:

- send an RP-ERROR message with cause #81, "Invalid short message transfer reference value" using the
received Message Reference, if an appropriate connection exists; or

- behave as described below for the receipt of an message not consistent with the protocol state.

The same procedures may apply to the network.

8.3.3 Unknown or unforeseen message type

If the User Equipment receives a RP-message indicating a value of the message type indicator (MTI) defined as
reserved, it shall ignore the message and return an RP-ERROR message with cause #97 "message type non-existent or
not implemented", if an appropriate connection exists.

If the User Equipment receives a message (except RP-ERROR) not consistent with the protocol state, the User
Equipment shall ignore the message and return a RP-ERROR message with cause #98 "Message type not compatible
with Short Message protocol state", if an appropriate connection exists.

If the User Equipment receives an RP-ERROR message not consistent with the protocol state, the User Equipment shall
ignore the message.

The network may follow the same procedures.

 38 TSM 04.11 V1.0.0 (2000-12)

8.3.4 Non-semantical mandatory information element errors

When on receipt of a message:

- an "imperative message part" error; or

- a "missing mandatory IE" error;

is diagnosed or when a message containing a syntactically incorrect mandatory IE is received, the user equipment shall
(except for the case of a reserved value of the MTI as defined above) proceed as follows:

- when the message is an RP-DATA or RP-ACK, the user equipmentshall ignore the message and return an
RP-ERROR message with cause #96 "invalid mandatory information", if an appropriate connection exists;

- when the message is an RP-ERROR, the mobile station shall treat the message as an RP-ERROR message
carrying RP-Cause value 111 without any diagnostic field, and with no RP-User Data.

The network may follow the applicable procedures defined in this subclause.

8.3.5 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of
TSM 04.11 are performed. If however no such reactions are specified then:

- if the message was not an RP-ERROR message, the UE shall ignore the message and return an RP-ERROR
message with cause value #95 "semantically incorrect message", if an appropriate connection exists; while

- if the message was an RP-ERROR message, the user equipment shall treat the message as an RP-ERROR
message carrying RP-Cause value #111 without any diagnostic field, and with no RP-User Data.

The network may follow the same procedure.

11 Timers
The present document places the following requirements on the timers described in this TS:

- timer TR1M shall be greater than 35 seconds and less than 45 seconds;

- the value of timer TRAM shall be greater than 25 seconds and less than 35 seconds;

- timer TR2M shall be greater than 12 seconds and less than 20 seconds.
 39 TSM 04.11 V1.0.0 (2000-12)

Annex A (informative):
Arrow diagrams
Arrow diagram A1:

The diagram shows CS (Circuit Switched mode) MO-message transfer by means of interlayer service primitives and
the actual messages being transferred between the layer entities

Arrow diagram A2:

The diagram shows CS MT-messaging by means of interlayer service primitives and the actual messages being
transferred between the layer entities

Arrow diagram A5:

The diagram shows PS (Packet Switched mode) MO-message transfer by means of interlayer service primitives
and the actual messages being transferred between the layer entities.

- MNSMS-primitives indicate services provided by CM to SM-RL.

- LLSMS-primitives indicate services provided by LLC to CM.

- CP-DATA is the CM-message carrying SM-RP data units.

- CP-ACK acknowledge CP-DATA reception on CM.

Arrow diagram A6:

The diagram shows PS MT-message transfer by means of interlayer service primitives and the actual messages
being transferred between the layer entities.

- MNSMS-primitives indicate services provided by CM to SM-RL.

- LLSMS-primitives indicate services provided by LLC to CM.

- CP-DATA is the CM-message carrying SM-RP data units.

- CP-ACK acknowledge CP-DATA reception on CM.

 40 (TSM 04.11 version 1.0.0): December 2000

PSMobile Originated Messaging on CM-sublayer

Mobile Station Side Network Side

SM-RL CM LLC LLC CM SM-RL

MNSMS-EST-Req (RP-DATA)

LL-UNITDATA - Req
(TLLI, CP DATA) LLC-UI
(CP DATA)
LL-UNITDATA - Ind
(TLLI, CP DATA)
MNSMS-EST-Ind (RP-DATA)
LL-UNITDATA - Req
LLC-UI (TLLI, CP ACK)
LL-UNITDATA - Ind (CP ACK)
(TLLI, CP ACK)

LL-UNITDATA - Req MNSMS-DATA-Req (RP-ACK)

LLC-UI (TLLI, CP DATA)
LL-UNITDATA - Ind (CP DATA)
(TLLI, CP DATA)

MNSMS-DATA-Ind (RP-ACK)
LL-UNITDATA - Req
(TLLI, CP ACK)
LLC-UI
(CP ACK)
LL-UNITDATA - Ind
MNSMS-REL-req (TLLI, CP ACK)
MNSMS-REL-req

Arrow diagram A5
 41 (TSM 04.11 version 1.0.0): December 2000
PS Mobile Terminated Messaging on CM-sublayer

Mobile Station Side Network Side

SM-RL CM LLC LLC CM SM-RL

MNSMS-EST- Req (RP DATA)

LL-UNITDATA - Req
(TLLI, CP DATA)
LLC-UI
LL-UNITDATA - Ind (CP DATA)
(TLLI, CP DATA)

MNSMS-EST- Ind (RP DATA)

LL-UNITDATA - Req
(TLLI, CP ACK) LLC-UI
(CP ACK) LL-UNITDATA - Ind
(TLLI, CP ACK)

MNSMS-DATA- Req (RP ACK)

LL-UNITDATA - Req
LLC-UI
(TLLI, CP DATA)
(CP DATA) LL-UNITDATA - Ind
(TLLI, CP DATA)

MNSMS-DATA- Ind (RP ACK)

LLC-UI LL-UNITDATA - Req

LL-UNITDATA - Ind (CP ACK) (TLLI, CP ACK)
(TLLI, CP ACK)
MNSMS-REL-req
MNSMS-REL-req

Arrow diagram A6
 42 (TSM 04.11 version 1.0.0): December 2000

Annex B (normative):
SDL-description of the CM-layer

B.1 Introduction
This annex contains an SDL-description of the Connection Management Sublayer in terms of the Short Message
Service Support. The CM- sublayer provides services to Short Message Relay Layer.

The SDLs contain a mixture of peer to peer messages and conceptual primitives between the layers SM-RL, CM, MM
and LLC, as viewed by the SMC entities. SDL-1/2/3 show the CSSMC entity on UE-side for Mobile Originated (MO)
short message transfer, SDL-4/5/6 show the CS SMC entity on UE-side for Mobile Terminated (MT) short message
transfer, SDL-7/8/9 show the CS SMC entity on the network side for Mobile Originated (MO) short message transfer,
and SDL-10/11/12 show the CS SMC entity on the network side for Mobile Terminated (MT) short message transfer.

SDL-13/14/15 show the PS SMC entity on UE-side for Mobile Originated (MO) short message transfer, SDL-16/17/18
show the PS SMC entity on UE-side for Mobile Terminated (MT) short message transfer, SDL-19/20/21 show the PS
SMC entity on the network side for Mobile Originated (MO) short message transfer, and SDL-22/23/24 show the PS
SMC entity on the network side for Mobile Terminated (MT) short message transfer.

The lower layers (below MM and LLC) are transparent to an SMC entity.

0
MO-IDLE

MNSMS-
EST-Req
(RP DATA)

CP DATA

Set TC1M

1
MO-Wait
for
CP ACK

MO-SMC-GP entity on UE-side for PS mode

SDL-13
 43 (TSM 04.11 version 1.0.0): December 2000

1 MO-Wait
for
CP ACK

CP ACK TC1M

No
Reset TC1M retx = max

Yes

MNSMS-
Set retx = Zero ERROR- retx = retx+1
Ind

2
MO-Wait
Set retx = Zero 1
for
CP DATA

0
MO-IDLE

MO-SMC-GP entity on UE-side for PS mode

SDL-14
 44 (TSM 04.11 version 1.0.0): December 2000

2 MO-Wait
for
CP DATA

MNSMS-
CP DATA
ABORT-
Req

MNSMS-
DATA- CP ERROR
Ind (RP ACK)

CP ACK

0
MO-IDLE

MO-SMC-GP entity on UE-side for PS mode

SDL-15

0
MO_IDLE

1
MO_Wait
for CP ACK

2
MO_Wait
for CP DATA

MO-SMC-GP entity on UE-side for PS mode

State transition diagram
 45 (TSM 04.11 version 1.0.0): December 2000

MT-IDLE

LL-
UNITDATA-
Ind-(RP DATA)

MNSMS-
DATA-
Ind (RP DATA)

CP ACK

1 MT - Wait
for
RP ACK

MT-SMC-GP entity on UE-side for PS mode

SDL-16
 46 (TSM 04.11 version 1.0.0): December 2000

1 MT-Wait
for
RP ACK

MNSMS- MNSMS-
DATA-Req ABORT-
(RP ACK) Req

CP DATA CP ERROR

Set TC1M

2 0
MT-Wait
for MT-IDLE
CP ACK

MT-SMC-GP entity on UE-side for PS mode

SDL-17
 47 (TSM 04.11 version 1.0.0): December 2000

2 MT-Wait
for
CP ACK

CP ACK TC1M

No
Reset TC1M retx = max

Yes

MNSMS-
Set retx = Zero ERROR- retx = retx+1
Ind

Set retx = Zero 1

0
MT-IDLE

MT-SMC-GP entity on UE-side for PS mode

SDL-18
 48 (TSM 04.11 version 1.0.0): December 2000

0
MT_IDLE

1
MT_Wait
for RP ACK

2
MT_Wait
for CP ACK

MT-SMC-GP entity on UE-side for PS mode

State transition diagram

MO-IDLE

LL-
UNITDATA-
Ind-(CP DATA)

MNSMS-
EST-
Ind (RP DATA)

CP ACK

1 MO - Wait
for
RP ACK

MO-SMC-GP entity on Network side for PS mode

SDL-19
 49 (TSM 04.11 version 1.0.0): December 2000

1 MT-Wait
for
RP ACK

MNSMS- MNSMS-
DATA-Req ABORT-
(RP ACK) Req

CP DATA CP ERROR

Set TC1N

2 0
MT-Wait
for MT-IDLE
CP ACK

MO-SMC-GP entity on Network side for PS mode

SDL-20
 50 (TSM 04.11 version 1.0.0): December 2000

2 MO-Wait
for
CP ACK

CP ACK TC1N

No
Reset TC1N retx = max

Yes

MNSMS-
Set retx = Zero ERROR- retx = retx+1
Ind

Set retx = Zero 1

0
MO-IDLE

MO-SMC-GP entity on Network side for PS mode

SDL-21
 51 (TSM 04.11 version 1.0.0): December 2000

0
MO_IDLE

1
MO_Wait
for RP ACK

2
MO_Wait
for CP ACK

MO-SMC-GP entity on Network-side for PS mode

State transition diagram

0
MT-IDLE

MNSMS-
EST-Req
(RP DATA)

CP DATA

Set TC1N

1
MT-Wait
for
CP ACK

MT-SMC-GP entity on Network-side for PS mode

SDL-22
 52 (TSM 04.11 version 1.0.0): December 2000

1 MT-Wait
for
CP ACK

CP ACK TC1N

No
Reset TC1N retx = max

Yes

MNSMS-
Set retx = Zero ERROR- retx = retx+1
Ind

2
MT-Wait
Set retx = Zero 1
for
CP DATA

0
MT-IDLE

MT-SMC-GP entity on Network-side for PS mode

SDL-23
 53 (TSM 04.11 version 1.0.0): December 2000

2 MT-Wait
for
CP DATA

MNSMS-
CP DATA
ABORT-
Req

MNSMS-
DATA- CP ERROR
Ind (RP ACK)

CP ACK

0
MT-IDLE

MT-SMC-GP entity on Network-side for PS mode

SDL-24

0
MT_IDLE

1
MT_Wait
for CP ACK

2
MT_Wait
for CP DATA

MT-SMC-GP entity on Network-side for PS mode

State transition diagram
 54 (TSM 04.11 version 0.

Annex C (informative):
Arrow diagrams
Arrow diagram C1:

The diagram reflects MO-message transfer by means of interlayer service primitives and the actual messages being
transferred between the layer entities.

- SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note).

- MNSMS-primitives indicate services provided by CM to SM-RL.

- RP-DATA is the SM-RL message carrying SM-TP data units.

- RP-ACK acknowledges RP-DATA reception on SM-RL.

Arrow diagram C2:

The diagram reflects MT-messaging by means of interlayer service primitives and the actual messages being transferred
between the layer entities.

- SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note).

- MNSMS-primitives indicate services provided by CM to SM-RL.

- RP-DATA is the SM-RL message carrying SM-TP data units.

- RP-ACK acknowledges RP-DATA reception on SM-RL.

Arrow diagram C3:

The diagram reflects memory available notification transfer by means of interlayer service primitives and the actual
messages being transferred between the layer entities.

- SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (* see note).

- MNSMS-primitives indicate services provided by CM to SM-RL.

- RP-SMMA is the SM-RL message indicating that the mobile has memory available to receive one or more short
messages.

- RP-ACK acknowledges RP-SMMA reception on SM-RL.

- RP-ERROR reports a failure in the notification procedure on the network side.

CWTS
 55 (TSM 04.11 version 0.

Arrow diagram C4:

The diagram reflects the abort of any retransmission of a memory available notification by SM-RL by means of the
SM-RL-MEMORY-AVAILABLE interlayer service primitive request with the SM-MEM-NOTIF-ABORT parameter
present. The use of this primitive and the associated parameter are, of course, local to the user equipment.

- SM-RL-primitives indicate services provided by SM-RL to SM-TL and RL (note).

- MNSMS-primitives indicate services provided by CM to SM-RL.

- RP-SMMA is the SM-RL message indicating that the mobile has memory available to receive one or more short
messages.

- RP-ACK acknowledges RP-SMMA reception on SM-RL.

- RP-ERROR reports a failure in the notification procedure on the network side.

NOTE: The SM-RL being the upper layer in the MSC, an interworking function between SM-RL-procedures and
MAP-procedure is necessary. The term "RL" is used in the diagrams to indicate this function (see figure).

Interw. func.
SM-RL SM-RL- MAP-
proc. proc.

CWTS
 56 (TSM 04.11 version 0.0. 2): December 2000

Mobile Originated Messaging on SM-RL

Mobile Station Side Network side

SM-TL SM-RL CM CM SM-RL RL

SM-RL-DATA-Req (SMS-SUBMIT)

RP-DATA

SM-RL-DATA-Ind (SMS-SUBMIT)

SM-RL-REPORT-Req

RP-ACK

SM-RL-REPORT-Ind

Arrow diagram C1
 57 (TSM 04.11 version 0.0. 2): December 2000

Mobile Terminated Messaging on SM-RL

Mobile Station Side Network side

SM-TL SM-RL CM CM SM-RL RL

SM-RL-DATA-Req (SMS-DELIVER)

RP-DATA

SM-RL-DATA-Ind (SMS-DELIVER)

SM-RL-REPORT-Req

RP-ACK

SM-RL-REPORT-Ind

Arrow diagram C2
 58 (TSM 04.11 version 0.0. 2): December 2000

Memory Available Notification on SM-RL

Mobile Station Side Network side

SM-TL SM-RL CM CM SM-RL RL

SM-RL-MEMORY
AVAILABLE-Req

RP-SMMA

SM-RL-MEMORY-AVAILABLE-Ind

SM-RL-REPORT-Req

RP-ACK / RP-ERROR

SM-RL-REPORT-Ind

Arrow diagram C3
 59 (TSM 04.11 version 0.0. 2): December 2000

Memory Available Notification Abort on SM-RL

Mobile Station Side Network side

SM-TL SM-RL CM CM SM-RL RL

SM-RL-MEMORY
AVAILABLE-Req

RP-SMMA
SM-RL-MEMORY
AVAILABLE-Req
(SMS-MEM-NOTIF-ABORT)

SM-RL-MEMORY-AVAILABLE-Ind

SM-RL-REPORT-Req
SM-RL-REPORT-Ind

RP-ACK / RP-ERROR

NOTE: Dashed lines indicates messages that may be sent, even though an abort request was given.
Arrow diagram C4
 60 (TSM 04.11 version 1.0.0): December 2000

Annex D (normative):
SDL-description of the short message relay layer

D.1 Introduction
This annex contains an SDL-description of the Short Message Relay Layer in terms of the Short Message Service
Support. The Short Message Relay Layer provides services to Short Message Transfer Layer.

The SDLs contain a mixture of peer to peer messages and conceptual primitives between the layers SM-TL, SM-RL
and CM, as viewed by the SMR entities. SDL-1/2/3 show the SMR entity on UE-side, and SDL-4/5 on the network
side.

The lower layers (below CM) are transparent to an SMR entity.

CWTS
 61 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

SM-RL-
DATA-Req
(SMS-SUBMIT)

MNSMS-
EST-Req
(RP-DATA)

SET TR1M

1 Wait
for
RP-ACK

MNSMS-
RP-ACK RP-ERROR ERROR-
TR1M
Ind

MNSMS-
RESET
ABORT-
TR1M Req

SM-RL- SM-RL-
Report- REPORT-
Ind Ind

0
MNSMS- IDLE
REL-Req

0
IDLE

SMR-entity on UE-side
MO Short Message transfer
SDL-1

CWTS
 62 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

MNSMS-
EST-Ind
(RP-DATA)

RP-DATA No
Accepted
?
Yes

SM-RL- Severe
DATA-Ind No
errors
(RP-DATA) ?
Yes

MNSMS-
SET TR2M ABORT- RP-ERROR
Req

0
IDLE MNSMS-
REL-Req

0
IDLE

3 Wait
to
send
RP-ACK

SM-RL- SM-RL- MNSMS-

REPORT- REPORT-Req ERROR- TR2M
Req (RP-ACK) (RP-ERROR) Ind

MNSMS-
RESET TR2M RESET TR2M RESET TR2M ABORT-
Req

SM-RL-
RP-ACK RP-ERROR REPORT-
Ind

0
MNSMS- IDLE
REL-Req

0
IDLE

SMR-entity on UE-side
MT Short Message transfer
SDL-2

CWTS
 63 (TSM 04.11 version 1.0.0): December 2000

0 B

IDLE
RETRANS
FLAG
YES SET?
SM-RL- SM-RL-MEMORY-
SM-RL- AVAILABLE-Req
Report- NO
MEMORY- Ind (SMS-MEM-
AVAILABLE-Req NOTIF-ABORT)
SET RETRANS
C FLAG, TRAM
RESET RESET TR1M RESET
RETRANS RETRANS
MNSMS-
EST-Req FLAG, TR1M FLAG, TRAM
(RP-SMMA)
MNSMS-
REL-Req SM-RL-
MNSMS- Report-
REL-Req
Ind

SET TR1M 4
WAIT FOR
0 RETRANS TIMER 0
A IDLE IDLE

1 Wait _____
for TRAM
RP-ACK

SM-RL-MEMORY-
CP-LAYER AVAILABLE-Req RP-ERROR _____
RP-ACK ERROR TR1M
(SMS-MEM-
INDICATION NOTIF-ABORT)

SET
RETRANS
FLAG
MNSMS- B
REL-Req
A

TEMP.
NO
RESET NETWORK
FAILURE?
TR1M and
RETRANS FLAG
YES

SM-RL-
Report-
Ind

0
IDLE

SMR-entity on UE-side
Memory Available Notification
SDL-3

CWTS
 64 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

3
Wait to
4 Send
Wait for RP-ACK
RETRANS
Timer

1
Wait
for
RP-ACK

SMR-entity on UE-side
State transition diagram

CWTS
 65 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

SM-RL-
DATA-Req
(RP-DATA)

MNSMS-
EST-Req
(RP-DATA)

SET TR1N

1 Wait
for
RP-ACK

MNSMS-
RP-ACK RP-ERROR ERROR-
TR1N
Ind

MNSMS-
RESET
ABORT-
TR1N Req

MNSMS- SM-RL-
REL-Req REPORT-
Ind

SM-RL- 0
Report- IDLE
Ind

0
IDLE

SMR-entity on Network-side
MT Short Message transfer
SDL-4

CWTS
 66 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

MNSMS-
EST-Ind
(RPDU)

RPDU No
Accepted
?
Yes

SM-RL-
Severe No
DATA-Ind
(RP-DATA errors
or RP-SMMA) ?
Yes

MNSMS-
SET TR2N ABORT- RP-ERROR
Req

0
IDLE MNSMS-
REL-Req

0
IDLE

3 Wait
to
send
RP-ACK

SM-RL- SM-RL- MNSMS-

REPORT- REPORT-Req ERROR- TR2N
Req (RP-ACK) (RP-ERROR) Ind

MNSMS-
RESET TR2N RESET TR2N RESET TR2N ABORT-
Req

SM-RL-
RP-ACK RP-ERROR REPORT-
Ind

0
MNSMS- IDLE
REL-Req

0
IDLE

SMR-entity on Network-side
MO Short Message and Notification transfer
SDL-5

CWTS
 67 (TSM 04.11 version 1.0.0): December 2000

0
IDLE

1
3
Wait
Wait
for
to send
RP-ACK
RP-ACK

SMR-entity on Network-side
State transition diagram

CWTS
 68 (TSM 04.11 version 1.0.0): December 2000

Annex E (informative): Cause definition

E-1: CP-cause definition

Cause no. 17: "Network failure"

This cause is sent to the UE if the MSC cannot service an UE generated request because of PLMN failures, e.g.
problems in MAP.

Cause no. 22: "Congestion"

This cause is sent if the service request cannot be actioned because of congestion (e.g. no channel, facility
busy/congested etc.).

Cause no. 81: "Invalid Transaction Identifier"

This cause indicates that the equipment sending this cause has received a message with a Transaction Identifier
which is currently not use on the UE - network interface.

Cause no. 95: "Semantically incorrect message"

This cause is used to report the receipt of a message with semantically incorrect content.

Cause no. 96: "Invalid mandatory information"

This cause indicates that the equipment sending this cause has received a message with non-semantical
mandatory information element errors.

Cause no. 97: "Message type non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message with a message type it does
not recognize either because this is a message not defined or defined but not implemented by the equipment
sending this cause.

Cause no. 98: "Message not compatible with short message protocol state"

This cause indicates that the equipment sending this cause has received a message not compatible with the Short
Message protocol state.

Cause no. 99: "Information element non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message which includes information
elements not recognized because the information element identifier is not defined or it is defined but not
implemented by the equipment sending the cause.

However, the information element is not required to be present in the message in order for the equipment
sending the cause to process the message.

Cause no. 111: "Protocol error, unspecified"

This cause is used to report a protocol error event only when no other cause applies.

E-2: RP-cause definition mobile originating SM-transfer

Cause no. 1: "Unassigned (unallocated) number"

This cause indicates that the destination requested by the User Equipment cannot be reached because, although
the number is in a valid format, it is not currently assigned (allocated).

Cause no. 8: "Operator determined barring"

This cause indicates that the UE has tried to send a mobile originating short message when the UE’s network
operator or service provider has forbidden such transactions.

Cause no. 10: "Call barred"

CWTS
 69 (TSM 04.11 version 1.0.0): December 2000

This cause indicates that the outgoing call barred service applies to the short message service for the called
destination.

Cause no. 21: "Short message transfer rejected"

This cause indicates that the equipment sending this cause does not wish to accept this short message, although
it could have accepted the short message since the equipment sending this cause is neither busy nor
incompatible.

Cause no. 27: "Destination out of service"

This cause indicates that the destination indicated by the User Equipment cannot be reached because the
interface to the destination is not functioning correctly. The term "not functioning correctly" indicates that a
signalling message was unable to be delivered to the remote user; e.g., a physical layer or data link layer failure
at the remote user, user equipment off-line, etc.

Cause no. 28: "Unidentified subscriber"

This cause indicates that the subscriber is not registered in the PLMN (i.e. IMSI not known).

Cause no. 29: "Facility rejected"

This cause indicates that the facility requested by the User Equipment is not supported by the PLMN.

Cause no. 30: "Unknown subscriber"

This cause indicates that the subscriber is not registered in the HLR (i.e. IMSI or directory number is not
allocated to a subscriber).

Cause no. 38: "Network out of order"

This cause indicates that the network is not functioning correctly and that the condition is likely to last a
relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be
successful.

Cause no. 41: "Temporary failure"

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long
period of time; e.g., the User Equipment may wish to try another short message transfer attempt almost
immediately.

Cause no. 42: "Congestion"

This cause indicates that the short message service cannot be serviced because of high traffic.

Cause no. 47: "Resources unavailable, unspecified"

This cause is used to report a resource unavailable event only when no other cause applies.

Cause no. 50: "Requested facility not subscribed"

This cause indicates that the requested short message service could not be provided by the network because the
user has not completed the necessary administrative arrangements with its supporting networks.

Cause no. 69: "Requested facility not implemented"

This cause indicates that the network is unable to provide the requested short message service.

Cause no. 81: "Invalid short message transfer reference value"

This cause indicates that the equipment sending this cause has received a message with a short message
reference which is not currently in use on the UE-network interface.

Cause no. 95: "Invalid message, unspecified"

This cause is used to report an invalid message event only when no other cause in the invalid message class
applies.

CWTS
 70 (TSM 04.11 version 1.0.0): December 2000

Cause no. 96: "Invalid mandatory information"

This cause indicates that the equipment sending this cause has received a message where a mandatory
information element is missing and/or has a content error (the two cases are indistinguishable).

Cause no. 97: "Message type non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message with a message type it does
not recognize either because this is a message not defined or defined but not implemented by the equipment
sending this cause.

Cause no. 98: "Message not compatible with short message protocol state"

This cause indicates that the equipment sending this cause has received a message such that the procedures do
not indicate that this is a permissible message to receive while in the short message transfer state.

Cause no. 99: "Information element non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message which includes information
elements not recognized because the information element identifier is not defined or it is defined but not
implemented by the equipment sending the cause.

However, the information element is not required to be present in the message in order for the equipment
sending the cause to process the message.

Cause no. 111: "Protocol error, unspecified"

This cause is used to report a protocol error event only when no other cause applies.

Cause no. 127: "Interworking, unspecified"

This cause indicates that there has been interworking with a network which does not provide causes for actions
it takes; thus, the precise cause for a message which is being send cannot be ascertained.

E-3: RP-cause definition mobile terminating SM-transfer

Cause no. 22: "Memory capacity exceeded"

This cause indicates that the user equipment cannot store the incoming short message due to lack of storage
capacity.

Cause no. 81: "Invalid short message reference value"

This cause indicates that the equipment sending this cause has received a message with a short message
reference which is not currently in use on the UE-network interface.

Cause no. 95: "Invalid message, unspecified"

This cause is used to report an invalid message event only when no other cause in the invalid message class
applies.

Cause no. 96: "Invalid mandatory information"

This cause indicates that the equipment sending this cause has received a message where a mandatory
information element is missing and/or has a content error (the two cases are indistinguishable).

Cause no. 97: "Message type non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message with a message type it does
not recognize either because this is a message not defined or defined but not implemented by the equipment
sending this cause.

Cause no. 98: "Message not compatible with short message protocol state"

This cause indicates that the equipment sending this cause has received a message such that the procedures do
not indicate that this is a permissible message to receive while in the short message transfer state.

CWTS
 71 (TSM 04.11 version 1.0.0): December 2000

Cause no. 99: "Information element non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message which includes information
elements not recognized because the information element identifier is not defined or it is defined but not
implemented by the equipment sending the cause.

However, the information element is not required to be present in the message in order for the equipment
sending the cause to process the message.

Cause no. 111: "Protocol error, unspecified"

This cause is used to report a protocol error event only when no other cause applies.

E-4: RP-Cause definition memory available notification

Cause no. 30: "Unknown Subscriber"

This cause indicates that the subscriber is not registered in the HLR (i.e. IMSI or directory number is not
allocated to a subscriber).

Cause no. 38: "Network out of order"

This cause indicates that the network is not functioning correctly and that the condition is likely to last a
relatively long period of time; e.g., immediately reattempting the short message transfer is not likely to be
successful.

Cause no. 41: "Temporary failure"

This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long
period of time; e.g., the User Equipment may wish to try another short message transfer attempt almost
immediately.

Cause no. 42: "Congestion"

This cause indicates that the short message service cannot be serviced because of high traffic.

Cause no. 47: "Resources unavailable, unspecified"

This cause is used to report a resource unavailable event only when no other cause applies.

Cause no. 69: "Requested facility not implemented"

This cause indicates that the network is unable to provide the requested memory available notification service.

Cause no. 95: "Invalid message, unspecified"

This cause is used to report an invalid message event only when no other cause in the invalid message class
applies.

Cause no. 96: "Invalid mandatory information"

This cause indicates that the equipment sending this cause has received a message where a mandatory
information element is missing and/or has a content error (the two cases are indistinguishable).

Cause no. 97: "Message type non-existent or not implemented"

This cause indicates that the equipment sending this cause has received a message with a message type it does
not recognize either because this is a message not defined or defined but not implemented by the equipment
sending this cause.

Cause no. 98: "Message not compatible with short message protocol state"

This cause indicates that the equipment sending this cause has received a message such that the procedures do
not indicate that this is a permissible message to receive while in the short message transfer state.

Cause no. 99: "Information element non-existent or not implemented"

CWTS
 72 (TSM 04.11 version 1.0.0): December 2000

This cause indicates that the equipment sending this cause has received a message which includes information
elements not recognized because the information element identifier is not defined or it is defined but not
implemented by the equipment sending the cause.

However, the information element is not required to be present in the message in order for the equipment
sending the cause to process the message.

Cause no. 111: "Protocol error, unspecified"

This cause is used to report a protocol error event only when no other cause applies.

Cause no. 127: "Interworking, unspecified"

This cause indicates that there has been interworking with a network which does not provide causes for actions
it takes; thus, the precise cause for a message which is being send cannot be ascertained.

CWTS
 73 (TSM 04.11 version 1.0.0): December 2000

Annex F (informative):
LAPDm SAPI 3 handling for short message service
This annex describes several typical SMS message transfer scenarios for circuit switched mode.

For packet switched mode SMS transfer, refer to TSM 03.60 for channel set up and upper layer message flow.

Case A: Mobile originating short message transfer, no parallel call.

The user equipmentside will initiate SAPI 3 establishment by a SABM command on the SDCCH (or on the
FACCH, if dedicated resurces have been assigned) after the cipher mode has been set. If no handover occurs, the
SAPI 3 link will stay up until the last CP-ACK is received by the MSC, and the clearing procedure is invoked.

Case B: Mobile terminating short message transfer, no parallel call.

The network side, i.e. the BSS will initiate SAPI3 establishment by a SABM command on the SDCCH (or on
the FACCH, if dedicated resources have been assigned) when the first CP-Data message is received from the
MSC. If no handover occurs, the link will stay up until the MSC has given the last CP-ack and invokes the
clearing procedure.

Case C: Mobile originating short message transfer, parallel call.

The user equipment will send a SABM command on the SACCH when a CM_SERV_ACC message has been
received from the network, allowing the short message transfer to start. If no handover occurs the link will stay
up until the MSC orders a explicit release, or the clearing procedure is invoked. If the parallel call is cleared
before the short message transfer is finalized, the MSC will delay the clearing procedure toward the BSS, i.e. the
channel release procedure is delayed.

Case D: Mobile terminating short message transfer, parallel call.

The network side, i.e. the BSS will initiate SAPI3 establishment by a SABM command on the SACCH when the
first CP-DATA message is received from the MSC. The further handling is exactly as described for case C.

Case E: Mobile terminating short message transfer together with Inter-MSC handover, parallel call.

The MAP procedures "Forward access signalling" and "Process access signalling" will be used between the two
MSCs to transfer the CP-DATA, CP-ACK and CP-ERROR messages.

Case F: Mobile terminating short message transfer on SDCCH (or on the FACCH, if dedicated resources have been
assigned) channel together with Inter-MSC handover.

The MAP procedures "Forward access signalling" and "Process access signalling" will be used between the two
MSC's to transfer the CP-DATA, CP-ACK and CP-ERROR messages.

CWTS
 74 (TSM 04.11 version 1.0.0): December 2000

UE BTS BSC MSC

CHANNEL:
SYNC

FACH PHYSICAL INFORMATION

RACH CHANNEL REQUEST CHAN RQD

CHAN ACTIV

CHAN CTIV ACK

AGCH IMM ASSIGN

SDCCH SABM (CM-SERV-REQ) EST IND (CM-SERV-REQ) CR (CM-SERV-REQ)

UA (CM-SERV-REQ)

AUTH REQ CC (AUTH REQ)

AUTH RES

CIPH MODE CMD ENCR CMD CIPH MODE CMD

CIPH MODE COM CIPH MODE COM

SABM (SAPI=3) EST IND (SAPI=3)

UA (SAPI=3)

CP-DATA To SC

CP-ACK

CP-DATA From SC

CP-ACK

CHAN RELEASE CLEAR CMD

DEACT SACCH

DISC (SAPI=0)

REL IND

UA (SAPI=0)

RF CHAN REL CLEAR COM

Local release
SAPI=3

Figure F1/TSM 04.11: Mobile originated Short Message on SDCCH

CWTS
 75 (TSM 04.11 version 1.0.0): December 2000

UE BTS BSC MSC

CHANNEL:
PCH PAGE REQUEST PAGING COMMAND PAGING From SC

SYNC1

FACH PHYSICAL INFORMATION

RACH CHANNEL REQUEST CHAN RQD

CHAN ACTIV

CHAN ACTIV ACK

AGCH IMM ASSIGN

SDCCH SABM (PAGE RESP) EST IND (PAGE RESP) CR (PAGE RESP)

UA (PAGE RESP)

AUTH REQ CC (AUTH REQ)

AUTH RESP

CIPH MODE CMD ENCR CMD CIPH MODE CMD

CIPH MODE COD CIPH MODE COD

SABM (SAPI=3) EST REQ (SAPI=3) CP-DATA

UA (SAPI=3) EST CONF (SAPI=3)

CP-DATA

CP-ACK

CP-DATA To SC

CP-ACK

CHAN RELEASE CLEAR CMD

DEACT SACCH

DISC (SAPI=0)

REL IND (SAPI=0)

UA (SAPI=0)

RF CHAN REL CLEAR COM

Local release
SAPI=3

Figure F2/TSM 04.11: Mobile terminated Short Message on SDCCH

CWTS
 76 (TSM 04.11 version 1.0.0): December 2000

UE BTS BSC MSC

CHANNEL:

ACTIVE CALL

CM SERV REQ
FACCH

CM SERV ACC

SABM (SAPI=3) EST IND (SAPI=3)

SACCH
UA (SAPI=3)
To SC
CP-DATA

CP-ACK

CP-DATA From SC

CP-ACK

ACTIVE CALL

Figure F3/TSM 04.11: Mobile originated Short Message on SACCH

CWTS
 77 (TSM 04.11 version 1.0.0): December 2000

UE BTS BSC MSC

CHANNEL:

ACTIVE CALL

FACCH

SABM (SAPI=3) EST REQ (SAPI=3) CP-DATA From SC

SACCH
UA (SAPI=3) EST CONF (SAPI=3)

CP-DATA

CP-ACK
To SC
CP-DATA

CP-ACK

ACTIVE CALL

Figure F4/TSM 04.11: Mobile terminated Short Message on SACCH

CWTS
 (TSM 04.1178
version 1.0.0): December 2000

UE BTS-A BSC-A MSC-A MSC-B

CHANNEL:
SACCH
CP-DATA
To SC
BSC-B BTS-B
CP-ACK
PREPARE HANDOVER
HANDO RQD
HANDO RQT CHAN ACTIV
PREPARE HANDOVER
ACK HANDO RQT ACK CHAN ACT ACK

IAM

HANDO CMD HANDO CMD ACM

FACCH
HANDO AC
Suspend SAPI=0 HANDO DET PHYSICAL
Local rel SAPI=3 HANDO DET
PROCESS ACCESS
SIGNALLING EST IND(0) SABM (SAP

UA (SAPI=

Send end signal HANDO COM HANDO CO

REL RF CHAN CLEAR CMD
Answer
RF CHAN REL ACK CLEAR COM
From SC
FORWARD ACCESS CP-DATA EST REQ (3) SABM (SAP
SIGNALLING
EST CONF (3) UA (SAPI=3

CP-DATA
PROCESS ACCESS
SIGNALLING CP-ACK

To SC

Figure F5/TSM 04.11: Inter/MSC handover during Short Message transfer on SACCH
 (TSM 04.1179
version 1.0.0): December 2000

UE BTS-A BSC-A MSC-A MSC-B

CHANNEL:
SDCCH
CP-DATA
To SC
BSC-B BTS-B
CP-ACK
PREPARE HANDOVER
HANDO RQD
HANDO RQT CHAN ACTIV
PREPARE HANDOVER
ACK HANDO RQT ACK CHAN ACT ACK

HANDO CMD HANDO CMD

HANDO AC
HANDO DET PHYSICAL
HANDO DET
PROCESS ACCESS
SIGNALLING EST IND(0) SABM (SAP

UA (SAPI=

Send end signal HANDO COM HANDO CO

REL RF CHAN CLEAR CMD

RF CHAN REL ACK CLEAR COM

From SC
FORWARD ACCESS CP-DATA EST REQ (3) SABM (SAP
SIGNALLING
EST CONF (3) UA (SAPI=3

CP-DATA
PROCESS ACCESS
SIGNALLING CP-ACK

To SC

Figure F6/TSM 04.11: Inter/MSC handover during Short Message transfer on SDCCH
 80 (TSM 04.11 version 1.0.0): December 2000

Annex G (informative):

History
Document history
DATE OLD_VERS NEW_VERS SUBJECT

22/08/00 0.0.1 0.0.1 First submission to CWTS

December 2000 0.0.1 0.0.2 Editorial Changes

December 2000 0.0.2 1.0.0 Version after approval of CWTS