10 Error handling

09.603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol GPT) across the Gn and Gp InterfaceRelease 1998TS

10.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 sub-sections 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 is always mandatorily 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.

A GTP signalling Request is distinguished from a GTP signalling Response by the Signalling message names (sub-clause 7.2, Signalling Message Formats). The Error Indication, the Version Not Supported and the SGSN Context Acknowledge messages shall be considered as Responses for the purpose of this Section.

The subsections 10.1.1 to 10.1.13 shall be applied in decreasing priorities.

10.1.1 Different GTP versions

If a receiving node receives a GTP signalling 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 G-PDU shall then be discarded. All GSNs shall be able to support all earlier GTP versions.

10.1.2 GTP Message too short

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

10.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.

10.1.4 Unexpected GTP signalling message

When an unexpected GTP signalling message is received, e.g. a Response message for which there is no corresponding outstanding Request, or a GTP signalling message sent in the wrong direction, it shall be silently discarded.

10.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.

10.1.6 Invalid Length

In a received GTP signalling message Request, if a mandatory TLV format information element has a Length different from the Length defined in the version that this message claims to use, then this information element shall be discarded, the error should be logged, and a Response shall be sent with Cause set to ‘Mandatory IE incorrect’.

In a received GTP signalling message Response, if a mandatory TLV format information element has a Length different from the Length defined in the version that this message claims to use, then the requesting entity shall treat the GTP signalling procedure as having failed.

10.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 which is defined as ‘spare’.

10.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 which is defined as ‘spare’.

10.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 a TV element, the receiver shall discard the rest of the message.

If the receiving GSN cannot interpret the rest of the message because of the ignored information element, the receiving GSN 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’.

10.1.10 Out of sequence information elements

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

10.1.11 Unexpected information element

An information element with a Type value which is defined in GTP 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.

10.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.

10.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 GSN may not handle the message correctly because of the incorrect information element, the receiving GSN should log the error and shall return a response with Cause set to ‘Optional IE incorrect’.

10.2 Path failure

A path counter shall be reset each time a signalling response is received on the path and incremented when the T3-RESPONSE timer expires for any signalling message sent on the path. The path shall be considered to be down if the counter exceeds N3-REQUESTS. In this case, the GSN 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.

10.3 MS detach

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

10.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 TS GSM 03.07).

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 TS GSM 03.07).