Content for TS 23.292 Word version: 17.0.0

1… 4… 5… 7… 7.2… 7.3… 7.3.2.2… 7.3.2.2.4… 7.4… 7.4.2.2… 7.4.2.2.3… 7.4.2.2.7… 7.5… 7.6… 7.6.1.2.2.6… 7.6.1.2.3… 7.6.1.2.3.5… 7.6.1.2.3.6… 7.6.2… 7.6.2.7 7.6.2.8… 7.6.2.11… 7.6.3… 7.7… 7.7.2… 7.9… 7.9.2… 7.9.2.4 7.9.2.5 8… A… G… H… H.5… H.5.3…

F.1 General F.2 Implementation options for call diversion from CS to the IMS F.3 Implementation options for prevention of circular looping of CS Terminations
...

A Service Consistency p. 116

IMS Centralized Services (ICS) provides communication services such that all services, and service control, are based on IMS mechanisms and enablers. It enables IMS services when using CS access for the media bearer.

With ICS, the user services are provided by IMS. User sessions are controlled in IMS via PS or CS access. When using CS access network, or when using PS access networks which do not support full duplex speech component of an IMS service, the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions.

Functionality is needed to provide IMS Centralized Services to devices using a circuit switched access network for media transport. Two fundamentally different approaches are enabled in this specification. One approach supports legacy UEs by placing new functional elements in the MSC Server. Another approach provides new functionality in the UE. The following Figure depicts the provision of IMS Centralized Services for these approaches from the user's perspective. This Figure is intended to be illustrative in nature, and is not intended to depict a complete or definitive identification of the various IMS Centralized Services that may be provided using different access networks or solutions.

Copy of original 3GPP image for 3GPP TS 23.292, Fig. A-1: IMS Centralized Services

Figure A-1: IMS Centralized Services
(⇒ copy of original 3GPP image)

B ICS functions in different deployment scenarios p. 117

The following tables provides guidance on which of the functions and functionalities are needed in the different deployment scenarios.

Scenario 1:

An operator who only supports UEs that have ICS functionality for their ICS Users:

	MSC Server with ICS enhancements	ICS UE	Transparent control channel		SCC AS
	MSC Server with ICS enhancements	ICS UE	I1	Gm	CAA	IUA	T-ADS
Required	No	Yes	As driven by operator policy and VPLMN support.	As driven by operator policy and VPLMN support.	Yes, only if I1 is supported	Yes	Yes

ICS Users using a non-ICS UE (e.g. after SIM swap) will not make use of the transparent control channel; non ICS UE originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008) for call origination.

Scenario 2:

An operator who only supports non ICS UEs for their ICS Users:

	MSC Server with ICS enhancements	ICS UE	Transparent control channel		SCC AS
	MSC Server with ICS enhancements	ICS UE	I1	Gm	CAA	IUA	T-ADS
Required	Yes	No	No	No	No	Conditional*	Yes

* Required if the operator supports IN (e.g. CAMEL) redirection of CS originated calls.

Scenario 3:

An operator who supports UE's for their ICS Users that do, and do not, have ICS functionality (to different subscribers and the same subscribers) ensuring the coexistence of UEs that have and do not have ICS functionality:

	MSC Server with ICS enhancements	ICS UE	Transparent control channel		SCC AS
	MSC Server with ICS enhancements	ICS UE	I1	Gm	CAA	IUA	T-ADS
Required	Yes	Yes	As driven by operator policy and VPLMN support.	As driven by operator policy and VPLMN support.	Yes, if I1 is supported	Yes	Yes

Scenario 4:

Inbound roaming - operator supports ICS

Inbound roaming subscribers on an operator's network that supports either the same or different ICS functionality that the inbound roaming subscriber is using, ensuring the coexistence of UEs that have and do not have ICS functionality.

Sub case 4.1:

Subscriber from operator supporting scenario 1 roams into network of scenario 1

Same functions and functionalities in roaming in-network as in scenario 1. No additional functions or functionalities.

Sub case 4.2:

Subscriber from operator supporting scenario 2 roams into network of scenario 2

Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities.

Sub case 4.3:

Subscriber from operator supporting scenario 1 roams into network of scenario 2

Same functions and functionalities in roaming in-network as in scenario 2. No additional functions or functionalities. Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control channel between ICS UE and SCC AS in the home network.

Sub case 4.4:

Subscriber from operator supporting scenario 2 roams into network of scenario 1

Same functions and functionalities in roaming in-network as in scenario 1: No additional functions or functionalities. Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008) for call origination.

Scenario 5:

Inbound roaming - operator does not support ICS

Inbound roaming subscribers on an operator's network that does not support ICS.

Sub case 5.1:

Subscriber from operator supporting scenario 1 roams into an operator's network that does not support ICS.

Roaming agreement, operator policy and access network restrictions decide on the use of the transparent control channel between ICS UE and SCC AS in the home network.

Sub case 5.2:

