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 38.413  Word version:  18.0.0

Top   Top   Up   Prev   None
1…   4…   8…   8.2…   8.2.3…   8.3…   8.3.4…   8.4…   8.4.3…   8.5…   8.7…   8.8…   8.10…   8.12…   8.17…   9…   9.2…   9.2.2…   9.2.3…   9.2.4…   9.2.6…   9.2.7…   9.2.9…   9.2.11…   9.2.16…   9.2.17…   9.3…   9.3.1.21…   9.3.1.41…   9.3.1.61…   9.3.1.81…   9.3.1.101…   9.3.1.121…   9.3.1.141…   9.3.1.161…   9.3.1.181…   9.3.1.205…   9.3.1.222…   9.3.1.245…   9.3.2…   9.3.3…   9.3.3.21…   9.3.3.42…   9.3.4…   9.3.4.10…   9.3.5…   9.4…   9.4.4   9.4.5   9.4.6…   9.5…   10… 
10 Handling of Unknown, Unforeseen and Erroneous Protocol Data  10.1 General  10.2 Transfer Syntax Error  10.3 Abstract Syntax Error  10.3.1 General  10.3.2 Criticality Information  10.3.3 Presence Information  10.3.4 Not comprehended IE/IE group  10.3.5 Missing IE or IE group  10.3.6 IEs or IE groups received in wrong order or with too many occurrences or erroneously present  10.4 Logical Error  10.5 Exceptions  10.6 Handling of AP ID  $ Change history 

 

10  Handling of Unknown, Unforeseen and Erroneous Protocol Data  p. 631

10.1  General  p. 631

Protocol Error cases can be divided into three classes:
  • Transfer Syntax Error.
  • Abstract Syntax Error.
  • Logical Error.
Protocol errors can occur in the following functions within a receiving node:
Reproduction of 3GPP TS 38.413, Fig. 10.1-1: Protocol Errors in NGAP.
Figure 10.1-1: Protocol Errors in NGAP.
Up
The information stated in subclauses 10.2, 10.3 and 10.4, to be included in the message used when reporting an error, is what at minimum shall be included. Other optional information elements within the message may also be included, if available. This is also valid for the case when the reporting is done with a response message. The latter is an exception to what is stated in subclause 4.1.
Up

10.2  Transfer Syntax Error  p. 631

A Transfer Syntax Error occurs when the receiver is not able to decode the received physical message. Transfer syntax errors are always detected in the process of ASN.1 decoding. If a Transfer Syntax Error occurs, the receiver should initiate Error Indication procedure with appropriate cause value for the Transfer Syntax protocol error.
Examples for Transfer Syntax Errors are:
  • Violation of value ranges in ASN.1 definition of messages. E.g., if an IE has a defined value range of 0 to 10 (ASN.1: INTEGER (0..10)), and 12 will be received, then this will be treated as a transfer syntax error.
  • Violation in list element constraints. E.g., if a list is defined as containing 1 to 10 elements, and 12 elements will be received, then this case will be handled as a transfer syntax error.
  • Missing mandatory elements in ASN.1 SEQUENCE definitions (as sent by the originator of the message).
  • Wrong order of elements in ASN.1 SEQUENCE definitions (as sent by the originator of the message).
Up

10.3  Abstract Syntax Error  p. 631

10.3.1  General  p. 631

An Abstract Syntax Error occurs when the receiving functional NGAP entity:
  1. receives IEs or IE groups that cannot be understood (unknown IE ID);
  2. receives IEs for which the logical range is violated (e.g., ASN.1 definition: 0 to 15, the logical range is 0 to 10, while values 11 to 15 are undefined), and 12 will be received; this case will be handled as an abstract syntax error using criticality information sent by the originator of the message);
  3. does not receive IEs or IE groups but according to the specified presence of the concerning object, the IEs or IE groups should have been present in the received message.
  4. receives IEs or IE groups that are defined to be part of that message in wrong order or with too many occurrences of the same IE or IE group;
  5. receives IEs or IE groups but according to the conditional presence of the concerning object and the specified condition, the IEs or IE groups should not have been present in the received message.
  6. receives IEs or IE groups for a functionality that is not supported.
Cases 1, 2 and 6 (not comprehended IE/IE group) are handled based on received Criticality information. Case 3 (missing IE/IE group) is handled based on Criticality information and Presence information for the missing IE/IE group specified in the version of the specification used by the receiver. Case 4 (IEs or IE groups in wrong order or with too many occurrences) and Case 5 (erroneously present conditional IEs or IE groups) result in rejecting the procedure.
If an Abstract Syntax Error occurs, the receiver shall read the remaining message and shall then for each detected Abstract Syntax Error that belong to cases 1-3 and 6 act according to the Criticality Information and Presence Information for the IE/IE group due to which Abstract Syntax Error occurred in accordance with subclauses 10.3.4 and 10.3.5. The handling of cases 4 and 5 is specified in subclause 10.3.6.
Up

