7.2 Registration

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

7.2.1 IMS registration via CS access

7.2.1.1 Overview

If the MSC Server enhanced for ICS implements the Combined CS Access Authentication procedure as specified in Annex G, the UE accessing the network via CS domain shall be authenticated and registered by this procedure, otherwise the following applies.

The UE may register (attach) in the CS domain whenever in CS coverage. The existing mobility management mechanisms are used in the UE and the CS network.

When performing a successful Location Update for the UE, the MSC Server has received the subscriber data from the HSS/HLR. This subscriber data may include an optional flag per VPLMN.

An MSC Server that is enhanced for ICS shall then perform the following:

– If the flag is received and is supported by the MSC Server, then the MSC Server shall analyse the value of the flag as follows:

– If the flag is set to true and optionally if the MSC Server is configured to know that the VPLMN has a suitable roaming agreement with the HPLMN of the UE, the MSC Server shall attempt the IMS registration using the I2 reference point.

– If the flag is set to false, the MSC Server shall not attempt the IMS registration.

– If the flag is not received or is not supported, the MSC Server may perform some pre-screening (e.g. IMSI range analysis) based on operator-policy in order to determine whether or not to attempt IMS registration for this subscriber.

NOTE 1: Exact pre‑screening procedures are operator specific.

NOTE 2: An MSC Server that is not enhanced for ICS will ignore the flag and thus will continue normal CS operation.

If the MSC Server decides not to perform registration in the IMS, the MSC Server falls back to the behaviour of an MSC Server that is not enhanced for ICS.

If the network is in NMO I configuration, the mobility management procedures using Gs interface triggers the MSC Server enhanced for ICS to perform IMS registration.

When attempting initial IMS registration on behalf of the ICS User, the MSC Server shall derive a home IMS domain name using the identity of the subscriber (e.g. IMSI). This domain name identifies the node (e.g. I‑CSCF or IBCF) to which the MSC Server shall send the IMS registration. The MSC Server shall also derive IMS user identities required for the registration from this identity. The MSC Server shall derive these identities in a manner that prevents collisions with other identities automatically derived from the same subscriber identity. See clause 4.6.2 of the present document for more information on the identities used.

The MSC Server then initiates a registration on behalf of the ICS User towards the home IMS indicating support for GRUU and including an InstanceID. If a GRUU is received, the MSC Server shall store it. The MSC Server shall not apply the mechanism for multiple simultaneous registrations.

NOTE 3: IMS authorization of registrations from an MSC Server enhanced for ICS is defined in clause 9.

The MSC Server shall indicate in the registration the media capabilities that it supports (as listed in TS 22.101 [9]).

The routing of the registration messaging is performed by standard IMS routing procedures. The S‑CSCF shall perform 3rd party registration towards the SCC AS. The SCC AS shall obtain from the S‑CSCF the necessary information related to the contact address for performing T‑ADS.

If the S-CSCF receives IMS de-registration from MSC, or receives IMS registration from new MSC while there is a valid IMS registration from old MSC, the S-CSCF releases the existing sessions which includes early session as defined in TS 24.229 [31].

If IMS registration is successful, then subsequent IMS sessions described in clause 4.4.2 shall be supported in IMS using the MSC Server procedures described in this specification.

The success or failure of the IMS registration shall not impact the CS attach status of the UE.

The MSC Server enhanced for ICS shall initiate IMS re-registration as necessary to maintain an active IMS registration during the period of time in which the UE is attached to the CS domain.

NOTE 4: Due to the MSC Server not applying the mechanism for multiple simultaneous registrations, this results in the behaviour of when a UE attaches to a new MSC Server enhanced for ICS and the old MSC Server enhanced for ICS has not deregistered the user, the new registration over-writes the existing one in the S‑CSCF.

After successful initial IMS registration, the MSC Server enhanced for ICS shall subscribe to the registration event package described in TS 23.228 [2] on behalf of the ICS User. The MSC Server shall use the default Public User Identity received during initial IMS registration for subscription to this package. The MSC Server enhanced for ICS shall refresh this subscription as necessary during the period of time in which its IMS registration on behalf of the ICS User is active.

