8 SS Notifications

23.0783GPPCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4Release 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 Architecture

8.1.1 Functional Entities used for CAMEL

This subclause describes the functional architecture needed to support Supplementary Service (SS) Notifications. Figure 8.1 shows the functional entities involved in sending SS Notifications. The architecture is applicable to the third phase of CAMEL or higher.

Figure 8.1: Functional architecture for support of SS Notifications

HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding SS‑CSI. The SS‑CSI is sent to the VLR at Location Update, on Data Restoration or if the SS‑CSI is updated by administrative action. When processing an invocation of the CCBS supplementary service, the HLR shall send a notification of the invocation of the supplementary service to the gsmSCF if required by the SS‑CSI.

MSC: When processing an invocation of any of the supplementary services ECT, CD and MPTY, the MSC may receive an SS‑CSI from the VLR, indicating that a notification of the invocation of the supplementary service shall be sent to the gsmSCF.

VLR: The VLR stores the SS‑CSI as a part of the subscriber data for subscribers roaming in the VLR area.

gsmSCF: The gsmSCF receives the SS Invocation Notification from the MSC or HLR.

8.1.2 Interfaces defined for SS Notifications

This subclause describes the different interfaces applicable to SS Notifications. It specifies on a high level the functions specific to SS Notifications.

8.1.2.1 MSC – gsmSCF interface

This interface is used by the MSC to send supplementary service invocation notifications to the gsmSCF. The SS invocations that can be notified to the gsmSCF via this interface are Call Deflection (CD), Explicit Call Transfer (ECT) and Multi Party (MPTY).

8.1.2.2 HLR – gsmSCF interface

This interface is used by the HLR to send supplementary service invocation notifications to the gsmSCF. The SS invocation that can be notified to the gsmSCF via this interface is Call Completion to Busy Subscriber (CCBS).

8.1.2.3 VLR – MSC interface

This interface is used by the VLR to transfer SS‑CSI to the MSC.

8.1.2.4 HLR-VLR interface

This interface is used by the HLR to send the SS‑CSI to the VLR or to remove SS‑CSI from the VLR.

8.2 Description of CAMEL Subscriber Data

8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS‑CSI)

This subclause defines the contents of the Supplementary Service Invocation Notification CAMEL Subscription Information (SS‑CSI).

8.2.1.1 Notification criteria

This data indicates for which supplementary services notifications shall be sent. The supplementary services which may be indicated are ECT, CD, CCBS and MPTY.

8.2.1.2 gsmSCF address

Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing.

8.2.1.3 CSI state

The CSI state indicates whether the SS‑CSI is active or not.

8.2.1.4 Notification flag

The notification flag indicates whether the change of the SS‑CSI shall trigger Notification on Change of Subscriber Data or not.

8.2.2 gsmSCF address list for CSI

The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI.

8.3 Procedures for CAMEL

8.3.1 Handling of Supplementary Service Invocation Notification

At the invocation of any of the services ECT, CD and MPTY the VLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS‑CSI and the particular invoked supplementary service is marked in the SS‑CSI. If this is the case a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS‑CSI. The processing of the particular SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification is sent.

The sending of the notification is independent of call related CAMEL processing, i.e. processing indicated by O/D/T/VT‑CSI.

On invocation of ECT, the VLR shall include the SS‑CSI in the Invoke ECT response message (see Process MAF027 in 3GPP TS 23.091 [25]) to the MSC if applicable for ECT.

On invocation of MPTY, the VLR shall include the SS‑CSI in the Process MPTY message (see Process MPTY_MAF026 in 3GPP TS 23.084 [21]) to the MSC if applicable for MPTY.

On invocation of CD, the VLR shall include the SS‑CSI in the Send Info For Incoming Call ack information flow to the MSC if applicable to CD (see 3GPP TS 23.072 [16]).

When a subscriber activates a CCBS request, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether

– The subscriber is provisioned with an active SS‑CSI, and

– CCBS is marked in the SS‑CSI.

If the criteria are fulfilled, a notification is immediately sent to the gsmSCF given by the gsmSCF address contained in the SS‑CSI and the processing of the CCBS request continues. Whenever the state of the CCBS request changes (see 3GPP TS 23.093 [26]), an additional notification is immediately sent to the gsmSCF and the processing of the CCBS request continues.

If the criteria are not fulfilled, the processing of the CCBS request continues unchanged and no notifications are sent.

At the invocation of the CCBS supplementary service, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS‑CSI and the particular invoked supplementary service is marked in the SS‑CSI. If this is the case, a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS‑CSI. The processing of the SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification are sent.

8.4 Description of information flows

This subclause contains the detailed description of the information flows used by CAMEL for notification of Supplementary Service invocation.

Each Information Element (IE) is marked as Mandatory (M), Specific conditions (S) or Optional (O) in the "Status" column.

