9 Handling of unknown, unforeseen, and erroneous protocol data

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

9.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 MS 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 3GPP TS 24.011.

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

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.

9.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 3GPP TS 24.007 [4].

9.2.2 Unknown or unforeseen transaction identifier

The Mobile Station 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 mobile station 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 Mobile Station shall ignore a CP‑ERROR message that is received specifying a Transaction Identifier which is not associated with an active SM transfer. The Mobile Station 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.

9.2.3 Unknown or unforeseen message type

If the Mobile Station 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 3GPP TS 24.007 [4].

If the Mobile Station receives a message not consistent with the protocol state, the Mobile Station 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.

9.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 mobile station shall proceed as follows.

When the corresponding SM transfer is not seen as successfully transferred, i.e. the transaction is not completed, the mobile station 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 mobile station shall ignore the message and enter the Idle State.

In the case that the message received is a CP‑ERROR message, the mobile station shall ignore the message and enter the Idle State.

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

9.2.5 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of 3GPP TS 24.011 are performed. If however no such reactions are specified, the mobile station shall proceed as follows:

– when the corresponding SM transfer is not seen as successfully transferred, the mobile station 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 mobile station shall ignore the message and enter the Idle State;

– in the case that the message received is a CP‑ERROR message, the mobile station shall ignore the message and enter the Idle State.

The network may follow the same procedure.

9.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 6.

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

9.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 mobile station 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 mobile station shall discard the message. If that discarded RP-ERROR message was part of MT SM transaction a request to abort the CM-connection shall be passed to the CM-sublayer.

When the mobile station’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.

9.3.3 Unknown or unforeseen message type

If the Mobile Station 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 Mobile Station receives a message (except RP‑ERROR) not consistent with the protocol state, the Mobile Station 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 Mobile Station receives an RP‑ERROR message not consistent with the protocol state, the Mobile Station shall ignore the message. If that discarded RP-ERROR message was part of MT SM transaction a request to abort the CM-connection shall be passed to the CM-sublayer.

The network may follow the same procedures.

9.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 mobile station 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 mobile station shall 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.

9.3.5 Messages with semantically incorrect contents

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

– if the message was not an RP‑ERROR message, the MS 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 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 same procedure.