10.3.2  Criticality Information  p. 632

In the NGAP messages there is criticality information set for individual IEs and/or IE groups. This criticality information instructs the receiver how to act when receiving an IE or an IE group that is not comprehended, i.e., the entire item (IE or IE group) which is not (fully or partially) comprehended shall be treated in accordance with its own criticality information as specified in subclause 10.3.4.
In addition, the criticality information is used in case of the missing IE/IE group abstract syntax error (see subclause 10.3.5).
The receiving node shall take different actions depending on the value of the Criticality Information. The three possible values of the Criticality Information for an IE/IE group are:
  • Reject IE.
  • Ignore IE and Notify Sender.
  • Ignore IE.
The comprehension of different IEs or IE groups within a standard version or between standard versions is not mandated. Any IE or IE group that is not supported shall be considered not comprehended, even if another IE or IE group for that EP from that standard version is comprehended, and action based on criticality shall be applied.
The comprehension of different EPs within a standard version or between different standard versions is not mandated. Any EP that is not supported shall be considered not comprehended, even if another EP from that standard version is comprehended, and action based on criticality shall be applied.
Up

10.3.3  Presence Information  p. 632

For many IEs/IE groups which are optional according to the ASN.1 transfer syntax, NGAP specifies separately if the presence of these IEs/IE groups is optional or mandatory with respect to RNS application by means of the presence field of the concerning object of class NGAP-PROTOCOL-IES, NGAP-PROTOCOL-IES-PAIR, NGAP-PROTOCOL-EXTENSION or NGAP-PRIVATE-IES.
The presence field of the indicated classes supports three values:
  1. Optional;
  2. Conditional;
  3. Mandatory.
If an IE/IE group is not included in a received message and the presence of the IE/IE group is mandatory or the presence is conditional and the condition is true according to the version of the specification used by the receiver, an abstract syntax error occurs due to a missing IE/IE group.
If an IE/IE group is included in a received message and the presence of the IE/IE group is conditional and the condition is false according to the version of the specification used by the receiver, an abstract syntax error occurs due to this erroneously present conditional IE/IE group.
Up

10.3.4  Not comprehended IE/IE group  p. 633

10.3.4.1  Procedure Code  p. 633

The receiving node shall treat the different types of received criticality information of the Procedure Code IE according to the following:
Reject IE:
  • If a message is received with a Procedure Code IE marked with "Reject IE" which the receiving node does not comprehend, the receiving node shall reject the procedure using the Error Indication procedure.
Ignore IE and Notify Sender:
  • If a message is received with a Procedure Code IE marked with "Ignore IE and Notify Sender" which the receiving node does not comprehend, the receiving node shall ignore the procedure and initiate the Error Indication procedure.
Ignore IE:
  • If a message is received with a Procedure Code IE marked with "Ignore IE" which the receiving node does not comprehend, the receiving node shall ignore the procedure.
When using the Error Indication procedure to reject a procedure or to report an ignored procedure it shall include the Procedure Code IE, the Triggering Message IE, and the Procedure Criticality IE in the Criticality Diagnostics IE.
Up

10.3.4.1A  Type of Message  p. 633

When the receiving node cannot decode the Type of Message IE, the Error Indication procedure shall be initiated with an appropriate cause value.

10.3.4.2  IEs other than the Procedure Code and Type of Message  p. 633

The receiving node shall treat the different types of received criticality information of an IE/IE group other than the Procedure Code IE and Type of Message IE according to the following:
Reject IE:
  • If a message initiating a procedure is received containing one or more IEs/IE group marked with "Reject IE" which the receiving node does not comprehend; none of the functional requests of the message shall be executed. The receiving node shall reject the procedure and report the rejection of one or more IEs/IE group using the message normally used to report unsuccessful outcome of the procedure. In case the information received in the initiating message was insufficient to determine a value for all IEs that are required to be present in the message used to report the unsuccessful outcome of the procedure, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure.
  • If a message initiating a procedure that does not have a message to report unsuccessful outcome is received containing one or more IEs/IE groups marked with "Reject IE" which the receiving node does not comprehend, the receiving node shall terminate the procedure and initiate the Error Indication procedure.
  • If a response message is received containing one or more IEs marked with "Reject IE", that the receiving node does not comprehend, the receiving node shall consider the procedure as unsuccessfully terminated and initiate local error handling.