The MSC Server enhanced for ICS shall initiate IMS deregistration on behalf of the ICS User upon receipt of any indication that the UE is no longer considered active at this MSC Server (e.g. Location Cancellation procedure, Purge MS procedure, etc.). In order to ensure that the registration request from the target MSC Server arrives at the S‑CSCF prior to the deregistration request from the source MSC Server, the MSC Server should delay the deregistration procedure, such as by starting a timer. If the S‑CSCF finds an existing binding upon receiving the deregistration request as specified in TS 24.229 [31] and identifies that is a request initiated by the MSC Server enhanced for ICS on behalf of the ICS User, the S‑CSCF shall compare the contact address in the deregistration request with the contact address in the existing binding using the URI comparison rules. If it agrees, the S‑CSCF will remove the existing binding. Otherwise, the de-registration request fails. Per operator policy, the MSC Server enhanced for ICS shall also initiate IMS re-registrations to obtain additional temporary-GRUUs as need.

Upon receipt of a network-initiated deregistration from the IMS, the MSC Server enhanced for ICS shall remove all registration details relating to the Public User Identities contained in the deregistration. Network-initiated deregistration from IMS shall not impact the UE’s CS registration status.

7.2.1.2 Registration using I2 reference point

Figure 7.2.1.2-1 describes how IMS registration is performed by the MSC Server enhanced for ICS upon receiving of a Location Update Request.

Figure 7.2.1.2-1: Initial IMS Registration via CS Access

1. The UE sends a Location Update Request towards the CS network.

NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used instead when the network is in MNO I configuration.

NOTE 2: Combined TA/LA Update procedure (as specified in TS 23.272 [44]) can be used instead when the network supports EMM combined procedures.

2. The MSC Server enhanced for ICS performs standard CS location update, authentication and obtains subscriber data.

3. A Location Area Update Accept is returned to the UE.

NOTE 3: If Combined RA/LA Update Request is used in Step 1, the MSC Server enhanced for ICS does not return Location Area Update Accept to the UE but returns Location Update Accept to SGSN, as specified in TS 23.060 [35].

NOTE 4: If Combined TA/LA Update procedure is used in Step 1, the MSC Server enhanced for ICS does not return Location Area Update Accept to the UE but returns Location Update Accept to MME, as specified in TS 23.272 [44].

4. The MSC Server enhanced for ICS decides to initiate IMS registration for this subscriber. If the subscriber is already registered via this MSC Server enhanced for ICS, no IMS registration is sent.

5. The MSC Server enhanced for ICS derives a domain name from the subscriber’s identity (e.g. IMSI) and discovers the address of the appropriate I‑CSCF/IBCF.

6. The MSC Server enhanced for ICS sends a SIP REGISTER to the IMS with a private and temporary Public User Identity derived from the subscriber’s IMSI as well as an InstanceID. The REGISTER also contains information indicating the capabilities (e.g. media types) supported and characteristics of the MSC Server as a SIP User Agent Client. The I‑CSCF verifies that the incoming REGISTER origins from a trusted MSC Server (in the same way it would check that a normal REGISTER origins from a trusted P‑CSCF).

7. The I‑CSCF initiates standard procedures for S‑CSCF location/allocation.

8. The I‑CSCF forwards the REGISTER to the S‑CSCF.

9. The S‑CSCF identifies the REGISTER as being from the MSC Server. The S‑CSCF skips any further authentication procedures and performs registration procedures with the HSS.

10. The S‑CSCF performs standard service control execution procedures. Filter criteria directs the S‑CSCF to send a REGISTER to the SCC AS.

11. IMS registration procedures are completed.

7.2.1.3 Deregistration using I2 reference point

Figure 7.2.1.3-1 describes how IMS deregistration is performed by an MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving away from an MSC Server enhanced for ICS to an MSC Server not enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered.

Figure 7.2.1.3-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to an MSC Server not enhanced for ICS

1. The UE initiates standard location updating procedures toward the CS network.

2. The CS network performs standard CS location updating and authentication procedures.

3. The HSS initiates location cancellation procedures towards the source MSC Server that is enhanced for ICS.

4. On receipt of the Cancel Location, the source MSC Server should delay the deregistration procedure for a short period of time, e.g. by starting a timer.

NOTE: The delay mentioned in step 4 is used to reduce the signalling at S‑CSCF when UE moves between MSC Servers enhanced for ICS (see clause 7.2.1.4). The delay needs to be long enough to ensure that the deregistration request from the source MSC Server arrives at the S‑CSCF after the registration request from target MSC Server enhanced for ICS.

5. The I‑CSCF initiates standard procedures for S‑CSCF location/allocation.

6. The I‑CSCF forwards the REGISTER to the S‑CSCF.

7. The S‑CSCF identifies the REGISTER as being from an MSC Server enhanced for ICS that is a trusted network node. The S‑CSCF skips any further authentication procedures and performs deregistration procedures with the HSS.

