Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…   D.6.8   D.7… 
7 Handling of unknown, unforeseen, and erroneous protocol data  7.1 General  7.2 Message too short or too long  7.3 Unknown or unforeseen procedure transaction identity or PDU Session identity  7.4 Unknown or unforeseen message type  7.5 Non-semantical mandatory information element errors  7.6 Unknown and unforeseen IEs in the non-imperative message part  7.7 Non-imperative message part errors  7.8 Messages with semantically incorrect contents 
...

 

7  Handling of unknown, unforeseen, and erroneous protocol data  p. 729

7.1  General  p. 729

The procedures specified in the present document 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.
Subclauses 7.1 to 7.8 shall be applied in order of precedence.
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 are assumed to have the error handling which is indicated in this subclause as mandatory ("shall") and that is indicated as strongly recommended ("should").
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 subclause 11.4.2 of TS 24.007.
Up

7.2  Message too short or too long  p. 729

7.2.1  Message too short  p. 729

When a message is received that is too short to contain a complete message type information element, that message shall be ignored, cf. TS 24.007.

7.2.2  Message too long  p. 729

The maximum size of a NAS message for NR connected to 5GCN is specified in TS 38.323.
The maximum size of a NAS message for E-UTRA connected to 5GCN is specified TS 36.323.
The maximum size of a NAS message for non-3GPP access connected to 5GCN is specified in TS 24.502

7.3  Unknown or unforeseen procedure transaction identity or PDU Session identity  p. 730

7.3.1  Procedure transaction identity  p. 730

The following network procedures shall apply for handling an unknown, erroneous, or unforeseen PTI received in a 5GSM message:
  1. In case the network receives a PDU SESSION MODIFICATION COMPLETE, a PDU SESSION RELEASE COMPLETE message or a PDU SESSION MODIFICATION COMMAND REJECT message in which the PTI value is an assigned or unassigned value that does not match any PTI in use, the network shall respond with a 5GSM STATUS message including 5GSM cause #47 "PTI mismatch".
  2. In case the network receives a PDU SESSION AUTHENTICATION COMPLETE message or a SERVICE-LEVEL AUTHENTICATION COMPLETE message in which the PTI value is an assigned value, the network shall respond with a 5GSM STATUS message including 5GSM cause #81 "invalid PTI value".
  3. In case the network receives a PDU SESSION ESTABLISHMENT REQUEST message, a PDU SESSION MODIFICATION REQUEST message or a PDU SESSION RELEASE REQUEST message in which the PTI value is an unassigned value, the network shall respond with a 5GSM STATUS message including 5GSM cause #81 "invalid PTI value".
  4. In case the network receives a 5GSM message in which the PTI value is a reserved value, the network shall ignore the message.
The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen PTI received in a 5GSM message:
  1. In case the UE receives a PDU SESSION MODIFICATION COMMAND message or a PDU SESSION MODIFICATION REJECT message in which the PTI value is an assigned value that does not match any PTI in use:
    1. if the UE detects that this PDU SESSION MODIFICATION COMMAND message is a network retransmission of an already accepted request (see subclause 6.3.2.3), the UE shall respond with a PDU SESSION MODIFICATION COMPLETE message;
    2. if the UE detects that this PDU SESSION MODIFICATION COMMAND message is a network retransmission of an already rejected request (see subclause 6.3.2.4), the UE shall respond with a PDU SESSION MODIFICATION COMAND REJECT message; or
    3. otherwise, the UE shall respond with a 5GSM STATUS message including 5GSM cause #47 "PTI mismatch".
  2. In case the UE receives a PDU SESSION RELEASE COMMAND message or a PDU SESSION RELEASE REJECT message in which the PTI value is an assigned value that does not match any PTI in use:
    1. if the UE detects that this PDU SESSION RELEASE COMMAND message is a network retransmission of an already accepted request (see subclause 6.3.3.3), the UE shall respond with a PDU SESSION RELEASE COMPLETE message; or
    2. otherwise, the UE shall respond with a 5GSM STATUS message including 5GSM cause #47 "PTI mismatch".
  3. In case the UE receives a PDU SESSION ESTABLISHMENT ACCEPT message or a PDU SESSION ESTABLISHMENT REJECT message in which the PTI value is an assigned value that does not match any PTI in use:
    1. the UE shall respond with a 5GSM STATUS message including 5GSM cause #47 "PTI mismatch".
  4. In case the UE receives a PDU SESSION AUTHENTICATION COMMAND message, a PDU SESSION AUTHENTICATION RESULT message or a SERVICE-LEVEL AUTHENTICATION COMMAND message in which the PTI value is an assigned value, the UE shall respond with a 5GSM STATUS message including 5GSM cause #81 "invalid PTI value".
  5. In case the UE receives a PDU SESSION ESTABLISHMENT ACCEPT message, a PDU SESSION ESTABLISHMENT REJECT message, a PDU SESSION MODIFICATION REJECT message or a PDU SESSION RELEASE REJECT message in which the PTI value is an unassigned value, the UE shall ignore the message.
  6. In case the UE receives a 5GSM message in which the PTI value is a reserved value, the UE shall ignore the message.
