11.4 Handling of superfluous information

24.0073GPPGeneral AspectsMobile radio interface signalling layer 3Release 17TS

All equipment should be able to ignore any extra information present in an L3 message, which is not required for the proper operation of that equipment. For example, a mobile station may ignore the calling party BCD number if that number is of no interest to the Mobile Station when a SETUP message is received.

11.4.1 Information elements that are unnecessary in a message

The relevant protocol specification may define certain IEs to be under some conditions unnecessary in a L3 message. A protocol entity detecting an unnecessary IE in a received L3 message shall ignore the contents of that IE for treating the message; it is not obliged to check whether the contents of the IE are syntactically correct.

11.4.2 Other syntactic errors

This clause applies to the analysis of the value part of an information element. It defines the following terminology:

– 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 syntactic rules given in the specification of the value part.

– It is not a syntactical error that a type 4 and type 6 standard IE specifies in its length indicator a greater length than possible according to the value part specification: extra bits shall be ignored.

– It should not be considered a syntactical error if a type 4 and type 6 IE is received with a shorter length than defined in this version of the specification if the IE is correctly encoded according to an earlier version of the specification.

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

Annex A (informative):
MN‑Services arrow diagram

Figure A.1: Mobile originated Call Setup. Successful case

Figure A.2: Mobile terminated Call Setup. Successful case

Figure A.3: Mobile originated, Call Release and Channel Release. Successful case

Figure A.4: Location updating. Successful case

Figure A.5: Handover. Successful case

Figure A.6: Establishment of parallel transactions (General view)

Figure A.7: Release of parallel transactions (General view)

Annex B (informative):
Description of CSN.1

The goal of the notation described hereafter is to describe the structure of the syntactically correct messages for a given signalling protocol, or of part of such messages. The notation addresses the cases where the concrete messages are binary strings. The notation allows to describe sets of strings: the structure of a message defined a protocol defines a set of allowable bit strings. It also allows to put labels on parts of strings that follow a given structure.

One aspect of the specification of message set is to define the set of strings that are acceptable as when received. All the strings that cannot be recognized as syntactically correct messages are to be rejected for syntactical reasons. In many cases, only a subset of this set are allowed to be sent. The notation allows also to distinguish the set of the strings that can be sent and the set of strings that are recognized as syntactically correct.

Another aspect of the specification of messages is the splitting of an acceptable string in a number of sub-strings that will be use to derive the exact significance of the message. The notation provides this function by labelling sub-strings. These labels can then in turn be used in textual or formal semantic descriptions which are not covered in the present document.

The notation described here could be enhanced in the future, with the addition of new rules.