## 8 Handling of unknown, unforeseen, and erroneous protocol data

04.083GPPMobile radio interface Layer 3 specificationRelease 1998TS

## 8.1 General

The procedures specified in 3GPP TS 04.08 and call-related supplementary service handling in 3GPP TS 04.10 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 04.10 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 sub-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, 5) of 3GPP TS 04.08, 3GPP TS 04.10, 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, cf. 3GPP TS 04.07.

## 8.3 Unknown or unforeseen transaction identifier

### 8.3.1 Call Control

The mobile station and network shall ignore a call control message received with TI value "111". For a call control message received with TI different from "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 reject a session management message other than SM-STATUS received with TI value "111" by immediately sending an SM-STATUS message with TI value "111". For a session management message received with TI different from "111", the following procedures shall apply:

a) Whenever any session management message except ACTIVATE PDP CONTEXT REQUEST, ACTIVATE AA PDP CONTEXT REQUEST or SM-STATUS is received by the network 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 or has been [recently] deactivated, the network should send a SM-STATUS message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and remain in the PDP‑INACTIVE state.

b) Whenever any session management message except REQUEST PDP 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 or has been [recently] deactivated, the MS shall send a SM-STATUS message with cause #81 "invalid transaction identifier value" using the received transaction identifier value and remain in the PDP-INACTIVE state.

c) When an ACTIVATE AA PDP CONTEXT REQUEST or REQUEST PDP CONTEXT ACTIVATION message is received with a transaction identifier flag set to "1", this message shall be ignored.

d) When an ACTIVATE PDP CONTEXT REQUEST message is received specifying a transaction identifier which is not recognized as relating to a 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 AA PDP CONTEXT REQUEST message is received by the network specifying a transaction identifier relating to a PDP context not in state PDP-INACTIVE, the network shall deactivate the old PDP 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.

f) Whenever a REQUEST PDP CONTEXT ACTIVATION message is received by the MS specifying a transaction identifier relating to a PDP context not in state PDP-INACTIVE, the MS shall locally deactivate the old PDP 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.

## 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, RR STATUS or 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 RR message or 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, RR STATUS, MM STATUS, GMM STATUS or SM STATUS depending on the protocol discriminator) with cause #97 "message type non-existent or not implemented".

NOTE 1: 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 04.07 [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, RR STATUS or 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 2: 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 sub-clause 3GPP TS 04.07); or

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

– 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, 8.5.3, 8.5.4 and 8.5.5 a), b) or c), the mobile station shall ignore the message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, RR STATUS or 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 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 (STATUS, RR STATUS, MM STATUS (depending on the protocol discriminator), GMM STATUS, or SM STATUS) with cause # 96 "Invalid mandatory information".

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

1. If the message is a DEACTIVATE AA PDP CONTEXT REQUEST, a DEACTIVATE AA PDP CONTEXT ACCEPT message shall be returned. All resources allocated for that context shall be released.
2. If the message is a REQUEST PDP CONTEXT ACTIVATION, a REQUEST PDP CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.
3. If the message is an ACTIVATE PDP CONTEXT REQUEST, an ACTIVATE PDP CONTEXT REJECT message with cause # 96 "Invalid mandatory information" shall be returned.

If the message is an ACTIVATE AA PDP CONTEXT REQUEST, an ACTIVATE AA PDP CONTEXT 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 04.07).

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

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, RR 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, RR 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 04.08 (i.e. of sub-clauses 3, 4, 5) 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, RR STATUS, or MM STATUS depending on the PD) 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 04.80) is the subject of the technical specifications 3GPP TS 04.10 and the 3GPP TS 04.8x series.