11 Error Handling

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

11.1 Protocol Errors

A protocol error is defined as a message with unknown, unforeseen or erroneous content. The term silently discarded used in the following clauses means that the implementation shall discard the message without further processing and should log the event including the erroneous message and should include the error in a statistical counter.

An information element with "Mandatory" in the "Presence requirement" column of a message definition shall always be present in that message.

The conditions for a conditional information element define whether the information element is semantically:

– mandatorily present;

– optionally present;

– mandatorily absent.

An information element, which is semantically mandatorily present but is omitted from the message, is treated as missing data.

An information element, which is semantically mandatorily absent but is present in the message, is treated as unexpected data.

The Error Indication, Version Not Supported, RAN Information Relay, Supported Extension Headers Notification and the SGSN Context Acknowledge messages shall be considered as Responses for the purpose of this clause.

The clauses 11.1.1 to 11.1.13 shall be applied in decreasing priorities.

11.1.1 Different GTP Versions

If a receiving node receives a GTP-C message of an unsupported version, that node shall return a GTP Version Not Supported message indicating in the Version field of the GTP header the latest GTP version that that node supports. The received GTP-PDU shall then be discarded.

11.1.2 GTP Message Length Errors

When a GTP message is received, and is too short to contain the GTP header for the GTP version that the sender claims to use, the GTP-PDU message shall be silently discarded.

If a GTP entity receives a Request message within an IP/UDP packet of a length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity should log the error and shall send the Response message with Cause IE value set to "Invalid message format".

If a GTP entity receives a Response message within an IP/UDP packet of a length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity should log the error and shall silently discard the message.

11.1.3 Unknown GTP Signalling Message

When a message using a Message Type value defining an Unknown GTP signalling message is received, it shall be silently discarded.

11.1.4 Unexpected GTP Signalling Message

When an unexpected GTP control plane message is received, e.g. a Response message for which there is no corresponding outstanding Request, or a GTP control plane message a GSN is not expected to handle (such as a PDU Notification Request received by a GGSN),, it shall be silently discarded.

11.1.5 Missing Mandatorily Present Information Element

The receiver of a GTP signalling Request message with a missing mandatorily present information element shall discard the request, should log the error, and shall send a Response with Cause set to "Mandatory IE missing". The receiver of a Response with a missing mandatory information element shall notify the upper layer and should log the error.

11.1.6 Invalid IE Length

The receiver of an invalid length GTP message cannot detect which of the IEs has an incorrect length, unless the message contains only one IE.

In a received GTP signalling message Request, which has a valid length, a mandatory or a conditional extendable length TLV format information element may have a Length field value, which is different from the expected Length . In this case,

– if the Length field value is greater than expected, the extra unknown octets shall be discarded.

– if the Length field value is less than the number of fixed octets defined for that IE, preceding the extended field(s), the receiver shall try to continue the procedure, if possible. Otherwise, this information element shall be discarded, the error should be logged, and a Response shall be sent with Cause set to "Mandatory IE incorrect". Please refer to Table 37 for determining the number of fixed octets of an IE.

In a received GTP signalling message Response, which has a valid length, a mandatory or conditional extendable length TLV format information element may have a Length field value, which is different from the expected Length. In this case,

– if the Length field value is greater than expected, the extra unknown octets shall be discarded.

– if the Length field value is less than the number of fixed octets defined for that IE, preceding the extended field(s), the receiver shall try to continue the GTP signalling procedure, if possible. Otherwise, the GTP signalling procedure shall be treated as having failed.

NOTE: Pre Rel-8 GTP entities don’t support receiving a Request or Response message with a mandatory or a conditional TLV format information element having an unexpected Length.

11.1.7 Invalid Mandatory Information Element

The receiver of a GTP signalling message Request including a mandatory information element with a Value that is not in the range defined for this information element value shall discard the request, should log the error, and shall send a response with Cause set to "Mandatory IE incorrect".

The receiver of a GTP signalling message Response including a mandatory information element with a Value that is not in the range defined for this information element shall notify the upper layer that a message with this sequence number has been received and should log the error.

If a GSN receives an information element with a value which is shown as reserved, it shall treat that information element as not being in the range defined for the information element.

NOTE: The receiver does not check the content of an information element field that is defined as "spare".

11.1.8 Invalid Optional Information Element

The receiver of a GTP signalling message including an optional information element with a Value that is not in the range defined for this information element value shall discard this IE, should log the error, and shall treat the rest of the message as if this IE was absent.

If a GSN receives an information element with a value which is shown as reserved, it shall treat that information element as not being in the range defined for the information element.

NOTE: The receiver does not check the content of an information element field that is defined as "spare".

11.1.9 Unknown Information Element

An information element with an unknown Type value shall be ignored by the receiver of the message. If this is a TLV element, this information element shall be skipped using its Length value. If this is an unknown TV element, the receiver shall discard the rest of the message. However, if the TV element is known but not expected, then the handling defined in clause 11.1.11 shall apply.

If the receiving node cannot interpret the rest of the message because of the ignored information element, the receiving node shall discard the message and should log the error. If the message was a Request, it shall, in addition, return a response with Cause set to "Invalid message format".

11.1.10 Out of Sequence Information Elements

If two or more information elements are out of sequence in a message, the receiving node shall discard the message and should log the error. In addition, if the message was a Request, the receiving node shall return a Response with Cause set to "Invalid message format".

11.1.11 Unexpected Information Element

An information element with a Type value which is defined in clause 7.7 of the present specification but is not expected in the received GTP signalling message shall be ignored (skipped) and the rest of the message processed as if this information element was not present. For all information elements of type TV, a receiving entity shall be able to determine how long each IE is, even if that IE should never be received in any message by that particular network entity.

11.1.12 Repeated Information Elements

If an information element is repeated in a GTP signalling message in which repetition of the information element is not specified, 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.

11.1.13 Incorrect Optional Information Elements

All optional information elements that are incorrect in a GTP signalling message shall be treated as not present in the message. However, if the receiving node may not handle the message correctly because of the incorrect information element, the receiving node should log the error and shall return a response with Cause set to "Optional IE incorrect".

11.2 Path Failure

A path counter shall be reset each time a response is received on the path and incremented when the T3-RESPONSE timer expires for any message sent on the path. The path shall be considered to be down if the counter exceeds N3-REQUESTS. In this case, the GSN or RNC may notify the Operation and Maintenance network element. GTP shall also notify the upper layer of the path failure, so that PDP contexts associated with this path may be deleted

11.3 MS Detach

When an MS detaches, all ongoing GTP control plane procedures related to this MS shall be aborted. The SGSN shall send Delete PDP Context Request messages for all active PDP contexts to the peer GGSNs.

11.4 Restoration and Recovery

All GSNs shall maintain in non-volatile memory a Restart Counter of local significance. A GSN that restarts shall change the Restart Counter value immediately after the restart procedure has been completed. The value shall be incremented by 1 modulo 256 (see 3GPP TS 23.007 [3]).

All GSNs shall also maintain in volatile memory a Restart Counter for each GSN that it is in contact with. The Restart Counters stored for all GSNs that it is in contact with shall be cleared after the restart procedure has been completed (see 3GPP TS 23.007 [3]).