2 Generic procedures for the control of supplementary services
24.0103GPPGeneral AspectsMobile radio interface layer 3Release 17Supplementary services specificationTS
2.1 Overview of the generic protocol and its scope
One generic protocol is defined for the control of supplementary services at the radio interface. This protocol operates at layer 3 of the radio interface and assumes the use of layers 1 and 2 conform to 3GPP TS 45‑series and 3GPP TS 44.004, 3GPP TS 44.005 and 3GPP TS 44.006. The generic protocol uses the acknowledged information transfer service available at the layer 2 ‑ layer 3 interface.
The Functional protocol is based on the use of the Facility information element and the FACILITY message as well as other specific functional messages specified in 3GPP TS 24.080 [27].
Standardised services use a functional protocol. A transparent protocol is also provided. The functional protocol requires the knowledge of the related supplementary service by the mobile equipment supporting it. This facilitates mobile equipment operation without human intervention by defining semantics for the protocol elements which the mobile equipment can process on its own.
2.2 Functional procedures for the control of supplementary services
2.2.1 General
This clause specifies the functional signalling procedures for the control of supplementary services at the radio interface.
The Functional protocol utilises functions and services provided by 3GPP TS 24.008 [48] basic call control procedures and the functions of the data link layer as defined in 3GPP TS 44.00.
In UMTS only, integrity protected signalling (see TS 24.008 [48], subclause ‘Integrity Protection of Signalling Messages,’ and in general, see 3GPP TS 33.102) is mandatory. In UMTS only, all protocols shall use integrity protected signalling. Integrity protection of all SS signalling messages is the responsibility of lower layers. It is the network which activates integrity protection. This is done using the security mode control procedure (TS 25.331).
The defined procedures specify the basic methodology for the control (e.g. registration, erasure, invocation, etc.) of supplementary services.
The first category, called the Separate Message Category utilises separate message types to indicate a desired function. The hold and retrieve families of messages are identified for this category.
The second category called the Common Information Element Category utilises the Facility information element to transport the protocol defined in 3GPP TS 24.080 [27]. The use of the Facility information element is common to many services, and its contents indicates what type of procedure is being requested. This category can be signalled both in the mobile to network and the network to mobile directions.
The control of supplementary services includes the following cases:
a) the request of supplementary service procedures during the establishment of a call;
b) the request of supplementary service procedures during the clearing of a call;
c) the request of call related supplementary service procedures during the active state of a call;
d) the request of supplementary service procedures independent from an active call;
e) the request of multiple, different supplementary service procedures within a single message;
f) the request of supplementary service procedures related to different calls.
The correlation of a call related supplementary service operation and the call which it modifies is provided by use of the transaction identifier (cases a, b, c, e and f).
The correlation of supplementary service operations and their responses, is provided by the combination of the transaction identifier of the messages containing the Facility information element and the Invoke identifier present within the Facility information element itself (cases a, b, c, d, e and f).
The identification of different supplementary service operations within one single message is provided by the Invoke identifier present within the Facility information element itself (case e).
The identification of supplementary service related operations to different calls is provided by using different messages with the corresponding transaction identifier of the appropriate call (case f), i.e. different transaction identifier values are used to identify each call individually.
2.2.2 Separate Messages Category
The messages defined in this clause are specified as separate functional messages for the request, acknowledgement and rejection of specific procedures. These procedures can only be performed during the active phase of a call. The functions of these messages are not to be duplicated or overlapped by the ones of the Common Information Element Category.
The following separate messages are defined:
HOLD RETRIEVE
HOLD ACKNOWLEDGE RETRIEVE ACKNOWLEDGE
HOLD REJECT RETRIEVE REJECT.
For detailed description of the Hold and Retrieve functions see 3GPP TS 24.083.
2.2.3 Common Information Element Category
The Common Information Element Category uses operations defined in 3GPP TS 24.080 [27] for supplementary services signalling. Procedures are initiated by sending an operation including an invoke component. The invoke component may yield a Return Error, Return Result or Reject component (also included in an operation) depending on the outcome of the procedure.
The operation state machines, and procedures for management of Invoke IDs specified in CCITT Recommendation Q.774 White Book are used.
A REGISTER message, a FACILITY message or certain existing 3GPP TS 24.008 [48] Call Control message is used to carry the Facility information element which includes these operations. These operations request, acknowledge or reject the desired supplementary service procedure.
2.2.4 Call related supplementary service procedures
2.2.4.1 Supplementary service procedures at call establishment or call clearing
For call related supplementary service procedures initiated at call establishment or call clearing, the messages for call control specified in 3GPP TS 24.008 [48] are utilised to transport Facility information elements. This enables, for example the originating mobile user to send a supplementary service invoke component within a SETUP message and to receive from the network a Return result, Return error, or Reject component type within the Facility information element in an ALERTING message, CONNECT message, or any other appropriate message.
When a supplementary service invoke component is included within a SETUP message, the originating mobile station shall encode the Facility information element identifier according to one of the three possible ways (see 3GPP TS 24.008 [48]):
a) simple recall alignment;
b) advanced recall alignment;
c) recall alignment not essential.
Encoding of the Facility IEI within the SETUP message for different supplementary services is described in the subclause 2.2.4.1.1.
The three different ways of encoding are required to support the network initiated mobile originating call establishment (see subclause 2.2.4.1.2 and 3GPP TS 24.008 [48]).
2.2.4.1.1 Encoding of the Facility IEI for different supplementary services
The table 2.1 shows the encoding of the Facility IEI within the SETUP message for different supplementary services.
Table 2.1: Encoding of the Facility IE within the SETUP message
|
Service |
Facility IE Encoding |
|
CUG |
simple recall alignment |
|
UUS |
Advanced recall alignment |
2.2.4.1.2 Supplementary service procedures at network initiated mobile originating call establishment
The Facility and SS Version IE received in the set-up container of the CC_ESTABLISHMENT message shall be handled according to the following rules:
The mobile station shall examine the IEI of the Facility IE.
If the Facility IEI coding is "simple recall alignment", the mobile station shall copy the Facility IE and SS Version IE from the set-up container to the SETUP message without verifying or modifying the contents of these information elements.
If the Facility IEI is encoded as "advanced recall alignment", the mobile station shall examine the SS Version IE.
If the mobile station recognises the protocol defined by the SS Version IE, it shall attempt to decode the Facility IE. If the decoding is successful, and the operation is supported by the mobile station, the mobile station shall copy this Facility IE and SS Version IE to the SETUP message. The mobile station shall also store relevant supplementary service information contained within the Facility IE so that any reply to this Facility IE sent by the network will be properly understood and processed.
If the mobile station does not recognise the SS Version IE, or the decoding of the Facility IE is unsuccessful, then the call is rejected as described in 3GPP TS 24.008 [48].
If the Facility IE is encoded as "recall alignment not essential", the mobile station shall examine the SS Version IE .
If the mobile station recognises the protocol defined by the SS Version IE, it shall attempt to decode the Facility IE.
If the decoding is successful, and the operation is supported by the mobile station, the mobile station shall copy this Facility IE and SS Version IE into the SETUP message. The mobile station shall also store relevant supplementary service information contained within the Facility IE so that any reply to this Facility IE sent by the network will be properly understood and processed.
If the mobile station does not recognise the SS Version IE, or the decoding of the Facility IE is unsuccessful, then the SS Version IE and Facility IE are discarded, and NOT copied into the SETUP message.
NOTE: A mobile station may include a Facility IE without an associated SS Version IE. This would indicate that the SS operation is encoded using Phase 1 protocols.
2.2.4.2 Supplementary service procedures during the call
For call related supplementary service procedures during the active state of a call, the FACILITY message is used for the exchange of the Facility information elements.
Note that the FACILITY message can also be used for this purpose in all states after the SETUP message has been sent.
If the supplementary service procedure is related only to a single call, the FACILITY message will use the transaction identifier and protocol discriminator of this call.
If the supplementary service procedure affects more then one call, the FACILITY message may use the transaction identifier and protocol discriminator of one of these calls.
If a call related FACILITY message is sent using the transaction identifier of a call in progress, and this call is cleared due to call related causes, then the transaction identifier may not be cleared simultaneously in all cases. Depending upon the supplementary service invoked, one of the following will occur:
‑ the network or mobile user may retain both the connection and the transaction identifier association and may send a response within a Facility information element in a FACILITY message prior to the initiation of the normal call clearing procedures; or
‑ the network or mobile user may send a response with a Facility information element in the first clearing message (i.e. DISCONNECT, RELEASE or RELEASE COMPLETE message).
2.2.4.3 Handling of protocol errors in call related SS procedures
Messages containing a Facility information element shall be checked for protocol errors before the contents of the Facility IE is acted on. The checks shall be performed in the following order:
1) The message carrying the Facility IE shall be checked for protocol errors as specified in 3GPP TS 24.008 [48]. If a protocol error is found then the procedures in 3GPP TS 24.008 [48] apply.
2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 2.2.8. If a protocol error is found then the procedures in subclause 2.2.8 apply.
2.2.4.4 Handling of other errors in call related SS procedures
If the tests specified in subclause 2.2.4.3 have been passed without the detection of a protocol error, the receiver will attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in the individual service specifications apply.
Examples of the behaviour that could occur in this case are:
‑ the network or MS clears the call and rejects the supplementary services request by means of a clearing message which contains a Return Error component with the appropriate parameter in the Facility Information Element;
‑ the network and MS continue to process the call according to normal 3GPP TS 24.008 [48] call control procedures. The supplementary services request is rejected by means of a FACILITY message or appropriate call control message containing a Return Error component with the appropriate parameter in the Facility Information Element;
‑ the network and MS continue to process the call according to the normal 3GPP TS 24.008 [48] call control procedures. The supplementary services request is ignored.
2.2.5 Call independent supplementary service procedures
2.2.5.1 Introduction
For supplementary service procedures independent of any call, the initiating side must establish a MM‑connection between the network and the MS according to the rules given in 3GPP TS 24.007 [49] and 3GPP TS 24.008 [48]. The call independent supplementary service procedures shall apply to both CS and PS domain for some specific services. On PS domain, a PS-signalling connection shall be established between the network and the MS instead of a MM-connection. Throughout this specification, the term MM-connection is used to denote a MM-connection for CS domain or PS-signalling connection for PS domain, as appropriate. The MS or the network starts the transaction by transferring a REGISTER message across the radio interface. This transaction is identified by the transaction identifier associated with the REGISTER message, and the Invoke identifier present in the component part of the Facility information element. Following the REGISTER message one or more FACILITY messages may be transmitted, all of them related by the use of the same transaction identifier. If the transaction is no longer used, it shall be released by sending a RELEASE COMPLETE message. This procedure is specified in detail in clause 3, and the text in clause 3 takes precedence over this introduction.
To convey the supplementary service invocation, the Facility information element is used. The Facility information element present either in the REGISTER message or a subsequent message identifies the supplementary service involved and the type of component (i.e. Invoke, Return result, Return error or Reject component).
When the REGISTER or FACILITY message contains a Facility information element and the requested service is available, a FACILITY message containing a Facility information element may be returned. One or more exchanges of FACILITY messages may subsequently occur. To terminate the service interaction and release the transaction identifier value, a RELEASE COMPLETE message is sent as specified for the specific supplementary service procedure. The RELEASE COMPLETE message may also contain the Facility information element.
2.2.5.2 Handling of protocol errors in call independent SS procedures
Messages containing a Facility information element shall be checked for protocol errors before the contents of the Facility IE is acted on. The checks shall be performed in the following order:
1) The message carrying the Facility IE shall be checked for protocol errors as specified in subclause 3.7. If a protocol error is found then the procedures in subclause 3.7 apply.
2) The contents of the Facility IE shall be checked for protocol errors as specified in subclause 2.2.8. If a protocol error is found then the procedures in subclause 2.2.8 apply.
2.2.5.3 Handling of other errors in call independent SS procedures
If the tests specified in subclause 2.2.5.2 have been passed without the detection of a protocol error, the receiver will attempt to process the contents of the Facility Information Element. If errors occur during this processing (e.g. system failure, or information in the Facility IE is incompatible with the requested operation) then the procedures specified in the individual service specifications apply.
An example of the behaviour that could occur in this case is:
‑ the MS or network sends a Facility information element containing a return error component in a FACILITY or RELEASE COMPLETE message. If the FACILITY message is used then the MM Connection may continue to be used for further signalling.
2.2.6 Multiple supplementary service invocations
2.2.6.1 Call related supplementary service procedures
Simultaneous requests for different supplementary service procedures (i.e. using more than one operation in the Facility information element) are permitted. Interactions between different operations shall be managed by processing the operations in the order in which they appear in the Facility information element.
2.2.6.2 Call independent supplementary service procedures
Where permitted by the relevant stage 3 specification, multiple operations may be sent on the same transaction.
It is possible for several call independent SS transactions to be used simultaneously. Call independent SS transactions can also exist in parallel with other CM‑Layer and MM transactions. The handling of multiple MM connections is defined in 3GPP TS 24.007 [49]and 3GPP TS 24.008 [48].
For call independent operations a single Facility Information Element shall not contain more than one component.
2.2.7 Recovery procedures
2.2.7.1 Call related supplementary service recovery procedures
There are no additional recovery procedures for call related supplementary service signalling on the radio path. The recovery procedures as specified for the basic service apply.
2.2.7.2 Call independent supplementary service recovery procedures
In case a transaction is not terminated according to the normal procedure as described in technical specifications 3GPP TS 24.08x and 24.09x‑series, the network side has to ensure that the transaction is terminated e.g. by a supervision timer.
2.2.8 Generic protocol error handling for the component part of supplementary services operations
If (according to the rules specified in 3GPP TS 29.002 [45]) a supplementary service operation is to be rejected the operation will be denied, and provided the transaction is still in progress, an appropriate reject component will be returned in a Facility Information Element.
The handling of the transaction depends on whether the operation is call related or call independent.
2.2.8.1 Call related component errors
If the call related transaction is still in progress then a reject component shall be sent. Any message which contains a Facility Information Element may be used. In general, the transaction (call) associated with the rejected operation shall not be automatically released by the entity that detects the error. The transaction (call) may be released in some exceptional cases where security related services are involved (e.g. Advice of Charge (Charging)). If this behaviour is required, then it will be specified in the relevant specification for the individual service.
When a reject component for a call related operation is received by a MS or MSC then it may initiate release of the transaction (call) if this is a specified action for the service the SS operation relates to.
Note that this behaviour is intended to allow security related services to release calls if one entity in the system does not support the service. The normal action should be to allow the call to continue.
If the call related transaction has terminated before the operation has been rejected (e.g. the component containing the error was sent in a RELEASE COMPLETE message) then the contents of the component shall be ignored, and no reject component is sent.
2.2.8.2 Call independent component errors
2.2.8.2.1 Single component errors
The reject component shall be sent in a RELEASE COMPLETE message.
If the component containing the error was itself sent in a RELEASE COMPLETE message then the contents of the component shall be ignored, and no reject component is sent.
2.2.8.2.2 Multiple component errors
If a single Facility IE contains more than one component then a RELEASE COMPLETE message with the cause "Facility rejected" and without any component shall be sent.