Subscriber from operator supporting scenario 2 roams into an operator's network that does not support ICS.

Roaming agreement and operator policy decide on the fallback solution, i.e., whether or not originated calls are routed to the home IMS using IN (e.g. CAMEL) signalling in conjunction with CS signalling (e.g. TS 24.008) for call origination.

C Communication Deflection support when call has been delivered using CS call control p. 119

When a call has been delivered to a non ICS UE using CS call control, Communication Deflection service can be centralized and executed in IMS by using IN (e.g. O-CSI CAMEL) if it is supported by the network and user subscription.

D Conditional Call Forwarding support when call has been delivered using CS call control p. 120

When a call has been delivered to an UE using CS call control, conditional call forwarding services can be centralized and executed in IMS by one of (or a combination of) the following implementation options.

Solution 1: Default PSIs

In this solution, Conditional CF is configured in IMS with default service configuration in the CS domain. The Conditional CF services are configured in the HLR. The different forwarded number can be set in HLR to indicate the type of CF. The VMSC redirects the call to IMS for appropriate handling of the service in IMS.

Solution 2: MAP suppression-of-announcements

In this solution, Conditional CF is configured and provisioned in IMS domain exclusively, according to IMS Centralized Service principle. It provides means to suppress the announcement in CS domain at the MSC for the conditional call forwarding services. MGCF provides the appropriate responses to TAS on behalf of the ICS user in CS domain. The MGCF can use the ICS indication if available to map cause codes received over the CS leg to appropriate IMS error codes.

For support of CFNRy, the TAS starts a supervisory no-reply timer on receipt of Alerting from the called party. If the timer expires without receipt of the Connect from the called party, the TAS invokes the CFNRy service.

Solution 3: IN

In this solution, Conditional CF is configured in IMS with default service configuration in the CS domain so that the VMSC invokes the CF service in the CS domain upon detection of CF triggers. IN (e.g. O-CSI CAMEL service) is configured in the HLR to redirect service control to IMS for processing of CF.

E Using MRF for media process p. 121

After the session between ICS UE and other party ( Party B) is hold, if the SCC AS receives the new session request, it can use MRF for media process. The following three options give details on how to implement it.

Solution 1: using MRFP by SCC AS for held party

In this solution, if the SCC AS receives the new session request after the session between ICS UE and other party (Party B) is hold, it changes the MGW media path from Party B to the third party (Party C), and connects Party B to MRF for playing announcement.

Solution 2: using MRFP by SCC AS for active and Held party

In this solution, if the SCC AS receives the new session request after the session between ICS UE and other party (Party B) is hold, it changes the MGW media path to MRF, and then connects Party B to MRF for playing announcement and connects the third party (Party C) to MRF to communicate with ICS UE.

Solution 3: using MRFP by TAS for Held call

In this solution, TAS is always kept in ICS UE A's remote leg. After the TAS receives the Hold request from the ICS UE via the SCC AS, it performs communication Hold procedure as described in TS 24.147. The MRF is connected to Party B for playing announcement.

F Call diversion from CS to IMS |R10| p. 122

F.1 General p. 122

An incoming call for a subscriber with a service provided by the IMS (e.g. ICS, SC, SR-VCC) can be received either through the CS domain or IMS. For such a subscriber, certain calls that are received through the CS domain need to be routed to the IMS for anchoring at the SCC AS, prior to the onward routing of the call to the subscriber. Solutions for this are discussed in clause F.2.

When an incoming CS call is anchored at the SCC AS using certain implementation options described in clause F.2, then as a result of domain selection, the call can be routed back to the CS domain to determine the CSRN for CS termination. In this case, the call can be treated as a new incoming call from the CS network, and then be re-routed to the IMS for anchoring again, thus creating a circular loop. Solutions for this are discussed in clause F.3.

F.2 Implementation options for call diversion from CS to the IMS p. 122

Several techniques available in the current CS networks can be used to implement the call diversion from CS to IMS, as detailed below:

Use of CAMEL for call diversion to IMS

This option applies to configurations requiring handling of incoming calls at the GMSC function. Upon receipt of an incoming call, the GMSC queries the HSS for routing information via the Send Routing Information (SRI) query. The user profile in the HSS is configured to return T-CSI including a gsmSCF address to the GMSC in response to the SRI query. When handling calls for a subscriber with a service provided by the IMS, the subsequent processing at the gsmSCF and the GMSC results in routing of the call to the IMS using the IMRN. The call is routed to the SCC AS according to standard IMS routing procedures. In order to determine the necessary information to complete the call, the SCC AS uses the IMRN or the ISUP information mapped to SIP headers.

HSS directed call diversion to IMS

This option also applies to configurations requiring handling of incoming calls at the GMSC function. Upon receipt of an incoming call, the GMSC queries the HSS for routing information using the MAP Send Routing Information (SRI) procedure (as defined in TS 29.002). Based on a non-standardized mechanism, the user profile in the HSS is configured to return an IP Multimedia Routing Number (IMRN) to the GMSC in response to the SRI query, when the call is directed to a subscriber with a service provided by the IMS. The subsequent processing at the GMSC results in routing of the call to IMS using the IMRN. Two methods can then be used to ensure correlation between the IMRN and the original called party.

