8 Handling of unknown, unforeseen, and erroneous protocol data

3GPP44.056CTS radio interface layer 3 specificationGSM Cordless Telephony System (CTS), Phase 1Release 17TS

8.1 General

The procedures specified in GSM 04.56 and call-related supplementary service handling in GSM 04.10 apply to those messages which pass the checks described in this subclause.

This subclause also 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 protocols.

Error handling concerning the value part of the Facility IE and of the SS Version Indicator IE are not in the scope of the present document. It is defined in GSM 04.10 and the GSM 04.8x series.

Subclauses 8.1 to 8.8 shall be applied in order of precedence.

Most error handling procedures are mandatory for the CTS‑MS.

Detailed error handling procedures in the CTS‑FP are implementation dependent and may vary. However, when extensions of this protocol are developed, CTS-FP will be assumed to have the error handling that is indicated in this subclause as mandatory ("shall") and that is indicated as strongly recommended ("should"). Subclauses 8.2, 8.3, 8.4, 8.5 and 8.7.2 do not apply to the error handling in the CTS‑FP applied to the receipt of initial layer 3 message: If the CTS-FP diagnoses an error described in one of these subclauses in the initial layer 3 message received from the CTS‑MS, it shall either:

– try to recognise the classmark and then take further implementation dependent actions; or

– release the RR-connection.

Also, the error handling of the CTS‑FP is only considered as mandatory or strongly recommended when certain thresholds for errors are not reached during a dedicated connection.

In this subclause 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" in clause 10, or if its value part violates rules of clause 10. However it is not a syntactical error that a type 4 IE specifies in its length indicator a greater length than defined in clause 10.

– A message 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 (i.e. clauses 4 and 5) of GSM 04.58, GSM 04.10, or relevant GSM 04.8X series.

8.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, see GSM 04.07.

8.3 Unknown or unforeseen transaction identifier

See GSM 04.08 clause 8.3. The CTS-FP shall act as the "network", whereas it is stated so.

8.4 Unknown or unforeseen message type

If a CTS‑MS receives a message with message type not defined for the PD and SPD or not implemented by the receiver in unacknowledged mode, it shall ignore the message.

If a CTS‑MS receives a message with message type not defined for the PD and SPD or not implemented by the receiver in acknowledged mode, it shall return a status message (STATUS, CTS RR STATUS or MM STATUS depending on the protocol discriminator and sub-protocol discriminator) with cause # 97 "message type non-existent or not implemented".

If the CTS‑FP receives an RR message or MM message with message type not defined for the PD or not implemented by the receiver in a protocol state where reception of an unsolicited message with the given PD from the CTS‑MS is not foreseen in the protocol, the CTS‑FP actions are implementation dependent. Otherwise, if the CTS-FP receives a message with message type not defined for the PD and the SPD or not implemented by the receiver, it shall ignore the message except that it should return a status message (STATUS, CTS RR STATUS or MM STATUS depending on the protocol discriminator and Sub-Protocol Discriminator) with cause #97 "message type non-existent or not implemented".

NOTE: A message type not defined for the PD and SPD in the given direction is regarded by the receiver as a message type not defined for the PD and SPD, see GSM 04.07 [20].

If the CTS‑MS receives a message not compatible with the protocol state, the CTS‑MS shall ignore the message except for the fact that, if an RR connection exists, it returns a status message (STATUS, CTS RR STATUS or MM STATUS depending on the protocol discriminator and sub-protocol discriminator) with cause #98 "Message type not compatible with protocol state".

If the CTS‑FP receives a message not compatible with the protocol state, the CTS‑FP actions are implementation dependent.

8.5 Non-semantical mandatory information element errors

When on receipt of a message:

– an "imperative message part" error; or

– a "missing mandatory IE" error;

is diagnosed or when a message containing:

– a syntactically incorrect mandatory IE; or

– an IE unknown in the message, but encoded as "comprehension required" (see subclause 10.5); or

– an out of sequence IE encoded as "comprehension required" (see subclause 10.5)

is received,

– the CTS‑MS station shall proceed as follows:

If the message is not one of the messages listed in subclauses 8.5.1, 8.5.2, and 8.5.3, the CTS‑MS shall ignore the message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, CTS RR STATUS or MM STATUS depending on the protocol discriminator and sub-protocol discriminator) with cause # 96 "invalid mandatory information".

– the CTS‑FP shall proceed as follows:

When the message is not one of the messages listed in subclause 8.5.3 b), c), d) or e), the CTS‑FP shall either

– try to treat the message (the exact further actions are implementation dependent); or

– ignore the message except that it should return a status message (STATUS, CTS RR STATUS, or MM STATUS depending on the protocol discriminator and sub-protocol discriminator) with cause # 96 "invalid mandatory information".

8.5.1 Radio resource management

For the CTS‑MS the following procedures shall apply:

– If the message is a CTS CHANNEL RELEASE message, the actions taken shall be the same as specified in subclause 4.4.13 "RR connection release".

8.5.2 Mobility management

No exceptional cases are described for mobility management messages.

8.5.3 Call control

See GSM 04.08 subclause 8.5.3.

8.6 Unknown and unforeseen IEs in the non-imperative message part

8.6.1 IEIs unknown in the message

The CTS‑MS shall ignore all IEs unknown in a message which are not encoded as "comprehension required".

The CTS‑FP shall take the same approach.

8.6.2 Out of sequence IEs

The CTS‑MS shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required".

The CTS-FP should take the same approach.

8.6.3 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 in clause 9 of the present document, 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.

The CTS‑FP should follow the same procedures.

8.7 Non-imperative message part errors

This category includes:

– syntactically incorrect optional IEs;

– conditional IE errors.

8.7.1 Syntactically incorrect optional IEs

The CTS‑MS shall treat all optional IEs that are syntactically incorrect in a message as not present in the message.

The CTS‑FP shall take the same approach.

8.7.2 Conditional IE errors

When the CTS‑MS upon receipt of a message 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, it shall ignore the message except for the fact that, if an RR connection exists, it shall return a status message (STATUS, CTS RR STATUS, or MM STATUS depending on the PD and SPD) with cause value # 100 "conditional IE error".

When the CTS‑FP receives a message and diagnose 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, the CTS‑FP shall either:

– try to treat the message (the exact further actions are implementation dependent); or

– ignore the message except that it should return a status message (STATUS, CTS RR STATUS or MM STATUS depending on the protocol discriminator and sub-protocol discriminator) with cause # 100 "conditional IE error".

8.8 Messages with semantically incorrect contents

When a message with semantically incorrect contents is received, the foreseen reactions of the procedural part of GSM 04.56 (i.e. of clauses 5, 5, 6) are performed. If however no such reactions are specified, the CTS‑MS shall ignore the message except for the fact that, if an RR connection exists, it returns a status message (STATUS, CTS RR STATUS, or MM STATUS depending on the PD and SPD) with cause value # 95 "semantically incorrect message".

The CTS‑FP should follow the same procedure except that a status message is not normally transmitted.

Semantic checking of the Facility information element value part (defined in GSM 04.80) is the subject of the technical specifications GSM 04.10 and the GSM 04.8x series.