8 Handling of unknown, unforeseen, and erroneous protocol data

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

8.1 General

The procedures specified in 3GPP TS 24.008 and call-related supplementary service handling in 3GPP TS 24.010 [21] apply to those messages which pass the checks described in this subclause.

This subclause 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 [21] and the 3GPP TS 24.08x series.

Sub subclauses 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 subclause 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 subclauses 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.

For definition of semantical and syntactical errors see 3GPP TS 24.007 [20], subclause 11.4.2.

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 [20].

8.3 Unknown or unforeseen transaction identifier

8.3.1 Call Control

The mobile station and the network shall ignore a Call Control message received with TI EXT bit = 0. Otherwise, if the TI EXT bit =1 or no extension is used, the behaviour described below shall be followed.

The mobile station and network shall reject a SETUP, EMERGENCY SETUP or START CC message received with octet 1 part of the TI value coded as "111" by sending RELEASE COMPLETE with cause #81 "Invalid transaction identifier value" The TI value in RELEASE COMPLETE shall be the complete TI value including the extension octet from the message that caused the rejection.

Any message other than SETUP, EMERGENCY SETUP or START CC received with octet 1 part of the TI value coded as "111" shall be ignored.

For a call control message received with octet 1 part of the TI value not coded as "111", the following procedures shall apply:

a) For a network that does not support the "Network initiated MO call" option and for all mobile stations:

Whenever any call control message except EMERGENCY SETUP, SETUP or RELEASE COMPLETE is received specifying a transaction identifier which is not recognized as relating to an active call or to a call in progress, the receiving entity shall send a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and remain in the Null state.

For a network that does support the "Network initiated MO call" option $(CCBS)$:

Whenever any call control message except EMERGENCY SETUP, SETUP, START CC or RELEASE COMPLETE is received specifying a transaction identifier which is not recognized as relating to an active call or to a call in progress, the receiving entity shall send a RELEASE COMPLETE message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and remain in the Null state.

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

c) For a network that does not support the "Network initiated MO call" option and for all mobile stations:

When an EMERGENCY SETUP or, a SETUP message is received specifying a transaction identifier which is not recognized as relating to an active call or to a call in progress, and with a transaction identifier flag incorrectly set to "1", this message shall be ignored.

For a network that does support the "Network initiated MO call" option $(CCBS)$:

When an EMERGENCY SETUP, a START CC or, a SETUP message is received specifying a transaction identifier which is not recognised as relating to an active call or to a call in progress, and with a transaction identifier flag incorrectly set to "1", this message shall be ignored.

d) When a SETUP message is received by the mobile station specifying a transaction identifier which is recognized as relating to an active call or to a call in progress, this SETUP message shall be ignored.

e) For a network that does not support the "Network initiated MO call" option:

When an EMERGENCY SETUP message or a SETUP message is received by the network specifying a transaction identifier which is recognized as relating to an active call or to a call in progress, this message need not be treated and the network may perform other actions.

For a network that does support the "Network initiated MO call" option $(CCBS)$:

When an EMERGENCY SETUP message or a START CC message is received by the network specifying a transaction identifier which is recognised as relating to an active call or to a call in progress, this message need not be treated and the network may perform other actions.

The same applies to a SETUP message unless the transaction has been established by a START_CC message and the network is in the "recall present" state (N0.6).

8.3.2 Session Management

The mobile station and network shall ignore a session management message with TI EXT bit = 0. Otherwise, the following procedures shall apply:

a) Whenever any session management message except ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST, or SM-STATUS is received by the network specifying a transaction identifier which is not recognized as relating to an active PDP context or MBMS context,or to a PDP context or MBMS context that is in the process of activation or deactivation, the network shall send a SM-STATUS message with cause #81 "invalid transaction identifier value" using the received transaction identifier value including the extension octet and remain in the PDP-INACTIVE state.

b) Whenever any session management message except REQUEST PDP CONTEXT ACTIVATION, REQUEST SECONDARY PDP CONTEXT ACTIVATION, REQUEST MBMS CONTEXT ACTIVATION, or SM-STATUS is received by the MS specifying a transaction identifier which is not recognized as relating to an active context or to a context that is in the process of activation or deactivation, the MS shall send a SM-STATUS message with cause #81 "invalid transaction identifier value" using the received transaction identifier value including the extension octet and remain in the PDP-INACTIVE state.

c) When a REQUEST PDP CONTEXT ACTIVATION message, REQUEST SECONDARY PDP CONTEXT ACTIVATION message or REQUEST MBMS CONTEXT ACTIVATION message is received by the MS with a transaction identifier flag set to "1", this message shall be ignored.

d) When an ACTIVATE PDP CONTEXT REQUEST message is received by the network specifying a transaction identifier which is not recognized as relating to a PDP context that is in the process of activation, and with a transaction identifier flag set to "1", this message shall be ignored.

e) Whenever an ACTIVATE PDP CONTEXT REQUEST or ACTIVATE SECONDARY PDP CONTEXT REQUEST message is received by the network specifying a transaction identifier relating to a PDP context or MBMS context not in state PDP-INACTIVE, the network shall deactivate the old PDP context or MBMS context relating to the received transaction identifier without notifying the MS. Furthermore, the network shall continue with the activation procedure of a new PDP context as indicated in the received message. Whenever an ACTIVATE MBMS CONTEXT REQUEST message is received by the network specifying a transaction identifier relating to an MBMS context not in state PDP-INACTIVE, the network shall deactivate the old MBMS context relating to the received transaction identifier without notifying the MS. Furthermore, the network shall continue with the activation procedure of a new MBMS context as indicated in the received message.