Up

7.3.2  PDU Session identity  p. 731

The following network procedures shall apply for handling an unknown, erroneous, or unforeseen PDU session identity received in the header of a 5GSM message (specified as the header of a standard L3 message, see TS 24.007):
  1. If the network receives a PDU SESSION MODIFICATION REQUEST message which includes an unassigned or reserved PDU session identity value, the network shall respond with a PDU SESSION MODIFICATION REJECT message including 5GSM cause #43 "invalid PDU session identity".
  2. If the network receives PDU SESSION RELEASE REQUEST message which includes an unassigned or reserved PDU session identity value, the network shall respond with a PDU SESSION RELEASE REJECT message including 5GSM cause #43 "invalid PDU session identity".
  3. Upon receipt of an UL NAS TRANSPORT message, the network takes the following actions:
    1. If the Request type IE is set to "initial request" or "initial emergency request" and the message includes a reserved PDU session identity value, the network shall respond with a DL NAS TRANSPORT message with 5GMM cause #90 "payload was not forwarded";
    2. otherwise, if the message includes an unassigned or reserved PDU session identity value, the network shall respond with a DL NAS TRANSPORT message with 5GMM cause #90 "payload was not forwarded".
  4. If the network receives a 5GSM message other than those listed in items a) through c) above in which the message includes a reserved PDU session identity value or an assigned value that does not match an existing PDU session, the network shall ignore the message.
The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen PDU session identity received in the header of a 5GSM message:
  1. If the UE receives a 5GSM message which includes an unassigned or reserved PDU session identity value, the UE shall ignore the message.
  2. If the UE receives a 5GSM message which includes a PDU session identity belonging to any PDU session in state PDU SESSION INACTIVE in the UE, the UE shall respond with a 5GSM STATUS message including 5GSM cause #43 "invalid PDU session identity".
Up

7.4  Unknown or unforeseen message type  p. 731

If UE receives a 5GMM message or 5GSM message with message type not defined for the extended protocol discriminator (EPD) or not implemented by the receiver, it shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #97 "message type non-existent or not implemented".
If the network receives a 5GMM or 5GSM message with message type not defined for the EPD or not implemented by the receiver in a protocol state where reception of an unsolicited message with the given EPD from the UE 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 EPD or not implemented by the receiver, it shall ignore the message except that it should return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #97 "message type non-existent or not implemented".
If the UE receives a message not compatible with the protocol state, the UE shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) 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.
Up

7.5  Non-semantical mandatory information element errors  p. 732

7.5.1  Common procedures  p. 732

When on receipt of a message,
  1. an "imperative message part" error; or
  2. a "missing mandatory IE" error
is diagnosed or when a message containing:
  1. a syntactically incorrect mandatory IE;
  2. an IE with an IEI unknown in the message, but encoded as "comprehension required" (see TS 24.007); or
  3. an out of sequence IE encoded as "comprehension required" (see TS 24.007) is received,
the UE shall proceed as follows:
If the message is not one of the messages listed in the UE procedures in subclause 7.5.3, item a), b) or c), the UE shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #96 "invalid mandatory information";
the network shall proceed as follows:
If the message is not one of the messages listed in the network procedures in subclause 7.5.3, item a), b) or c), the network shall either:
  1. try to treat the message (the exact further actions are implementation dependent); or
  2. ignore the message except that it should return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #96 "invalid mandatory information".
Up

7.5.2  5GS mobility management  p. 732

No exceptional cases are described for 5GS mobility management messages.
No semantical or syntactical diagnosis other than presence and length shall be performed on the EPS NAS message container information element in the REGISTRATION REQUEST message.

7.5.3  5GS session management  p. 732

The following UE procedures shall apply for handling an error encountered with a mandatory information element in a 5GSM message:
a) If the message is a PDU SESSION ESTABLISHMENT ACCEPT, the UE shall initiate PDU session release procedure by sending a PDU SESSION RELEASE REQUEST message with 5GSM cause #96 "invalid mandatory information".
b) Void.
c) If the message is a PDU SESSION RELEASE COMMAND, a PDU SESSION RELEASE COMPLETE message with 5GSM cause #96 "invalid mandatory information" shall be returned.
The following network procedures shall apply for handling an error encountered with a mandatory information element in a 5GSM message:
a) If the message is a PDU SESSION ESTABLISHMENT REQUEST, a PDU SESSION ESTABLISHMENT REJECT message with 5GSM cause #96 "invalid mandatory information" shall be returned.
b) If the message is a PDU SESSION MODIFICATION REQUEST, a PDU SESSION MODIFICATION REJECT message with 5GSM cause #96 "invalid mandatory information" shall be returned.
c) If the message is a PDU SESSION RELEASE REQUEST, a PDU SESSION RELEASE REJECT message with 5GSM cause #96 "invalid mandatory information" shall be returned.
Up

