5 CM‑procedures

24.0113GPPPoint-to-Point (PP) Short Message Service (SMS) support on mobile radio interfaceRelease 17TS

5.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 CS in A/Gb and Iu mode, or the LLC layer for GPRS in A/Gb mode, or the GMM-connection for PS in Iu mode, or the EMM-connection for EPS in S1 mode if packet-switched service is used, or through the MME for S1 mode if circuit-switched service is used, or through the AMF for N1 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 service, the CM‑procedures described can only be performed if an MM‑connection has been established between the mobile station and the network.

For GPRS, no connection has to be established, and thus the CM procedures for GPRS reflect this. Detailed SDL diagrams for SMC entities are contained in annex B.

For EPS when packet-switched service is used, detailed SDL diagrams for SMC entities are contained in annex B.

5.2 Short Message Control states

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

5.2.1 SMC-CS states at the MS side of the radio interface

5.2.1.1 Mobile Originating Case

The states described in this clause are for an SMC entity in an MS 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").

5.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.

5.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.

5.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.

5.2.1.1.4 MO‑MM‑connection established (State 3)

This state exists when the MO‑SMC has:

– received the acknowledgement, CP‑ACK; or

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

5.2.1.2 Mobile Terminating case

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

5.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.

5.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.

5.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).

5.2.2 SMC-GP, SMC-EP and SMC-5G states at the MS side of the radio interface

5.2.2.1 Mobile Originating Case

The states described in this clause are for an SMC-GP entity in a GPRS MS, and for an SMC-EP entity in an EPS MS, and for an SMC-5G entity in a 5GS MS 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").

5.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.

5.2.2.1.2 MO‑GMM‑connection pending (State 1) (Iu mode only)

This state exists when the MO‑SMC has requested the establishment of a PS signalling connection.

5.2.2.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.

5.2.2.1.4 MO‑Wait for CP-Data (State 3)

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

5.2.2.1.5 MO‑EMM‑connection pending (State 4) (S1 mode only)

This state exists when the MO‑SMC has requested the establishment of a NAS signalling connection.

5.2.2.2 Mobile Terminating case

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

5.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.

5.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).

5.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.

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

5.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").

5.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.

5.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.

5.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).

5.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.

5.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.

5.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.

5.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.

5.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).

5.2.4 SMC-GP, SMC-EP and SMC-5G states at the network side of the radio interface

5.2.4.1 Mobile Originating Case

The states described in this subclause are for an SMC-GP entity in an SGSN and for an SMC-EP entity in an MSC or an MME and an SMC-5G entity in a SMSF 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").

5.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.

5.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).

5.2.4.1.3 MO‑Wait for CP-ACK(State 2)

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

5.2.4.2 Mobile Terminating Case

The states described in this subclause are for an SMC-GP entity in an SGSN and the SMC-EP entity in the MSC or the MME handling mobile terminating short message transfer.

5.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.

5.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.

5.2.4.2.3 MT‑Wait for CP DATA (State 2)

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

5.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 5.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.

5.3.1 MM‑connection establishment for circuit switched service

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 MS 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 3GPP TS 24.008 [5]). The destination side SMC entity then sends a CP‑ACK and enters the MM‑Connection Established state.

5.3.2 RPDU transfer

5.3.2.1 RPDU transfer for circuit switched service

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, hand over, assignment failure, hand over 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.

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.

5.3.2.2 RPDU transfer for GPRS, EPS and 5GS

In A/Gb mode, when an SMC-GP or SMC-EP entity is in the Idle state and transfer of an RPDU is requested, the SMC-GP or SMC-EP entity on the originating side forwards the CP‑DATA message containing the R-PDU to the lower layer, and sets the timer TC1* and enters the Wait for CP-ACK state. In A/Gb mode, for the SMC-GP entity, the lower layer is the LLC sublayer. For the SMC-EP entity on the MS side, the lower layer is EMM. For the SMC-EP entity on the network side, the lower layer can be either the SGs association as described in 3GPP TS 29.118 [12] or the EMM sublayer. For the SMC-5G entity on the MS side, the lower layer is 5GMM. For the SMC-5G entity on the network side the lower layer is provided by the Namf Service Based Interface as described in 3GPP TS 29.518 [16] and by the Nsmsf Service Based Interface as described in 3GPP TS 29.540 [17].

