3 Service definition
24.0113GPPPoint-to-Point (PP) Short Message Service (SMS) support on mobile radio interfaceRelease 17TS
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 24‑series of 3GPP 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 MS communicates with an SMC entity in the MSC or the SGSN or the MME or the SMSF 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 mobile station supporting the Short Message Service shall have a minimum of two SMC entities per service type (i.e. two for CS GSM and two for GPRS). This enables the MS to receive MT messages during an MO message transfer.
To ensure that an MS 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 the SGSN or the MME or the SMSF shall have a minimum of two SMC entities available each during an MT message transfer to a mobile station, one being reserved for MO message transfer. In an MO message transfer, the MSC or the SGSN or the MME or the SMSF shall have one SMC entity reserved for handling of an MT message.
3.2.1 Definition of primitives on the MS side
This subclause defines the service primitives used on the MS side. Table 3.1/3GPP TS 24.011 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/3GPP TS 24.011: MNSMS service primitives on the MS‑side
|
SERVICE PRIMITIVES |
PARAMETER |
|
|
NAME |
TYPE |
|
|
MNSMS‑ABORT‑ |
Req |
Cause |
|
MNSMS‑DATA- |
Req |
MO RPDU |
|
Ind |
MT 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.
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/3GPP TS 24.011 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/3GPP TS 24.011: MNSMS service primitives on the network side
|
SERVICE PRIMITIVES |
PARAMETER |
|
|
NAME |
TYPE |
|
|
MNSMS‑ABORT‑ |
Req |
Cause |
|
MNSMS‑DATA- |
Req |
MT RPDU |
|
Ind |
MO 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.
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 Mobile Station.
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 MS 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.
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 MS side
This subclause defines the service primitives used on the MS side. Table 3.3/3GPP TS 24.011 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/3GPP TS 24.011: SM‑RL service primitives on the mobile station 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 |
|
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 mobile station 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.
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 mobile station. 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 mobile station 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/3GPP TS 24.011 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/3GPP TS 24.011: 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 |
|
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 mobile station.
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.
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 mobile station. 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.