An ‘M’ IE shall always be included. The conditions for the inclusion of an ‘S’ IE are shown in the ‘Description’ column of the definition table. An ‘O’ IE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol.

The following principles apply for the handling of the IEs by the receiving entity:

– The gsmSCF may silently discard any IE which it does not functionally support.

Details of errors and exceptions to these rules are specified in are specified in 3GPP TS 29.002 [34].

8.4.1 MSC to gsmSCF information flows

8.4.1.1 SS Invocation Notification

8.4.1.1.1 Description

This IF is generated by the MSC when it shall notify the gsmSCF of a supplementary service invocation.

8.4.1.1.2 Information Elements

Information element name	Status	Description
Notification Event	M	This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Explicit Call Transfer, Call Deflection, Multi Party.
Notification Event Specific Information	S	In the case of ECT, the sending entity shall include the called party for each call originated by the subscriber and relevant to the ECT invocation. Note: the subscriber may have originated zero, one or two calls relevant to the ECT service. In the case of CD, the deflected to number shall be included in this IE. In the case of MPTY, this IE shall be omitted.
IMSI	M	This IE identifies the mobile subscriber who has invoked the supplementary service to be notified.
MSISDN	M	This IE identifies the mobile subscriber who has invoked the supplementary service to be notified.

8.4.2 HLR to VLR information flows

8.4.2.1 Delete Subscriber Data

8.4.2.1.1 Description

This IF is used by the HLR to delete CAMEL subscription data from a VLR. Ii is specified in 3GPP TS 29.002 [34].

8.4.2.1.2 Information Elements

The Delete Subscriber Data IF contains the following CAMEL specific information elements for SS Notifications:

Information element name	Status	Description
CAMEL Subscription Info Withdraw	O	This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR.
Specific CSI Withdraw	O	This IE is used to indicate that only SS‑CSI shall be deleted from the VLR. This IE should not be present when CAMEL Subscription Info Withdraw is present.

Information element name

Status

Description

CAMEL Subscription Info Withdraw

This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR.

Specific CSI Withdraw

This IE is used to indicate that only SS‑CSI shall be deleted from the VLR.

This IE should not be present when CAMEL Subscription Info Withdraw is present.

8.4.2.2 Insert Subscriber Data

8.4.2.2.1 Description

This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TS 29.002 [34].

8.4.2.2.2 Information Elements

The Insert Subscriber Data contains the following CAMEL specific information element for SS Notifications:

Information element name	Status	Description
SS‑CSI	O	This IE is described in subclause 8.2.1. This IE identifies the subscriber as having supplementary service invocation notification services. It contains the Notification Criteria and gsmSCFAddress. When SS‑CSI is sent to the VLR, it shall not contain a marking for CCBS.

Information element name

Status

Description

SS‑CSI

This IE is described in subclause 8.2.1.

This IE identifies the subscriber as having supplementary service invocation notification services. It contains the Notification Criteria and gsmSCFAddress.

When SS‑CSI is sent to the VLR, it shall not contain a marking for CCBS.

8.4.3 HLR to gsmSCF information flows

8.4.3.1 SS Invocation Notification

This IF is generated by the HLR when it shall notify the gsmSCF of a supplementary service invocation.

8.4.3.1.2 Information Elements

Information element name	Status	Description
Notification Event	M	This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Completion of Calls to Busy Subscriber
IMSI	M	This IE identifies the mobile subscriber who has invoked the supplementary service to be notified.
MSISDN	M	This IE identifies the mobile subscriber who has invoked the supplementary service to be notified.
B-Number	M	This IE indicates the destination address of the CCBS request.
CCBS Request State	M	This IE identifies the current state of the CCBS request. It can be one of: – Request; – Recall; – Active; – Completed; – Suspended; – Frozen; – Deleted.

8.4.4 VLR to MSC information flows

8.4.4.1 Invoke SS result

8.4.4.1.1 Description

This IF is used by the VLR to send SS‑CSI to the MSC. This IF is specified in 3GPP TS 29.002 [34].

8.4.4.1.2 Information Elements

The Invoke SS result contains the following CAMEL specific information element for SS Notifications:

Information element name	Status	Description
SS‑CSI	C	This IE is included when it is available in the VLR and either ECT or MPTY has been successfully invoked and that supplementary service has been marked for notification.

8.4.4.2 Send Info For Incoming Call ack

8.4.4.2.1 Description

This IF is used by the VLR to send SS‑CSI to the MSC. This IF is specified in 3GPP TS 23.018 [12].

8.4.4.2.2 Information Elements

The Send Info For Incoming Call ack contains the following CAMEL specific information elements for SS Notifications:

Information element name	Status	Description
SS‑CSI	S	This IE is included when it is available in the VLR and CD has been successfully invoked and that supplementary service has been marked for notification.