Ignore IE and Notify Sender:
  • If a message initiating a procedure is received containing one or more IEs/IE groups marked with "Ignore IE and Notify Sender" which the receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended IEs/IE groups, continue with the procedure as if the not comprehended IEs/IE groups were not received (except for the reporting) using the understood IEs/IE groups, and report in the response message of the procedure that one or more IEs/IE groups have been ignored. In case the information received in the initiating message was insufficient to determine a value for all IEs that are required to be present in the response message, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure.
  • if a message initiating a procedure that does not have a message to report the outcome of the procedure is received containing one or more IEs/IE groups marked with "Ignore IE and Notify Sender" which the receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended IEs/IE groups, continue with the procedure as if the not comprehended IEs/IE groups were not received (except for the reporting) using the understood IEs/IE groups, and initiate the Error Indication procedure to report that one or more IEs/IE groups have been ignored.
  • If a response message is received containing one or more IEs/IE groups marked with "Ignore IE and Notify Sender" which the receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended IEs/IE groups, continue with the procedure as if the not comprehended IEs/IE groups were not received (except for the reporting) using the understood IEs/IE groups and initiate the Error Indication procedure.
Ignore IE:
  • If a message initiating a procedure is received containing one or more IEs/IE groups marked with "Ignore IE" which the receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended IEs/IE groups and continue with the procedure as if the not comprehended IEs/IE groups were not received using the understood IEs/IE groups.
  • If a response message is received containing one or more IEs/IE groups marked with "Ignore IE" which the receiving node does not comprehend, the receiving node shall ignore the content of the not comprehended IEs/IE groups and continue with the procedure as if the not comprehended IEs/IE groups were not received using the understood IEs/IE groups.
When reporting not comprehended IEs/IE groups marked with "Reject IE" or "Ignore IE and Notify Sender" using a response message defined for the procedure, the Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported IE/IE group.
When reporting not comprehended IEs/IE groups marked with "Reject IE" or "Ignore IE and Notify Sender" using the Error Indication procedure, the Procedure Code IE, the Triggering Message IE, Procedure Criticality IE, and the Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported IE/IE group.
Up

10.3.5  Missing IE or IE group  p. 634

The receiving node shall treat the missing IE/IE group according to the criticality information for the missing IE/IE group in the received message specified in the version of this specification used by the receiver:
Reject IE:
  • if a received message initiating a procedure is missing one or more IEs/IE groups with specified criticality "Reject IE"; none of the functional requests of the message shall be executed. The receiving node shall reject the procedure and report the missing IEs/IE groups using the message normally used to report unsuccessful outcome of the procedure. In case the information received in the initiating message was insufficient to determine a value for all IEs that are required to be present in the message used to report the unsuccessful outcome of the procedure, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure.
  • if a received message initiating a procedure that does not have a message to report unsuccessful outcome is missing one or more IEs/IE groups with specified criticality "Reject IE", the receiving node shall terminate the procedure and initiate the Error Indication procedure.
  • if a received response message is missing one or more IEs/IE groups with specified criticality "Reject IE", the receiving node shall consider the procedure as unsuccessfully terminated and initiate local error handling.
Ignore IE and Notify Sender:
  • if a received message initiating a procedure is missing one or more IEs/IE groups with specified criticality "Ignore IE and Notify Sender", the receiving node shall ignore that those IEs are missing and continue with the procedure based on the other IEs/IE groups present in the message and report in the response message of the procedure that one or more IEs/IE groups were missing. In case the information received in the initiating message was insufficient to determine a value for all IEs that are required to be present in the response message, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure.
  • if a received message initiating a procedure that does not have a message to report the outcome of the procedure is missing one or more IEs/IE groups with specified criticality "Ignore IE and Notify Sender", the receiving node shall ignore that those IEs are missing and continue with the procedure based on the other IEs/IE groups present in the message and initiate the Error Indication procedure to report that one or more IEs/IE groups were missing.
  • if a received response message is missing one or more IEs/IE groups with specified criticality "Ignore IE and Notify Sender", the receiving node shall ignore that those IEs are missing and continue with the procedure based on the other IEs/IE groups present in the message and initiate the Error Indication procedure to report that one or more IEs/IE groups were missing.
Ignore IE:
  • if a received message initiating a procedure is missing one or more IEs/IE groups with specified criticality "Ignore IE", the receiving node shall ignore that those IEs are missing and continue with the procedure based on the other IEs/IE groups present in the message.
  • if a received response message is missing one or more IEs/IE groups with specified criticality "Ignore IE", the receiving node shall ignore that those IEs/IE groups are missing and continue with the procedure based on the other IEs/IE groups present in the message.
When reporting missing IEs/IE groups with specified criticality "Reject IE" or "Ignore IE and Notify Sender" using a response message defined for the procedure, the Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported IE/IE group.
When reporting missing IEs/IE groups with specified criticality "Reject IE" or "Ignore IE and Notify Sender" using the Error Indication procedure, the Procedure Code IE, the Triggering Message IE, Procedure Criticality IE, and the Information Element Criticality Diagnostics IE shall be included in the Criticality Diagnostics IE for each reported IE/IE group.
Up

