16 Error Handling and Future Compatibility

09.183GPPGeneral Packet Radio Service (GPRS)Gs interface layer 3 specificationServing GPRS Support Node (SGSN) - Visitors Location Register (VLR)TS

16.1 General

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

In this clause the following terminology is used:

– an IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved", or if its value part violates coding rules. However, it is not a syntactical error that an IE specifies in its Length Indicator a greater length than defined in the relevant clause; and

– a message is defined to have semantically incorrect contents if it contains information which, possibly dependant on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part of 3GPP TS 09.18.

When a receiving entity detects the need to send a BSSAP+-MOBILE-STATUS message (see errors detailed below), the entity shall copy the IMSI IE value (if included) of the incorrect message to the IMSI IE on the BSSAP+-MOBILE-STATUS message. The message in error is also included in the BSSAP+-MOBILE-STATUS message. Both the receiving and the sending entity shall abandon the procedure related to the incorrect message and return to the state from where the procedure related to the incorrect message was started.

Both the receiving and the sending entity shall inform the O&M entity upon sending or receiving a BSSAP+-MOBILE-STATUS message.

The next subclauses in this clause shall be applied in order of precedence.

16.2 Message too short

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

16.3 Unknown or unforeseen message type

If a message is received with a message type not defined or not implemented by the receiver it shall ignore the message. A BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to “message unknown” and the Erroneous message IE containing the received message shall be returned.

If a message is received that is not compatible with the protocol state, a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to “message not compatible with the protocol state” and the erroneous message shall be returned.

If a message is received that is not defined to be received by that entity (i.e. the message is sent in the wrong direction) it shall be treated as unknown message and the message shall be ignored. A BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to “message unknown” and the Erroneous message IE containing the received message shall be returned.

16.4 Missing mandatory information element

When on receipt of a message, and a "missing mandatory IE" error is diagnosed, the receiver shall ignore the message and return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "missing mandatory information element" and shall return the Erroneous message information element containing the received message.

16.5 IEs unknown or unforeseen in the message

All IEs unknown or unforeseen in a message shall be ignored.

16.6 Out of sequence IEs

All IEs that are out of sequence shall be ignored.

16.7 Repeated IEs

If an information element with format T, TV, or TLV is repeated in a 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. If the limit on repetition of information elements is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all subsequent repetitions of the information element shall be ignored.

16.8 Syntactically incorrect mandatory IE.

On receipt of a message which contains a syntactically incorrect mandatory IE, the receiver shall ignore the message and return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "invalid mandatory information" and shall return the Erroneous message information element containing the received message.

16.9 Syntactically incorrect optional IEs

All optional IEs that are syntactically incorrect in a message shall be treated as not present in the message.

16.10 Conditional IE errors

When a VLR or SGSN 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 which is required to be present in the message, a VLR or SGSN shall ignore the message and return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "conditional IE error" and shall return the Erroneous message information element containing the received message.

When a VLR or SGSN receives a message containing a syntactically incorrect conditional IE which is not required to be present in the message, nor required to be absent in the message, then a VLR or SGSN shall ignore that IE.

16.11 IEs with semantically incorrect contents

When an IE with semantically incorrect contents is received, the foreseen reactions of the procedural part of 3GPP TS 09.18 are performed.

If however no such reactions are specified, the receiving entity shall ignore that IE and treat the rest of the message. If, because this IE was ignored, the rest of the message can no longer be handled then the receiving entity shall return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "semantically incorrect message" and shall return the Erroneous message information element containing the received message.