7 Handling of unknown, unforeseen, and erroneous protocol data

3GPP44.068Group Call Control (GCC) protocolRelease 17TS

7.1 General

This subclause specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the receiving GCC protocol entity in the MS. 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. Error handling procedures in the network are for further study.

Subclauses 7.1 to 7.8 shall be applied in order of precedence.

Most error handling procedures are mandatory for the MS.

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

– 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 (i.e. clauses 6 and 7) of the present document.

7.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 3GPP TS 24.007.

7.3 Unknown or unforeseen transaction identifier

If COMM = T, the MS shall answer to a message received with TI value "111" by sending a STATUS message with same TI value, cause "invalid transaction identifier value", and including, if possible, as diagnostics the complete message received (this may not be possible, e.g. due to length restrictions). If COMM = F, the MS shall ignore a message received with TI value "111".

For a group call control message received with TI different from "111", the following procedures shall apply.

Whenever a message is received specifying a transaction identifier which is not recognized as relating to an active transaction, if COMM = F, the MS shall ignore the message; if COMM = T, the MS shall send a STATUS message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and including, if possible, as diagnostics the complete message received (this may not be possible, e.g. due to length restrictions). and remain idle.

7.4 Unknown or unforeseen message type

If the protocol entity in the MS 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 COMM = T, 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.

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.

If the protocol entity in the MS receives a message not compatible with the protocol state, the MS shall ignore the message except for the fact that, if COMM = T, 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.

7.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 3GPP TS 24.008, subclause 10.5); or

– an out of sequence IE encoded as "comprehension required" (see 3GPP TS 24.008, subclause 10.5);

is received:

– the MS shall, if COMM = F, ignore the message. Otherwise it shall proceed as follows:

– the MS shall ignore the message except for the fact that 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).

7.6 Unknown and unforeseen information elements in the non-imperative message part

7.6.1 Information elements unknown in the message

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

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

7.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 clause 8, 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.

7.7 Non-imperative message part errors

This category includes:

– syntactically incorrect optional Information elements;

– conditional IE errors.

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

7.8 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part (i.e. of clauses 5 and 6) of the present document are performed. If however no such reactions are specified, the MS shall ignore the message except for the fact that, if COMM = T, 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).