Cooperative allocation/deallocation: In this method, the IMS is made aware of the assigned IMRN and when a call is received for that number, the original number is retrieved. This method is similar to the Provide Roaming Number procedure in MAP (see TS 29.002).
Algorithmic: In this method, a known algorithm is used to derive the IMRN at the CS, and to deduce the original called number from the IMRN at the IMS. One method of performing such an algorithm could be use of a prefix. In such a case, care is required in the network configuration to avoid call looping for the case when the call is subsequently routed from the IMS to the CS domain for call termination (see clause F.3 for possible solutions to prevent call looping).

Static diversion from GMSC with dedicated trunk groups

This option also applies to configurations requiring handling of incoming calls at the GMSC function. Dedicated trunk groups can be used at the GMSC to divert CS terminations to the MGCF.

Static diversion using Local Number Portability

This option can be used for routing of calls originating in PSTN networks to IMS. A Local Number Portability database dip can be used to reroute incoming calls to a subscriber with a service provided by the IMS with calls to the MGCF.

Direct routing to IMS

Translations can be set up in the PSTN network to route the incoming call to a subscriber with a service provided by the IMS to the MGCF. This way the normal IMS routing technique specified in TS 23.228 can be used.

F.3 Implementation options for prevention of circular looping of CS Terminations p. 123

Several implementation techniques can be used to avoid circular looping, as detailed below:

Use of SCC AS for retrieving the CSRN

When the SCC AS decides that the call is to be terminated in the CS domain, the SCC AS retrieves the CSRN from the MSC/MSC-Server via the HSS using the following method:

MAP SRI Query: This option makes use of a MAP Interface between the SCC AS and the HSS to request allocation of a CSRN from the HSS for routing of the call to the MSC/MSC-Server currently serving the subscriber.
Sh UDR Query: This option makes use of the Sh interface between the SCC AS and the HSS. The SCC AS sends a Sh UDR query to the HSS to request allocation of a CSRN for routing of the call to the MSC/MSC-Server currently serving the subscriber.

Use of a specific CSRN to indicate the anchored call

When the SCC AS decides that the call is to be terminated in the CS domain, the SCC AS allocates a specific CSRN. The specific CSRN can be an MSISDN with added prefix digits. The SCC AS uses the specific CSRN to route the call to the CS network. The following options are available to resolve the MSISDN of original called party from the CSRN.

MGCF resolution: In this option, the SCC AS forwards the call to the MGCF (which has a GMSC function). The specific CSRN is used by the MGCF to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The MGCF resolves the MSISDN from the CSRN and invokes GMSC functionality integrated in the MGCF for handling the CS call terminating procedure. In particular, the MGCF/GMSC includes the "Suppress T-CSI" parameter in the MAP SRI sent to the HSS.
GMSC resolution: In this option, the SCC AS forwards the call to the MGCF, which then forwards the call on to GSMC. The specific CSRN is used by the GSMC to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The GMSC resolves the MSISDN from the CSRN and invokes the CS call terminating procedure. In particular, the GMSC includes the "Suppress T CSI" parameter in the MAP SRI sent to the HSS.
HSS resolution: In this option, the SCC AS forwards the call to the GMSC. The GMSC treats the call as a normal terminating call and sends a MAP SRI request to the HSS for the specific CSRN. The specific CSRN is used by the HSS to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The HSS resolves the MSISDN from the CSRN and uses CS call terminating procedures to obtain routing information from the MSC/MSC-Server.

Use of a dynamically allocated CSRN to route via the GMSC

This option uses a dynamically allocated CSRN to divert the call to the appropriate GMSC as described below:

The SCC AS allocates a CSRN that maps to an appropriate GMSC. Standard CS termination procedures are then executed at the GMSC.
The GMSC is configured with N-CSI and criteria corresponding to the CSRN. This causes the GMSC to issue an InitialDP containing the CSRN to the gsmSCF.
The gsmSCF performs a function on the CSRN to obtain the MSISDN of the called party number and the MSISDN is returned to the GMSC in a CONNECT operation together with the CSRN as a Re-direction ID.
The GMSC continues the normal CS call termination procedure by issuing an SRI to the HSS using the MSISDN, which causes T-CSI to be returned back to the GMSC.
The GMSC issues another InitialDP containing both MSISDN and CSRN to the gsmSCF. The gsmSCF recognises that it has been triggered for the second time (due to the presence of the CSRN) and therefore returns a CONTINUE for the MSISDN, thus avoiding a circular loop.
The GMSC sends a MAP SRI query to the HSS with the "Suppress T CSI" parameter, thus allowing the HSS to obtain the MSRN through standard call terminating procedures.