8 Handling of unknown, unforeseen, and erroneous protocol data

04.183GPPMobile radio interface Layer 3 specificationRadio Resource Control (RRC) protocolRelease 1999TS

8.1 General

The procedures specified in 3GPP TS 04.18 and call-related supplementary service handling in 3GPP TS 24.010 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.

Error handling concerning the value part of the Facility IE and of the SS Version Indicator IE are not in the scope of the present document. It is defined in 3GPP TS 24.010 and the 3GPP TS 04.8x series.

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. sub-clauses 3, 4 and 5) of 3GPP TS 04.18, 3GPP TS 24.010, or relevant 3GPP TS 04.8x series.

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

8.3 Unknown or unforeseen transaction identifier

See 3GPP TS 24.008.

8.4 Unknown or unforeseen message type

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

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 sub-clause 3GPP TS 24.007); or

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

is received:

– the mobile station shall proceed as follows:

– If the message is not one of the messages listed in sub-clauses 8.5.1, 8.5.2 and 8.5.3 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".

– the network shall proceed as follows:

– When the message is not one of the messages listed in sub-clause 8.5.3 b), c), d) or e) and 8.5.5 a), b), d) or e), 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".

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 3.5 "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 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 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 upon receipt of a GMM or SM message diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives a GMM or SM message containing at least one syntactically incorrect conditional IE, it shall ignore the message and it shall return a status message (GMM STATUS or SM STATUS depending on the PD) with cause value # 100 "conditional IE error".

When the network receives a message and diagnose a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives a 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 04.18 (i.e. clause 3) 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 (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.

Semantic checking of the Facility information element value part (defined in 3GPP TS 24.080) is the subject of the technical specifications 3GPP TS 24.010 and the 3GPP TS 04.8x series.

8.9 Incomplete rest octets

When the number of octets in a rest octets information element is too low 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 explicit specified in the relevant rest octet definition.

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 fit into the rest octets.

{ < a > < b > < c > }

The above set may be truncated into:

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

{ < a > < b > } or

{ < a > } or

null