Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.292  Word version:  18.0.0

Top   Top   Up   Prev   Next
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… 
7.2 Registration  7.2.1 IMS registration via CS access  7.2.1.1 Overview  7.2.1.2 Registration using I2 reference point  7.2.1.3 Deregistration using I2 reference point  7.2.1.4 Registration after Deregistration using I2 reference point  7.2.1.5 Registration before Deregistration using I2 reference point  7.2.2 IMS Registration via IP-CAN 
...

 

7.2  Registration  p. 23

7.2.1  IMS registration via CS access  p. 23

7.2.1.1  Overview  p. 23

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.
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.
The MSC Server shall indicate in the registration the media capabilities that it supports (as listed in TS 22.101).
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.
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.
After successful initial IMS registration, the MSC Server enhanced for ICS shall subscribe to the registration event package described in TS 23.228 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 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.
Up

7.2.1.2  Registration using I2 reference point  p. 25

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.
Copy of original 3GPP image for 3GPP TS 23.292, Fig. 7.2.1.2-1: Initial IMS Registration via CS Access
Figure 7.2.1.2-1: Initial IMS Registration via CS Access
(⇒ copy of original 3GPP image)
Up
Step 1.
The UE sends a Location Update Request towards the CS network.
Step 2.
The MSC Server enhanced for ICS performs standard CS location update, authentication and obtains subscriber data.
Step 3.
A Location Area Update Accept is returned to the UE.
Step 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.
Step 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.
Step 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).
Step 7.
The I-CSCF initiates standard procedures for S-CSCF location/allocation.
Step 8.
The I-CSCF forwards the REGISTER to the S-CSCF.
Step 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.
Step 10.
The S-CSCF performs standard service control execution procedures. Filter criteria directs the S-CSCF to send a REGISTER to the SCC AS.
Step 11.
IMS registration procedures are completed.
Up

7.2.1.3  Deregistration using I2 reference point  p. 26

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.
Copy of original 3GPP image for 3GPP TS 23.292, Fig. 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
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
(⇒ copy of original 3GPP image)
Up
Step 1.
The UE initiates standard location updating procedures toward the CS network.
Step 2.
The CS network performs standard CS location updating and authentication procedures.
Step 3.
The HSS initiates location cancellation procedures towards the source MSC Server that is enhanced for ICS.
Step 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.
Step 5.
The I-CSCF initiates standard procedures for S-CSCF location/allocation.
Step 6.
The I-CSCF forwards the REGISTER to the S-CSCF.
Step 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.
Step 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.
Step 9.
IMS deregistration procedures are completed.
Up

7.2.1.4  Registration after Deregistration using I2 reference point  p. 27

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.
Copy of original 3GPP image for 3GPP TS 23.292, Fig. 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
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
(⇒ copy of original 3GPP image)
Up
Step 1.
The UE initiates standard location updating procedures towards the CS network.
Step 2.
The CS network performs standard CS location updating and authentication procedures.
Step 3.
The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.
Step 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.
Step 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.
Up

7.2.1.5  Registration before Deregistration using I2 reference point  p. 28

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.
Copy of original 3GPP image for 3GPP TS 23.292, Fig. 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
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
(⇒ copy of original 3GPP image)
Up
Step 1.
The UE initiates standard location updating procedures towards the CS network.
Step 2.
The CS network performs standard CS location updating and authentication procedures.
Step 3.
The HSS initiates location cancellation procedures towards the source MSC Server enhanced for ICS.
Step 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.
Step 5.
The source MSC Server that is enhanced for ICS initiates IMS deregistration for this subscriber.
Step 6.
The I-CSCF initiates standard procedures for S-CSCF location/allocation.
Step 7.
The I-CSCF forwards the REGISTER to the S-CSCF.
Step 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.
Up

7.2.2  IMS Registration via IP-CAN  p. 29

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.
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 indicating its abilities to use ICS.
  2. The S-CSCF informs the SCC AS about the registration, using the procedures defined in clause 6.3 of TS 23.218.
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].
Up

Up   Top   ToC