In Iu mode, when an SMC-GP entity in the MS side is in the Idle state and transfer of an RPDU is requested:

– the SMC-GP entity on the originating side requests the GMM sublayer to establish a PS signalling connection, and enters the GMM‑Connection Pending state.

– after completion of the PS signalling connection establishment, a confirmation is given to the originating side to indicate that the GMM sublayer is ready for RPDU transfer; and.

– after confirmation of the PS signalling connection establishment, the SMC-GP entity on the originating side forwards the CP‑DATA message to the GMM sublayer. This contains the RPDU, and also the SMC-GP entity sets the timer TC1* and enters the Wait for CP‑ACK state.

In S1 mode, when an SMC-EP entity in the MS side is in the Idle state and transfer of an RPDU is requested:

– if the MS is not using Control plane CIoT EPS optimization:

1) the SMC-EP entity on the originating side requests the EMM sublayer to establish a NAS signalling connection, and enters the EMM‑Connection Pending state;

2) after completion of the NAS signalling connection establishment, a confirmation is given to the originating side to indicate that the EMM sublayer is ready for RPDU transfer; and

3) after confirmation of the NAS signalling connection establishment, the SMC-EP entity on the originating side forwards the CP‑DATA message to the EMM sublayer. This contains the RPDU, and also the SMC-EP entity sets the timer TC1* and enters the Wait for CP‑ACK state; or

– if the MS is using Control plane CIoT EPS optimization, the SMC-EP entity on the originating side forwards the CP‑DATA message that contains the RPDU to the EMM sublayer when requesting the EMM sublayer to establish a NAS signalling connection. The SMC-EP entity then sets the timer TC1* and enters the Wait for CP‑ACK state immediately.

NOTE 1: If the MS in idle mode is using Control plane CIoT optimization, the first CP-DATA message is sent by piggybacking on the CONTROL PLANE SERVICE REQUEST message during the service request procedure as specified in 3GPP 24.301 [10].

In N1 mode, when an SMC-5G entity in the MS side is in the Idle state and transfer of an RPDU is requested:

– if the MS is not using Control plane CIoT 5GS optimization:

1) the SMC-5G entity on the originating side requests the 5GMM sublayer to establish a NAS signalling connection;

2) after completion of the NAS signalling connection establishment, a confirmation is given to the originating side to indicate that the 5GMM sublayer is ready for RPDU transfer; and

3) after confirmation of the NAS signalling connection establishment, the SMC-5G entity on the originating side forwards the CP‑DATA message to the 5GMM sublayer. This contains the RPDU, and also the SMC-5G entity sets the timer TC1* and enters the Wait for CP-ACK state; and

– if the MS is using Control plane CIoT 5GS optimization, the SMC-5G entity on the originating side forwards the CP‑DATA message that contains the RPDU to the 5GMM sublayer when requesting the 5GMM sublayer to establish a NAS signalling connection. The SMC-5G entity then sets the timer TC1* and enters the Wait for CP‑ACK state immediately.

NOTE2: If the MS in idle mode is using Control plane CIoT optimization, the first CP-DATA message is sent by piggybacking on the CONTROL PLANE SERVICE REQUEST message during the service request procedure as specified in 3GPP 24.501 [15].

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

In S1 mode and the circuit-switched service is used, when an SMC-EP entity in the network side is in Idle state and transfer of an RPDU is requested, the SMC-EP entity on the MSC forwards the CP‑DATA message to the SGs sublayer. This contains the RPDU, and also the SMC-EP entity sets the timer TC1* and enters the Wait for CP‑ACK state. The SGs layer transfers the CP-DATA message by using the procedures specified in 3GPP 24.301 [10].