8. The S‑CSCF performs the procedures as described in clause 7.2.1.1. As the contact address in the REGISTER is the same with the contact address in the existing binding, the S‑CSCF performs standard service control execution procedures. Filter criteria directs the S‑CSCF to send a REGISTER to the SCC AS.

9. IMS deregistration procedures are completed.

7.2.1.4 Registration after Deregistration using I2 reference point

Figure 7.2.1.4-1 describes how IMS deregistration is performed by the MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving between two MSC Servers enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered. The registration request from the target MSC Server enhanced for ICS arrives at the S‑CSCF after the deregistration request from the source MSC Server enhanced for ICS.

Figure 7.2.1.4-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to a target MSC Server enhanced for ICS

1. The UE initiates standard location updating procedures towards the CS network.

NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used when the network is in MNO I configuration.

NOTE 2: Combined TA/LA Update procedure (as specified in TS 23.272 [44]) can be used instead when the network supports EMM combined procedures.

2. The CS network performs standard CS location updating and authentication procedures.

3. The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.

4. The source MSC Server enhanced for ICS initiates IMS de-registration as described in clause 7.2.1.3. The S‑CSCF removes the existing binding related to the source MSC Server enhanced for ICS.

5. The target MSC Server that is also enhanced for ICS initiates IMS registration as described in clause 7.2.1.2. The S‑CSCF establishes a new binding related to the target MSC Server enhanced for ICS.

NOTE 3: If step 5 is performed before step 4, the de-registration of the source MSC Server enhanced for ICS does not affect the new registered contact of the target MSC Server enhanced for ICS.

7.2.1.5 Registration before Deregistration using I2 reference point

Figure 7.2.1.5-1 describes how IMS deregistration is performed by the MSC Server enhanced for ICS upon detection of the Location Cancellation procedure. In this scenario, the UE is moving between two MSC Servers enhanced for ICS. Identical IMS deregistration procedures are initiated by the source MSC Server enhanced for ICS upon receiving of any other indication that the UE is no longer considered registered. The registration request from the target MSC Server enhanced for ICS arrives at the S‑CSCF before the deregistration request from the source MSC Server enhanced for ICS.

Figure 7.2.1.5-1: IMS Deregistration via CS Access by source MSC Server enhanced for ICS when moving to a target MSC Server enhanced for ICS

1. The UE initiates standard location updating procedures towards the CS network.

NOTE 1: Combined RA/LA Update Request (as specified in TS 23.060 [35]) can be used when the network is in MNO I configuration.

NOTE 2: Combined TA/LA Update procedure (as specified in TS 23.272 [44]) can be used instead when the network supports EMM combined procedures.

2. The CS network performs standard CS location updating and authentication procedures.

3. The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.

4. The target MSC Server that is also enhanced for ICS initiates IMS registration as described in clause 7.2.1.2. The S‑CSCF updates a existing binding related to the source MSC Server enhanced for ICS.

5. The source MSC Server that is enhanced for ICS initiates IMS deregistration for this subscriber.

6. The I‑CSCF initiates standard procedures for S‑CSCF location/allocation.

7. The I‑CSCF forwards the REGISTER to the S‑CSCF.

8. The S‑CSCF identifies the REGISTER as being from an MSC Server enhanced for ICS that is a trusted network node. The S‑CSCF skips any further authentication procedures and performs deregistration procedures as described in clause 7.2.1.1. As the contact address in the REGISTER differs from the contact address in the existing binding related to the target MSC Server, the S‑CSCF returns an error response to the source MSC Server enhanced for ICS.

7.2.2 IMS Registration via IP-CAN

Whenever the ICS UE acquires IP connectivity via an IP-CAN, the UE shall register in the IMS if not already registered in IMS. Registration with IMS is in accordance with the procedure as defined in TS 23.228 [2].

3rd-party registration shall be performed by the S‑CSCF via the ISC interface towards the SCC AS. This supports ADS functionality in the SCC AS.

1. The UE registers in the IMS as described in clause 5.2.2.3 of TS 23.228 [2] indicating its abilities to use ICS.

NOTE: Access networks capabilities could be taken into account when sending any indications.

2. The S‑CSCF informs the SCC AS about the registration, using the procedures defined in clause 6.3 of TS 23.218 [7].

IMS registration via IP-CAN is performed independently of the UE’s CS state.

Information regarding home network support of ICS shall be configured in the ICS UE, e.g. via OMA DM [24].