10.3.6  IEs or IE groups received in wrong order or with too many occurrences or erroneously present  p. 635

If a message with IEs or IE groups in wrong order or with too many occurrences is received or if IEs or IE groups with a conditional presence are present when the condition is not met (i.e., erroneously present), the receiving node shall behave according to the following:
  • If a message initiating a procedure is received containing IEs or IE groups in wrong order or with too many occurrences or erroneously present, none of the functional requests of the message shall be executed. The receiving node shall reject the procedure and report the cause value "Abstract Syntax Error (Falsely Constructed Message)" using the message normally used to report unsuccessful outcome of the procedure. In case the information received in the initiating message was insufficient to determine a value for all IEs that are required to be present in the message used to report the unsuccessful outcome of the procedure, the receiving node shall instead terminate the procedure and initiate the Error Indication procedure.
  • If a message initiating a procedure that does not have a message to report unsuccessful outcome is received containing IEs or IE groups in wrong order or with too many occurrences or erroneously present, the receiving node shall terminate the procedure and initiate the Error Indication procedure, and use cause value "Abstract Syntax Error (Falsely Constructed Message)".
  • If a response message is received containing IEs or IE groups in wrong order or with too many occurrences or erroneously present, the receiving node shall consider the procedure as unsuccessfully terminated and initiate local error handling.
When determining the correct order only the IEs specified in the specification version used by the receiver shall be considered.
Up

10.4  Logical Error  p. 636

Logical error situations occur when a message is comprehended correctly, but the information contained within the message is not valid (i.e., semantic error), or describes a procedure which is not compatible with the state of the receiver. In these conditions, the following behaviour shall be performed (unless otherwise specified) as defined by the class of the elementary procedure, irrespective of the criticality information of the IEs/IE groups containing the erroneous values.
Class 1:
Where the logical error occurs in a request message of a class 1 procedure, and the procedure has a message to report this unsuccessful outcome, this message shall be sent with an appropriate cause value. Typical cause values are:
  • Semantic Error.
  • Message not compatible with receiver state.
Where the logical error is contained in a request message of a class 1 procedure, and the procedure does not have a message to report this unsuccessful outcome, the procedure shall be terminated and the Error Indication procedure shall be initiated with an appropriate cause value. The Procedure Code IE and the Triggering Message IE within the Criticality Diagnostics IE shall then be included in order to identify the message containing the logical error.
Where the logical error exists in a response message of a class 1 procedure, the procedure shall be considered as unsuccessfully terminated and local error handling shall be initiated.
Class 2:
Where the logical error occurs in a message of a class 2 procedure, the procedure shall be terminated and the Error Indication procedure shall be initiated with an appropriate cause value. The Procedure Code IE and the Triggering Message IE within the Criticality Diagnostics IE shall then be included in order to identify the message containing the logical error.
Up

10.5  Exceptions  p. 636

The error handling for all the cases described hereafter shall take precedence over any other error handling described in the other subclauses of clause 10.
  • If any type of error (Transfer Syntax Error, Abstract Syntax Error or Logical Error) is detected in the ERROR INDICATION message, it shall not trigger the Error Indication procedure in the receiving Node but local error handling.
  • In case a response message or Error Indication message needs to be returned, but the information necessary to determine the receiver of that message is missing, the procedure shall be considered as unsuccessfully terminated and local error handling shall be initiated.
  • If an error that terminates a procedure occurs, the returned cause value shall reflect the error that caused the termination of the procedure even if one or more abstract syntax errors with criticality "ignore and notify" have earlier occurred within the same procedure.
  • If an AP ID error is detected, the error handling as described in subclause 10.6 shall be applied.
Up

10.6  Handling of AP ID  p. 637

If a node receives a first returned message that includes an unknown local AP ID, the receiving node shall initiate an Error Indication procedure with inclusion of the received AP IDs from the peer node and an appropriate cause value. Both nodes shall initiate a local release of any established UE-associated logical connection (for the same NG interface) having these AP IDs as local or remote identifier.
If a node receives a message (other than the first or first returned messages) including an erroneous AP ID that is either an unknown local AP ID, or an inconsistent remote AP ID (i.e. it is different to the remote AP ID stored previously for this UE-associated logical connection) for the same NG interface:
  • if this message is not the last message for this UE-associated logical connection, the node shall initiate an Error Indication procedure with inclusion of the received AP ID(s) from the peer node and an appropriate cause value. Both nodes shall initiate a local release of any established UE-associated logical connection (for the same NG interface) having the erroneous AP ID as either the local or remote identifier.
  • if this message is the last message for this UE-associated logical connection, the receiving node shall initiate a local release of any established UE-associated logical connection (for the same NG interface) having the erroneous AP ID as either the local or remote identifier.
Up

$  Change history  p. 638

Up   Top