3 Supplementary service support procedures

24.0103GPPGeneral AspectsMobile radio interface layer 3Release 17Supplementary services specificationTS

3.1 General

This clause describes the supplementary service support procedures at the radio interface. These procedures are provided by the supplementary service support entity defined in 3GPP TS 24.007 [49]. 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

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

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 3GPP TS 24.008 [48] 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

At the terminating side a supplementary service support is regarded as being established when an MM‑connection is established. According 3GPP TS 24.008 [48] 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

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

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

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)

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

MS Network

REGISTER

————————————————————————————————————————————>

Facility (Invoke = Operation (Supplementary service code, Parameter(s)))

RELEASE COMPLETE

<————————————————————————————————————————————

Facility (Return result = Operation (Parameter(s)))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Return error (Error))

RELEASE COMPLETE

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Facility (Reject (Invoke_problem))

RELEASE COMPLETE (note)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

RELEASE COMPLETE (note)

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >

NOTE: To prevent transactions being kept open following exceptional cases, either side of the transaction may release it by sending a RELEASE COMPETE message without a Facility IE.

Figure 3.1: Mobile station initiated supplementary service transaction

3.6.2 Network initiated supplementary service transaction

MS Network

REGISTER

<————————————————————————————————————————————

Facility (Invoke = Operation (Supplementary service code, Parameter(s)))

RELEASE COMPLETE

————————————————————————————————————————————>

Facility (Return result = Operation (Parameter(s)))

RELEASE COMPLETE

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

Facility (Return error (Error))

RELEASE COMPLETE

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

Facility (Reject (Invoke_problem))

RELEASE COMPLETE (note 1, note 3)

– – – – — – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – ->

RELEASE COMPLETE (note 3)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

NOTE 1: If the network initiated operation does not require a result, reject or error to be returned then the MS shall release the transaction by sending a RELEASE COMPLETE message without a Facility Information Element.

NOTE 2: For network initiated unstructured SS data alternative procedures for connection release apply; refer to 3GPP TS 23.090 [20] and 3GPP TS 24.090 [35].

NOTE 3: To prevent transactions being kept open following exceptional cases, either side of the transaction may release it by sending a RELEASE COMPETE message without a Facility IE.

Figure 3.2: Network initiated supplementary service transaction

3.7 Handling of unknown, unforeseen, and erroneous protocol data

3.7.1 General

These procedures only apply to messages where the protocol discriminator is set to indicate call independent SS operations according to the rules in 3GPP TS 24.007 [49] and 3GPP TS 24.080 [27]. 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 3GPP TS 24.080 [27] or 3GPP TS 24.008 [48]. 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.

The following procedures are listed in order of precedence.

Handling of errors in the contents of the Facility IE is described in subclause 2.2.8, and is outside the scope of this subclause.

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

3.7.3 Unknown or unforeseen transaction identifier

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:

a) 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.

b) 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".

c) 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

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

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 3GPP TS 24.008 [48]); or

‑ an out of sequence IE encoded as "comprehension required";

is received, the MS shall proceed as follows:

a) If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 ‑ Invalid mandatory information".

b) If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message.

The network may follow the same procedures.

3.7.6 Unknown and Unforeseen IEs in the non‑imperative part

3.7.6.1 IEIs unknown in the message

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

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

If an information element with format T, TV or TLV (see 3GPP TS 24.007 [49]) 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

This category includes:

‑ syntactically incorrect optional IEs;

‑ conditional IE errors.

Errors in the content of the Facility IE are handled according to subclause 2.2.8.

3.7.7.1 Syntactically incorrect optional IEs (other than Facility)

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

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.