Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.010  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   2…   3…   4…   5…

 

3  Supplementary service support proceduresp. 15

3.1  Generalp. 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 establishmentp. 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 sidep. 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.
Up

3.2.2  Supplementary service support establishment at the terminating sidep. 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).
Up

3.3  Supplementary service support information transfer phasep. 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 releasep. 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 proceduresp. 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 transactionp. 16

Copy of original 3GPP image for 3GPP TS 24.010, Fig. 3.1: Mobile station initiated supplementary service transaction
Up

3.6.2  Network initiated supplementary service transactionp. 17

Copy of original 3GPP image for 3GPP TS 24.010, Fig. 3.2: Network initiated supplementary service transaction
Up

3.7  Handling of unknown, unforeseen, and erroneous protocol datap. 17

3.7.1  Generalp. 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.
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.
Up

3.7.2  Message too shortp. 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 identifierp. 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:
  1. 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.
  2. 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".
  3. 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.
Up

3.7.4  Unknown or unforeseen message typep. 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.
Up

3.7.5  Non-semantical mandatory Information Element Errorp. 18

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 TS 24.008); or
  • an out of sequence IE encoded as "comprehension required";
is received, the MS shall proceed as follows:
  1. If the message is not RELEASE COMPLETE it shall send a RELEASE COMPLETE message with cause "#96 - Invalid mandatory information".
  2. If the message is RELEASE COMPLETE, it shall be treated as a normal RELEASE COMPLETE message.
The network may follow the same procedures.
Up

3.7.6  Unknown and Unforeseen IEs in the non-imperative partp. 19

3.7.6.1  IEIs unknown in the messagep. 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 IEsp. 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 IEsp. 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.
Up

3.7.7  Non-imperative message part errorsp. 19

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

Up   Top   ToC