8 Handling of unknown, unforeseen, and erroneous protocol data

04.633GPPPacket Data on Signalling channels Service (PDS) Service Description, Stage 3TS

8.1 General

This section specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the receiving PDSS1 or PDSS2 protocol 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.

Subclauses 8.1 to 8.8 shall be applied in order of precedence.

Most error handling procedures are mandatory for the MS.

Detailed error handling procedures in the network are implementation dependent and may vary from PLMN to PLMN. However, when extensions of this protocol are developed, networks will be assumed to have the error handling that is indicated in this section as mandatory ("shall") and that is indicated as strongly recommended ("should"). Subclauses 8.2, 8.3, 8.4, 8.5 and 8.7.2 do not apply to the error handling in the network applied to the receipt of initial layer 3 message: If the network diagnoses an error described in one of these sections in the initial layer 3 message received from the mobile station, it shall either:

– try to recognize the classmark and then take further implementation dependent actions, or

– release the RR-connection.

Also, the error handling of the network is only considered as mandatory or strongly recommended when certain thresholds for errors are not reached during a dedicated connection.

In this section 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" in subclause 10, or if its value part violates rules of subclause 10. However it is not a syntactical error that a TLV encoded IE specifies in its length indicator a greater length than defined in subclause 10.

– 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 sections 6 and 7.

8.2 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 GSM 04.07.

8.3 Unknown or unforeseen transaction identifier

The mobile station and network shall answer to a message received with TI value "111" by sending a RELEASE COMPLETE message with same TI value and cause "invalid transaction identifier value". For a call control message received with TI different from "111", the following procedures shall apply:

a) Whenever a message except a SETUP or RELEASE COMPLETE is received specifying a transaction identifier which is not recognized as relating to an active transaction, the receiving entity shall send a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and remain idle.

b) When a RELEASE COMPLETE message is received specifying a transaction identifier which is not recognized as relating to an active transaction, the MM connection associated with that transaction identifier shall be released.

c) When a SETUP message is received with:

– a transaction identifier which is not recognized as relating to an active transaction, and

– TI flag value 1;

the receiving entity shall send a RELEASE COMPLETE message with cause "invalid transaction identifier value" and not including diagnostics using the received transaction identifier value and remain idle.

d) When a SETUP message is received specifying a transaction identifier which is recognized as relating to an active call or to a call in progress, this SETUP message shall be treated as a message not compatible with the protocol state, see subclause 8.4.

8.4 Unknown or unforeseen message type

If the protocol entity in 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 except for the fact that, if an RR connection exists, it shall return a STATUS message with cause "message type non-existent or not implemented" and including as diagnostics the message type of the message received.

If the protocol entity in the network receives a message with message type not defined for the PD or not implemented by the receiver, it shall ignore the message except that it should return a STATUS message with cause "message type non‑existent or not implemented" and including as diagnostics the message type of the message received.

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 GSM 04.07.

1) If the protocol entity in the mobile station receives a message not compatible with the protocol state, the mobile station shall ignore the message except for the fact that, if an RR connection exists, it returns a STATUS message with cause "message type not compatible with protocol state" and including as diagnostics the message type of the message received.

If the network receives a message not compatible with the protocol state, the network actions are implementation dependent.

8.5 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, or

– an IE unknown in the message, but encoded as "comprehension required" (see GSM 04.08, subclause 10.5), or

– an out of sequence IE encoded as "comprehension required" (see GSM 04.08, subclause 10.5);

is received;

– the mobile station shall proceed as follows:

When the message is not one of the messages listed in section 8.5.1, the mobile station shall ignore the message except for the fact that, if an RR connection exists, it shall return a STATUS message with cause "invalid mandatory information" and including, if possible, as diagnostics the complete message received (this may not be possible, e.g., due to length restrictions).

– the network shall proceed as follows:

When the message is not one of the message listed in section 8.5.1 the network shall either:

– try to treat the message (the exact further actions are implementation dependent), or

– ignore the message except that it should return a STATUS message with cause "invalid mandatory information", possibly including as diagnostics the complete message received.

8.5.1 Special cases

1) If the message is a SETUP message and received by the mobile station, a RELEASE COMPLETE message shall be returned with cause "invalid mandatory information" and including, if possible, as diagnostics the complete message received (this may not be possible, e.g., due to length restrictions).

2) If the message is a SETUP message and received by the network, a RELEASE COMPLETE message shall be returned with cause "invalid mandatory information" and possibly including as diagnostics the complete message received.

3) If the message is a RELEASE COMPLETE message, it shall be treated as a normal RELEASE COMPLETE message.

4) If the message is a STATUS message and received by the network, a RELEASE COMPLETE message may be returned with cause value "invalid mandatory information" and possibly including as diagnostics the complete message received.

8.6 Unknown and unforeseen information elements in the non‑imperative message part

8.6.1 Information elements unknown in the message

The protocol entity shall ignore all information elements unknown in a message which are not encoded as "comprehension required".

8.6.2 Out of sequence information elements

The MS shall ignore all out of sequence Information elements in a message which are not encoded as "comprehension required".

The network should take the same approach.

8.6.3 Repeated Information elements

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information element is not specified in section 9 of the present document, only the contents of the information element appearing first shall be handled and all subsequent repetitions of the information element shall be ignored. When repetition of information elements is specified, only the contents of specified repeated information elements shall be handled. If the limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored.

The network should follow the same procedures.

8.7 Non-imperative message part errors

This category includes:

– syntactically incorrect optional Information elements;

– conditional IE errors.

8.7.1 Syntactically incorrect optional Information elements

The protocol entity shall treat all optional Information elements that are syntactically incorrect in a message as not present in the message.

8.8 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of sections 6 and 7 are performed. If however no such reactions are specified, the MS shall ignore the message except for the fact that, if an RR connection exists, it returns a STATUS message with cause value "semantically incorrect message" and including, if possible, as diagnostics the complete message received (this may not be possible, e.g., due to length restrictions).

The network should follow the same procedure except that a status message is not normally transmitted.