In S1 mode and the packet-switched service is used, when an SMC-EP entity in the network side is in Idle state and transfer of an RPDU is requested, the SMC-EP entity on the originating side forwards the CP‑DATA message to the EMM sublayer. This contains the RPDU, and also the SMC-GP entity sets the timer TC1* and enters the Wait for CP‑ACK state.

In N1 mode and the packet-switched service is used, when an SMC-5G entity in the network side is in Idle state and transfer of an RPDU is requested, the SMC-5G entity on the SMSF forwards the CP-DATA message to the N20 sublayer. This contains the RPDU, and also the SMC-5G 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.

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-5G 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-5G resets the timer TC1* and enters the Idle State.

In A/Gb mode or S1 mode, when receiving a CP‑DATA message form the lower layer, the SMC-GP or SMC-EP 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.

In Iu mode, when receiving a CP‑DATA message from the GMM 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.

In S1 mode, when receiving a CP‑DATA message from the lower layer, the SMC-EP 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.

In N1 mode, when receiving a CP-‑DATA message from the lower layer, the SMC-5G 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.

5.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.

5.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.

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 MS 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 mobile station 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.

It is possible that the CP‑ACK of a short message transfer might not be received (e.g. due to hand over). 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.

5.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 A/Gb mode) or the signalling connection (in Iu mode and in S1 mode if packet-switched service is used, and in N1 mode) in between transfers. For mobile terminated short messages this is simple because the network decides when, and whether, to release the RR connection (in A/Gb mode) or the signalling connection (in Iu mode and in S1 mode if packet-switched service is used, and in N1 mode). However, for mobile originated transfers, the network does not know whether or not the mobile has more messages to transfer. For short message transfer through the EPS in S1 mode if circuit-switched service is used, the network side has no knowledge of the signalling connection in for both mobile originated and mobile terminated transfers.

If another short message or a memory available notification is to be sent, an originating SMR entity in the MS may choose to continue to use the same RR connection (in A/Gb mode) or the same signalling connection (in Iu mode or in N1 mode).

In the case of a SMS transfer via the CS domain, when the MS chooses to use the same RR connection (in A/Gb mode) or CS signalling connection (in Iu mode), then:

– the MS shall transmit a CM SERVICE REQUEST for the new CM connection before the final CP‑ACK (i.e. 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 MS may transmit the CP‑ACK for the old MM connection; the MS shall not transmit the final CP-ACK after the new CP-DATA;

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

– the MS 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.

In the case of a SMS transfer via the PS domain, when the MS chooses to use the same PS signalling connection (in Iu mode and in S1 mode if packet-switched service is used); or in the case of a SMS transfer via the PS domain in A/Gb mode; or in the case of SMS transfer through the EPS, or in the case of SMS transfer in N1 mode, then:

– the MS shall transmit the CP-DATA for the successive RPDU and shall not transmit the final CP‑ACK for the current SMS (i.e. the one that acknowledges the CP‑DATA that carried the RP‑ACK);

– the Transaction Identifier used for the successive RPDU shall be different to that used for the current RPDU; and

– the MS shall not transmit the CP-DATA for the successive RPDU before the final CP‑DATA (i.e. the one that carried the RP‑ACK) has been received.

NOTE: When an MS sends successive memory available notifications and/or mobile originated short messages on different RR connections (in A/Gb mode) or signalling connections (in Iu mode and S1 mode), the MS is strongly recommended to use different Transaction Identifiers for the old and new MM connections.

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 hand overs).

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 or not sent by the MS, the following events shall be interpreted as the implicit reception of the awaited CP‑ACK:

– in the case of a SMS transfer via the CS domain,, the reception of a CM SERVICE REQUEST followed by a CP‑DATA with a different transaction identifier and carrying an RPDU; or

– in the case of a SMS transfer via the PS domain, the reception of a CP-DATA with a different transaction identifier and carrying an RPDU.