Content for TS 24.010 Word version: 18.0.0
3 Supplementary service support procedures
3.1 General
3.2 Supplementary service support establishment
3.3 Supplementary service support information transfer phase
3.4 Supplementary service support release
3.5 Recovery procedures
3.6 Message flow (single operation example)
3.7 Handling of unknown, unforeseen, and erroneous protocol data
...
...
3 Supplementary service support procedures p. 15
3.1 General p. 15
This clause describes the supplementary service support procedures at the radio interface. These procedures are provided by the supplementary service support entity defined in TS 24.007. The supplementary service support procedures provide the means to transfer messages for the call independent supplementary service procedures. These procedures are regarded as the user of the supplementary service support.
3.2 Supplementary service support establishment p. 15
At the beginning of each call independent supplementary service procedure a supplementary service support must be established.
3.2.1 Supplementary service support establishment at the originating side p. 15
If the entity that uses the supplementary support procedures wants to send a REGISTER message, the supplementary service support entity shall first request the establishment of an MM-connection. This MM-connection is established according to TS 24.008 and 04.07. If the network is the initiating side then MM-connection establishment may involve paging the MS.
The supplementary service support entity shall send the REGISTER message as the first CM-message on the MM-connection. The REGISTER message is sent to the corresponding peer entity on the MM-connection and the supplementary service support shall be regarded as being established.
3.2.2 Supplementary service support establishment at the terminating side p. 15
At the terminating side a supplementary service support is regarded as being established when an MM-connection is established. According TS 24.008 this can be ascertained by the receipt of the first message, with a new transaction identifier. For successful establishment of supplementary service support this message shall be a REGISTER message.
If the terminating side wishes to reject the establishment of supplementary services support then it may be immediately initiate supplementary services support release (see subclause 3.4).
3.3 Supplementary service support information transfer phase p. 15
Upon the establishment of the supplementary service support both users may exchange FACILITY messages by use of the supplementary service support.
3.4 Supplementary service support release p. 15
At the end of each call independent supplementary service procedure the established supplementary service support is released.
The side closing the transaction shall release the transaction by sending the RELEASE COMPLETE message to its corresponding peer entity.
Both supplementary service support entities release the MM-connection locally.
3.5 Recovery procedures p. 16
The supplementary service support does not provide recovery procedures, i.e. the operations are transparent to the supplementary service support.
3.6 Message flow (single operation example) p. 16
This subclause contains examples of message flows for a single transaction consisting of a single operation. These examples may not show all possibilities.
3.6.1 Mobile station initiated supplementary service transaction p. 16
Figure 3.1: Mobile station initiated supplementary service transaction
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
3.6.2 Network initiated supplementary service transaction p. 17
3.7 Handling of unknown, unforeseen, and erroneous protocol data p. 17
3.7.1 General p. 17
These procedures only apply to messages where the protocol discriminator is set to indicate call independent SS operations according to the rules in TS 24.007 and TS 24.080. Messages that do not meet this criteria are treated according to other GSM technical specifications.
This subclause specifies procedures for handling of unknown, unforeseen and erroneous protocol data by the receiving entity. The procedures are called "error handling procedures", but they also define a compatibility mechanism for future extension of the protocol.
Most error handling procedures are mandatory in the MS, but optional in the network. Detailed error handling procedures may vary from PLMN to PLMN.
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 TS 24.080 or TS 24.008. However, it is not a syntactical error if a type 4 IE specifies a length indicator greater than that defined. The component part of the Facility information element is handled by a separate mechanism, and errors in the component part are not covered by this subclause.
3.7.2 Message too short p. 18
When a message is received that is too short to contain a complete message type information element, that message shall be ignored.
3.7.3 Unknown or unforeseen transaction identifier p. 18
The MS shall ignore messages with the transaction identifier value set to "111".
If the transaction identifier value is not "111" the following procedures shall apply to the MS:
- If a RELEASE COMPLETE message is received specifying a transaction identifier that is not recognised as relating to a call independent SS transaction that is in progress then the message shall be ignored.
- If a FACILITY message is received specifying a transaction identifier that is not recognised as relating to a call independent SS transaction that is in progress then a RELEASE COMPLETE message shall be sent with cause value #81 "invalid call reference value".
- If a REGISTER message is received specifying a transaction identifier that is not recognised as relating to a call independent SS transaction that is in progress and with a transaction identifier flag incorrectly set to "1", this message shall be ignored. The network may follow the same procedures.
3.7.4 Unknown or unforeseen message type p. 18
If the MS receives a message type not defined for the protocol discriminator or not implemented by the receiver, then a RELEASE COMPLETE message shall be sent with cause value #97 "message type non-existent or not implemented".
If the MS receives a message type not consistent with the transaction state then a RELEASE COMPLETE message shall be sent with cause value #98 "message not compatible with control state".
The network may follow the same procedures.
3.7.5 Non-semantical mandatory Information Element Error p. 18
When on receipt of a message:
- an "imperative message part" error; or
- a "missing mandatory IE" error;
- a syntactically incorrect mandatory IE; or
- an IE unknown in the message, but encoded as "comprehension required" (see TS 24.008); or
- an out of sequence IE encoded as "comprehension required";
- If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 - Invalid mandatory information".
- If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message.
3.7.6 Unknown and Unforeseen IEs in the non-imperative part p. 19
3.7.6.1 IEIs unknown in the message p. 19
The MS shall ignore all IEs unknown in the message which are not encoded as "comprehension required".
The network shall take the same approach.
3.7.6.2 Out of sequence IEs p. 19
The MS shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required".
The network may take the same approach.
3.7.6.3 Repeated IEs p. 19
If an information element with format T, TV or TLV (see TS 24.007) 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.
The network may follow the same procedures.
3.7.7 Non-imperative message part errors p. 19
This category includes:
- syntactically incorrect optional IEs;
- conditional IE errors.
3.7.7.1 Syntactically incorrect optional IEs (other than Facility) p. 19
The MS shall treat all optional IEs that are syntactically incorrect in a message as not present in the message
The network shall take the same approach.
3.7.7.2 Conditional IE errors p. 19
When the 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 (other than Facility), it shall send a RELEASE COMPLETE message with cause #100 "conditional IE error".
The network may follow the same procedure.