f) Whenever a REQUEST PDP CONTEXT ACTIVATION message or REQUEST SECONDARY PDP CONTEXT ACTIVATION message is received by the MS specifying a transaction identifier relating to a PDP context or MBMS context not in state PDP-INACTIVE, the MS shall locally deactivate the old PDP context or MBMS context relating to the received transaction identifier. Furthermore, the MS shall continue with the activation procedure of a new PDP context as indicated in the received message.

Whenever a REQUEST MBMS CONTEXT ACTIVATION message is received by the MS specifying a transaction identifier relating to a PDP context or MBMS context not in state PDP-INACTIVE, the MS shall locally deactivate the old PDP context or MBMS context relating to the received transaction identifier. Furthermore, the MS shall continue with the activation procedure of a new MBMS context as indicated in the received message.

g) When an ACTIVATE SECONDARY PDP CONTEXT REQUEST message is received by the network specifying a transaction identifier which is not recognized as relating to a PDP context that is in the process of activation and with a transaction identifier flag set to "1", this message shall be ignored.

8.4 Unknown or unforeseen message type

If a mobile station receives an RR, MM or CC 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, MM or CC message with message type not defined for the PD or not implemented by the receiver in acknowledged mode, it shall return a status message (STATUS, MM STATUS depending on the protocol discriminator) with cause # 97 "message type non-existent or not implemented".

If a mobile station receives a GMM message or SM message with message type not defined for the PD or not implemented by the receiver, it shall return a status message (GMM STATUS or SM STATUS depending on the protocol discriminator) with cause # 97 "message type non-existent or not implemented".

If the network receives an MM 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 (STATUS, MM STATUS, GMM STATUS or SM STATUS depending on the protocol discriminator) 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 [20].

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 (STATUS, MM STATUS depending on the protocol discriminator) with cause #98 "Message type not compatible with protocol state". When the message was a GMM message the GMM-STATUS message with cause #98 "Message type not compatible with protocol state" shall be returned. When the message was a SM message the SM-STATUS message with cause #98 "Message type not compatible with protocol state" shall be returned.

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

NOTE: The use by GMM and SM of unacknowledged LLC may lead to messages "not compatible with the protocol state".

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 [20]); or

– an out of sequence IE encoded as "comprehension required" (see 3GPP TS 24.007 [20]) is received,

the mobile station shall proceed as follows:

If the message is not one of the messages listed in subclauses 8.5.1, 8.5.2, 8.5.3, 8.5.4 and 8.5.5 a), b) , f) or h), the mobile station shall ignore the message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, MM STATUS depending on the protocol discriminator) with cause # 96 "Invalid mandatory information". If the message was a GMM message the GMM-STATUS message with cause #96 " Invalid mandatory information" shall be returned. If the message was an SM message the SM-STATUS message with cause # 96 "invalid mandatory information" shall be returned.

– the network shall proceed as follows:

When the message is not one of the messages listed in subclause 8.5.3 b), c), d) or e) and 8.5.5 a), c), d), e) or g), 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 (STATUS, or MM STATUS (depending on the protocol discriminator), GMM STATUS, or SM STATUS) with cause # 96 "Invalid mandatory information".

8.5.1 Radio resource management

See 3GPP TS 44.018 [84].

8.5.2 Mobility management

No exceptional cases are described for mobility management messages.

8.5.3 Call control

a) If the message is a SETUP message, a RELEASE COMPLETE message with cause # 96 "invalid mandatory information" shall be returned.

b) If the message is a DISCONNECT message, a RELEASE message shall be returned with cause value # 96 "invalid mandatory information" and subclause 5.4. "call clearing" applies as normal.

c) If the message is a RELEASE message, a RELEASE COMPLETE message shall be returned with cause value # 96 "invalid mandatory information".

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

e) If the message is a HOLD REJECT or RETRIEVE REJECT message, it shall be treated as a normal HOLD REJECT or RETRIEVE REJECT message.

f) If the message is a STATUS message and received by the network, a RELEASE COMPLETE message may be returned with cause value # 96 "invalid mandatory information".

8.5.4 GMM mobility management

No exceptional cases are described for mobility management messages.

8.5.5 Session management

a) If the message is a DEACTIVATE PDP CONTEXT REQUEST, a DEACTIVATE PDP CONTEXT ACCEPT message shall be returned. All resources allocated for that context shall be released.

b) If the message is a REQUEST PDP CONTEXT ACTIVATION, a REQUEST PDP CONTEXT ACTIVATION REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

c) If the message is an ACTIVATE PDP CONTEXT REQUEST, an ACTIVATE PDP CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

d) If the message is an ACTIVATE SECONDARY PDP CONTEXT REQUEST, an ACTIVATE SECONDARY PDP CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

e) If the message is a MODIFY PDP CONTEXT REQUEST, a MODIFY PDP CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

f) If the message is a REQUEST MBMS CONTEXT ACTIVATION, a REQUEST MBMS CONTEXT ACTIVATION REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

g) If the message is an ACTIVATE MBMS CONTEXT REQUEST, an ACTIVATE MBMS CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

h) If the message is a REQUEST SECONDARY PDP CONTEXT ACTIVATION, a REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

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 [20]).

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 [20]).

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, MM or CC message diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives an RR, MM or CC 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 (STATUS, or MM STATUS depending on the PD) 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 (STATUS, MM STATUS, GMM STATUS or SM STATUS depending on the protocol discriminator) 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 24.008 (i.e. of clauses 3, 4, 5, 6) 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 (STATUS, or MM STATUS depending on the PD) with cause value # 95 "semantically incorrect message". If the message was a GMM message the GMM-STATUS message with cause #95 "semantically incorrect message" shall be returned. If the message was an SM message the SM-STATUS message with cause # 95 "semantically incorrect message" shall be returned.

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 [24]) is the subject of the technical specifications 3GPP TS 24.010 [21] and the 3GPP TS 24.08x series.