4 Overview of IP Multimedia (IM) Core Network (CN) subsystem centralized services (ICS)

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

4.1 General

ICS allows for the delivery of consistent IMS services to the user regardless of the attached access type (e.g. CS domain access or IP-CAN). ICS provides communication services such that all services, and service control, are based on IM CN subsystem mechanisms and enablers. This includes enabling IM CN subsystem services when using CS access for the media bearer.

When using a CS access network only, or when using a PS access networks that does not support the full duplex speech component of an IM CN subsystem service in conjunction with a CS access network, the CS core network is utilized to establish a circuit switch access according to e.g. 3GPP TS 24.008 [7] or 3GPP2 C.S0001-D [37] to provide bearers for voice, data, and fax media of IM CN subsystem sessions.

If the PS access network does support the full duplex speech component of an IMS service then existing IM CN subsystem session procedures are used as specified in 3GPP TS 24.229 [11].

ICS provides mechanisms to support the use of CS media bearer for IM CN subsystem sessions. With ICS, IM CN subsystem sessions using CS media are treated as standard IM CN subsystem sessions for the purpose of service control.

Sessions originated by ICS subscribers in both the IM CN subsystem and in the CS domain are subject to anchoring in the IM CN subsystem. Similarly, voice calls terminated to ICS subscribers are anchored in the IM CN subsystem. When anchoring occurs, such sessions have a path to the SCC AS from either the CS access domain or the IM CN subsystem so that the SCC AS can be used to provide service centralization.

In order for the above to occur, the following procedures are supplied within this specification:

– procedures for call origination are specified in Clause 7;

– procedures for call modification initiated from the ICS UE are specified in Clause 8;

– procedures for call modification initiated towards an ICS UE are specified in Clause 9;

– procedures for call termination are specified in Clause 10;

– procedures for session release are specified in Clause 11; and

– procedures for supplementary service invocation for ICS are specified in Clause 12.

4.2 Underlying network capabilities

ICS assumes the use of a number of underlying network capabilities:

1) provision by the home network operator of an ICS specific AS on the IM CN subsystem, as specified in 3GPP TS 24.229 [11];

2) signalling within the CS domain (both within the home network and between the home network and any visited network) supported using either ISUP (as defined in ITU-T Recommendations Q.761 to Q.764 [28]) or BICC (as defined in ITU-T Recommendations Q.1902.1 to Q.1902.6 [29]);

3) provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [21]) at the MSC Server;

4) if the MSC Server is not enhanced for ICS, interworking between the CS domain and the IM CN subsystem is provided by an MGCF in accordance with 3GPP TS 29.163 [22]. In addition, as an operator option, a support of IMS Centralized Services (ICS) may be signalled to the MGCF in a SIP initial request for dialog or a response associated with the SIP initial request; and

5) capability of the IP-CAN to support full duplex speech component, for example as used in IMS multimedia telephony.

4.3 URI and address assignments

In order to support ICS to a subscriber the following URI and address assignments are assumed:

a) the ICS UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one to many public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. The subscriber’s IM CN subsystem profile will need to be provisioned with a tel URI, either as the default public user identity or associated with it, equivalent to a DN (e.g. MSISDN) in the subscriber’s CS profile associated with speech/audio (e.g. TS11).

b) void

c) a PSI DN is assigned that can reach an ICS application that can support the ICS capabilities for that ICS UE. The PSI DNs can be dynamically allocated at the time that the call is rerouted to the IM CN subsystem for ICS purposes. The PSI DN is used specifically in the case of Gm or I1 service control for the purpose of CS bearer setup and does not apply to other procedures. The IM CN subsystem is configured to treat the PSI DN as a PSI;

d) a non ICS UEs which are not registered in the IM CN subsystem might still be attached to the CS network at an MSC. In this scenario, a CSRN is assigned for routing the call to the CS domain;

e) an MSC Server enhanced for ICS shall use a private user identity and public user identity specifically reserved for IM CN subsystem registrations from an MSC Server. This is to avoid conflicts in IM CN subsystem registration by a UE and an MSC Server registering on behalf of the same subscriber. The identities reserved for ICS identities are defined in 3GPP TS 23.003 [4]; and an MSC Server shall use only those public user identities representing E.164 numbers from the subscriber’s IM CN subsystem profile to originate and terminate calls;

f) an MSC Server enhanced for ICS is provisioned with a string that identifies the visited network at the home network. The string needs to be different than the value provisioned to a P-CSCF, as specified in 3GPP TS 24.229 [11], in order to distinguish between a P-CSCF and an MSC Server enhanced for ICS; and

g) an IMRN is assigned that can reach an ICS application that can support the ICS capabilities for that UE. IMRNs can be dynamically allocated. The IM CN subsystem is configured to treat the IMRN as a PSI.

h) an MSC Server enhanced for ICS shall provide a home network domain name from the subscriber’s IMSI as defined in 3GPP TS 23.003 [4].

4.4 Guidelines for use of media feature tags

NOTE: When the values appropriate for use with a media feature tag are of string type, then when included in Contact, Accept-Contact or Reject-Contact header fields, the value of the media feature tag is preceded by "<" and followed by ">" according to IETF RFC 3840 [34] and IETF RFC 3841 [35A].

4.5 Networks where IMSVoPS is not homogeneously supported

In order to support sessions with IMS PS voice in a network where IMSVoPS is not homogeneously supported, it is assumed that filter criteria causes all sessions with IMS PS voice to be anchored in an SCC AS. Configuration of QoS assignment for IMS PS voice of the sessions need to be aligned with the initial filter criteria and SCC AS determination that a SIP INVITE request establishes a session with IMS PS voice.