7.6  Unknown and unforeseen IEs in the non-imperative message part  p. 733

7.6.1  IEIs unknown in the message  p. 733

The UE shall ignore all IEs with an IEI unknown in a message which are not encoded as "comprehension required" (see TS 24.007).
The network shall take the same approach.

7.6.2  Out of sequence IEs  p. 733

The UE shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required" (see TS 24.007).
The network should take the same approach.

7.6.3  Repeated IEs  p. 733

If an information element with format T, TV, TLV, or TLV-E is repeated in a message in which repetition of the information element is not specified in clause 8 and clause 9 of the present document, the UE shall handle only the contents of the information element appearing first and shall ignore all subsequent repetitions of the information element. When repetition of information elements is specified, the UE shall handle only the contents of specified repeated information elements. If the limit on repetition of information elements is exceeded, the UE shall handle the contents of information elements appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information element.
The network should follow the same procedures.
Up

7.6.4  Unknown and unforeseen IEs in a Type 6 IE container information element |R18|  p. 733

7.6.4.1  IEIs unknown in the Type 6 IE container information element  p. 733

The UE shall ignore all IEs with an IEI unknown in a Type 6 IE container information element which are not encoded as "comprehension required" (see TS 24.007).
The network shall take the same approach.
Up

7.6.4.2  Out of sequence IEs  p. 734

The UE shall ignore all out of sequence IEs in a Type 6 IE container information element which are not encoded as "comprehension required" (see TS 24.007).
The network should take the same approach.

7.6.4.3  Repeated IEs  p. 734

If an information element with format TLV-E is repeated in a Type 6 IE container information element in which repetition of the information element is not specified in clause 8 and clause 9 of the present document, the UE shall handle only the contents of the information element appearing first and shall ignore all subsequent repetitions of the information element. When repetition of information elements in the Type 6 IE container information element is specified, the UE shall handle only the contents of specified repeated information elements. If the limit on repetition of information elements is exceeded, the UE shall handle the contents of information elements appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information element.
The network should follow the same procedures.
Up

7.7  Non-imperative message part errors  p. 734

This category includes:
  1. syntactically incorrect optional IEs; and
  2. conditional IE errors.

7.7.1  Syntactically incorrect optional IEs  p. 734

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

7.7.2  Conditional IE errors  p. 734

When upon receipt of a 5GMM or 5GSM message the UE diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error, or when it receives a 5GMM or 5GSM message containing at least one syntactically incorrect conditional IE, the UE shall ignore the message and shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #100 "conditional IE error".
When the network receives a message and diagnoses 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:
  1. try to treat the message (the exact further actions are implementation dependent); or
  2. ignore the message except that it should return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #100 "conditional IE error".
Up

7.7.3  Errors in a Type 6 IE container information element |R18|  p. 734

7.7.3.1  Syntactically incorrect optional IEs  p. 734

The UE shall treat all optional IEs that are syntactically incorrect in a Type 6 IE container information element as not present in the Type 6 IE container information element.
The network shall take the same approach.
EXAMPLE 1:
If the Type 6 IE container information element includes 2 type 6 information elements, and the first one is syntactically incorrect, the receiver ignores the first information element and continues with the processing of the second one.
EXAMPLE 2:
If the remaining value part of a Type 6 IE container information element is too short to contain a complete type 6 information element, the receiver ignores these octets and continues with the processing of the octets following the Type 6 IE container information element, if there are any.
Up

7.7.3.2  Conditional IE errors  p. 735

When upon receipt of a 5GMM or 5GSM message the UE diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error for the contents of a Type 6 IE container information element, or when it receives a 5GMM or 5GSM message with a Type 6 IE container information element containing at least one syntactically incorrect conditional IE, the UE shall ignore the message and shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #100 "conditional IE error".
When the network receives a message and diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error for the contents of a Type 6 IE container information element or when it receives a message with a Type 6 IE container information element containing at least one syntactically incorrect conditional IE, the network shall either:
  1. try to treat the message (the exact further actions are implementation dependent); or
  2. ignore the message except that it should return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #100 "conditional IE error".
Up

7.8  Messages with semantically incorrect contents  p. 735

When a message with semantically incorrect contents is received, the UE shall perform the foreseen reactions of the procedural part of the present document (i.e. of clauses 5, 6). If, however no such reactions are specified, the UE shall ignore the message except that it shall return a status message (5GMM STATUS or 5GSM STATUS depending on the EPD) with cause #95 "semantically incorrect message".
The network should follow the same procedure except that a status message is not normally transmitted.
Up

Up   Top   ToC