8 Handling of unknown, unforeseen, and erroneous protocol data

3GPP44.018GSM/EDGE Radio Resource Control (RRC) protocolMobile radio interface Layer 3 specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 General

The procedures specified in this technical specification apply to those messages which pass the checks described in this sub-clause.

This sub-clause also specifies procedures for the 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.

Sub-clauses 8.1 to 8.8 shall be applied in order of precedence.

Most error handling procedures are mandatory for the mobile station.

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 sub-clause as mandatory ("shall") and that is indicated as strongly recommended ("should"). Sub-clauses 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 sub-clauses 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 sub-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 sub-clause 10, or if its value part violates rules of clause 10. However it is not a syntactical error that a type 4 IE specifies in its length indicator a greater length than defined in clause 10.

– A message is defined to have semantically incorrect contents if it contains information which, possibly dependent on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part (i.e. Clauses 3, 4, 5) of this technical specification.

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

8.3 (void)

8.4 Unknown or unforeseen message type

If a mobile station or the network receives a GTTP message with message type not defined for the PD or not implemented by the receiver, it shall ignore the message.

If a mobile station receives an RR message with message type not defined for the PD or not implemented by the receiver in unacknowledged mode, it shall ignore the message.

If a mobile station in packet idle mode has enabled EC operation then it shall interpret RR messages received on the EC-CCCH as described in sub-clause 10.1.

If a mobile station receives an RR message with message type not defined for the PD or not implemented by the receiver in acknowledged mode, it shall return a status message (RR STATUS) with cause # 97 "message type non-existent or not implemented".

If the network receives an RR message with message type not defined for the PD or not implemented by the receiver in a protocol state where reception of an unsolicited message with the given PD from the mobile station is not foreseen in the protocol, the network actions are implementation dependent. Otherwise, if the network receives an RR 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 (RR STATUS) with cause #97 "message type non-existent or not implemented".

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 mobile station receives an RR 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 (RR STATUS) with cause #98 "Message type not compatible with protocol state".

If the network receives an RR 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 3GPP TS 24.007); or

– an out of sequence IE encoded as "comprehension required" (see 3GPP TS 24.007);

is received:

– the mobile station shall proceed as follows:

– for RR protocol, if the message is not one of the messages listed in sub-clause 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 (RR STATUS) with cause # 96 "Invalid mandatory information";

– for GTTP, the mobile station shall ignore the message.

– the network shall proceed as follows:

– for RR protocol, 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 (RR STATUS) with cause # 96 "Invalid mandatory information".

– for GTTP, the network shall ignore the message.

8.5.1 Radio resource management

For the mobile station the following procedures shall apply:

a) If the message is a CHANNEL RELEASE message, the actions taken shall be the same as specified in sub-clause 3.4.13 "RR connection release".

b) If the message is a PARTIAL RELEASE message, the reactions of the MS are for further study.

8.6 Unknown and unforeseen IEs in the non-imperative message part

8.6.1 IEIs unknown in the message

The MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required" (see 3GPP TS 24.007).

The network shall take the same approach.

8.6.2 Out of sequence IEs

The MS shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required" (see 3GPP TS 24.007).

The network should take the same approach.

8.6.3 Repeated IEs

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 9 of this technical specification, 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 IEs;

– conditional IE errors.

8.7.1 Syntactically incorrect optional IEs

The MS shall treat all optional IEs that are syntactically incorrect in a message as not present in the message.

The network shall take the same approach.

8.7.2 Conditional IE errors

When the MS upon receipt of an RR message diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives an RR message containing at least one syntactically incorrect conditional IE, it shall ignore the message except for the fact that, if an RR connection exists, it shall return a status message (RR STATUS) with cause value # 100 "conditional IE error".

When the MS or the network upon receipt of a GTTP message diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives a GTTP message containing at least one syntactically incorrect conditional IE, it shall ignore the message.

When the network receives an RR message and diagnose a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives an RR message containing at least one syntactically incorrect conditional IE, 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 (RR STATUS) with cause # 100 "conditional IE error".

8.8 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of 3GPP TS 44.018 are performed. If however no such reactions are specified, the MS shall ignore the message except for the RR protocol in which case, if an RR connection exists, it returns a status message (RR STATUS) with cause value # 95 "semantically incorrect message".

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

8.9 Incomplete rest octets

When the number of octets in a rest octets information element is too small to contain the complete set of components, these components may be truncated by the sending entity (i.e. the network) to fit into the rest octets information element. Whether or not truncation is allowed depends on the construction of the rest octets information element and must be explicitly specified in the relevant rest octet definition (truncated concatenation).

If truncation is allowed, the mobile station shall assume the value ‘L’ for the missing components.

If the trunctation is not specified for the relevant rest octet definition, the sending entity must ensure that the complete set of components fits into the rest octets.

A truncated concatenation is an ordered sequence of components encapsulated in curly brackets and followed by the ‘//’ postfix. The components are the terms appearing at the first level of the concatenation construction.

The truncated concatenation is equivalent either to the null string or to a concatenation including any number of the components of the sequence put in the same consecutive order and starting with the first component.

As an example, the set:

{ < a > < b > < c > }//

is equivalent to:

{ < a > < b > < c > } or

{ < a > < b > } or

{ < a > } or

null