8 General protocol error handling

3GPP48.016Base Station System (BSS) - Serving GPRS Support Node (SGSN) interfaceGeneral Packet Radio Service (GPRS)Network serviceRelease 17TS

This sub-clause is not applicable to the Sub-Network Service protocol.

The following "General case" sub-clause applies unless otherwise stated in the "Special cases" sub-clause.

8.1 General case

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

Most error handling procedures are mandatory for a BSS and SGSN.

Detailed error handling procedures are implementation dependent and may vary from PLMN to PLMN. However, when extensions of this protocol are developed, networks shall 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").

In this sub-clause the following terminology is used:

– Syntactical error: an IE is defined to be syntactically incorrect in a PDU if it contains at least one value defined as "reserved" or "reserved for future use", or if its value part violates coding rules specified in the relevant protocol specification, e.g. a too short IE (the length indicator shall be used to determine the boundary of the IE). However, it is not a syntactical error that an IE specifies in its length indicator a greater length than defined in the relevant protocol specification; and

– Semantic error: a PDU 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 of the relevant protocol specification.

To allow for the introduction of new functions the following rules shall be used to determine the actions of a receiving entity when it receives a PDU, part or all of which it is unable to understand. As the recipient is unable to tell the difference between a new, previously unspecified coding and an erroneous coding, the recipient also uses the same rules for error handling.

The robustness of a recipient in handling erroneous PDUs does not relax the requirement that the transmitter shall obey the present document. However, it is intended that functionality can be gradually added to an entity, and no obstacle to intermediate phase equipment is intended.

8.1.1 Presence requirements of Information Elements

There are three different presence requirements (M, C, or O) for an IE within a given PDU:

– M ("Mandatory") means that the IE shall be included by the sending side, and that the receiver diagnoses a "missing essential IE" error when detecting that the IE is not present.

– C ("Conditional") means:

– that inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification;

– that there are conditions for the receiver to expect that the IE is present and/or conditions for the receiver to expect that the IE is not present; these conditions depend only on the PDU itself, and not on the state in which the PDU was received; they are known as static conditions;

– that the receiver detecting that the IE is not present when sufficient static conditions are fulfilled for its presence, shall diagnose a "missing essential IE" error;

– that the receiver detecting that the IE is present when sufficient static conditions are fulfilled for its non‑presence, shall treat the IE as an optional one, see below.

– O ("Optional") means that the receiver shall never diagnose a "missing essential IE" error or shall never diagnose an error because it detects that the IE is present or that the IE is not present. There may however be conditions depending on the states, resources, etc. of the receiver to diagnose other errors.

In addition, the following definitions apply:

– Essential Elements: These are the conditional (C) elements when the condition for their reception is fulfilled, plus the mandatory (M) elements. Any exception to this rule is explicitly stated in the relevant protocol specification.

– Non-Essential Elements: Non-essential elements are all the information elements that are not defined as essential.

8.1.2 Erroneous events

The following events shall be regarded as errors by the recipient and shall be treated as specified below. Certain types of error shall be reported to the sending side, in that case the erroneous PDU and the error cause shall be returned to the sending side by means of the appropriate error reporting PDU. The following rules shall be applied in order of precedence:

1) a PDU whose type is non-existent or unrecognisable: the error shall not be reported, the PDU shall be ignored;

2) a PDU not consistent with the recipient’s state: the error shall be reported with cause "PDU not compatible with the protocol state", the PDU shall be ignored;

3) a PDU sent in the wrong direction: the error shall be reported with cause "Protocol error – unspecified", the PDU shall be ignored;

4) a missing essential information element: the error shall be reported with cause "Missing essential IE", the PDU shall be ignored;

5) syntactical error in an essential IE: the error shall be reported with cause "Invalid essential IE", the PDU shall be ignored.

8.1.3 Non-erroneous events

The following events shall not be regarded as errors by the recipient:

1) spare bits with an unexpected value in any information element;

2) the use of additional octets in any information element with a length indicator, that is: when the indicated length is greater than defined in the relevant protocol specification (the length indicatorl shall be used to determine the boundary of the IE);

3) a missing non-essential information element;

4) an unknown information element identifier;

5) any unexpected information element; and

6) a syntactical error in any non-essential information element.

When the recipient detects one or more of these events the receiving entity shall ignore the information that it is unable to understand and treat the PDU on the basis of the information that remains.

Additionally, when more information elements of a particular type are received than are expected, the last one(s) shall be ignored.

If, because information was ignored, the rest of the PDU can no longer be handled then the receiving entity shall report the error to the sending side by means of the appropriate error reporting PDU including the incorrect PDU received and the cause "semantically incorrect PDU".

8.1.4 Other events

The following events should be treated on a case by case basis and the outcome may depend upon the capabilities of the recipient.

1) The recipient may accept PDUs that contain information elements that do not appear to be in the correct sequence. Elements that occur more than once in a PDU shall be assumed to have been transmitted in the correct order. Recipients that do not accept out of sequence information elements shall regard the PDU as containing unexpected and/or missing information elements and follow the procedures defined in the rest of this "General case" sub-clause.

2) When any IE with semantically incorrect contents is received, the receiving entity shall react according to the relevant protocol specification. If however no such reactions are specified, the receiving entity shall ignore that IE and treat the rest of the PDU. If, because this IE was ignored, the rest of the PDU can no longer be handled then the receiving entity shall report the error to the sending side by means of the appropriate error reporting PDU including the incorrect PDU received and the cause "semantically incorrect PDU".

8.2 Special cases

In case of conflict between this sub-clause and the above "General case" sub-clause, this sub-clause takes precedence.

In case of conflict between this sub-clause and the specific "Abnormal conditions" sub-clauses in sub-clause "Network Service Control protocol", the "Abnormal conditions" sub-clauses take precedence over this "Special cases" sub-clause.

8.2.1 Deviations from the "General case" sub-clause

The Cause information element (see sub-clauses "General PDU definitions and contents" and "General information elements coding") shall be considered as a non-essential information element even when mandatory in a PDU.

8.2.2 Error reporting

The NS-STATUS PDU shall be used to report error to the remote NS entity, see sub-clause "Procedure for error reporting". The NS-STATUS PDU shall never be used to report an error detected in a received NS-STATUS PDU.