9 Security Considerations

23.2923GPPIP Multimedia Subsystem (IMS) centralized servicesRelease 17Stage 2TS

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

9.1 Access security

ICS re-uses the CS domain security described in the detailed access specific specification.

Access using MSC Server enhanced for ICS is secured by the combination of the CS access security and the IMS Network Domain Security. The MSC Server enhanced for ICS also performs the trusted node authentication procedures according to TS 33.203 [32].

9.2 Network Domain Security

Network domain security with the MSC server enhanced for ICS shall be provided by NDS/IP according to TS 33.210 [33] for the I2 reference point.

NOTE: If the control plane interfaces are trusted (e.g. physically protected), there is no need to use protection according to TS 33.210 [33].

Annex A (informative):
Service Consistency

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.

Figure A-1: IMS Centralized Services

Annex B (informative):
ICS functions in different deployment scenarios

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	ICS UE	Transparent control channel		SCC AS
	enhancements		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 [6]) for call origination.

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

	MSC Server with ICS	ICS UE	Transparent control channel		SCC AS
	enhancements		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	ICS UE	Transparent control channel		SCC AS
	enhancements		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 [6]) 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 [6]) for call origination.

Annex C (informative):
Communication Deflection support when call has been delivered using CS call control

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.

Annex D (informative):
Conditional Call Forwarding support when call has been delivered using CS call control

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.

Annex E (informative):
Using MRF for media process

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 [21]. The MRF is connected to Party B for playing announcement.

Annex F (informative):
Call diversion from CS to IMS