6 Roles for registration in the IM CN subsystem

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

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

6.1 Introduction

This clause specifies procedures that are related to registration in the IM CN subsystem that are required for support of ICS. Both when the ICS UE generates the registration and when the MSC Server enhanced for ICS generates the registration is covered.

Subclause A.3 gives examples of signalling flows for registration.

6.2 ICS UE

In the present document, "ICS is enabled for the UE" refers to all of the following conditions:

– the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled; and

– the ability of simultaneous use of a CS bearer and use of PS for the service control signalling path.

Prior to performing IMS registration the ICS UE shall check that the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [43]) is set to enabled for this ICS UE; otherwise ICS is disabled for this ICS UE and the ICS UE shall perform as in 3GPP TS 24.229 [11] and in 3GPP TS 24.008 [7].

If the ICS UE has an IMEI, prior to performing registration, the ICS UE shall generate an instance id based on its IMEI as defined in 3GPP TS 23.003 [4].

If ICS is enabled for the UE then the ICS UE registers to IM CN subsystem as specified in 3GPP TS 24.229 [11] and includes its capabilities in the Contact header field. The ICS UE shall include in the Contact header field:

a) a g.3gpp.ics media feature tag set to "principal" as specified in annex B.2;

b) a g.3gpp.accesstype media feature tag set to one of the following text strings based on the access network technology being used by the UE to register, as follows:

– "wlan": the UE is using WLAN access technology;

– "cellular": the UE is using cellular access technology;

– "docsis": the UE is using DOCSIS access technology;

– "dsl": the UE is using DSL access technology;

– "ethernet": the UE is using Ethernet access technology;

Additionally to ensure that the text string is unique for that registration flow the UE shall append a unique numerical single digit value for each registration flow to the text string value above (e.g "wlan1"); and

c) a sip.instance media feature tag containing the instance ID;

6.3 MSC Server enhanced for ICS

6.3.1 General

Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall generate

– a private user identity;

– an instance id;

– a temporary public user identity; and

– a home network domain name to address the REGISTER request to;

in accordance with the procedures as described in 3GPP TS 23.003 [4].

NOTE: The condition when the MSC Server enhanced for ICS initiates registration on behalf of a UE is described in 3GPP TS 29.292 [24].

Prior to performing registration on behalf of a UE, the MSC Server enhanced for ICS shall obtain the IMEI of the UE using procedures as defined in 3GPP TS 24.008 [7]. The IMEI shall be used to create the instance id as defined in 3GPP TS 23.003 [4].

6.3.2 Initial registration

On sending a REGISTER request, the MSC Server enhanced for ICS shall:

1) set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER request;

2) set the From header field to the SIP URI that contains the temporary public user identity to be registered;

3) set the To header field to the SIP URI that contains the temporary public user identity to be registered;

4) populate an Authorization header field, with:

– the username directive, set to the value of the private user identity;

– the realm directive, set to the domain name of the home network;

– the integrity-protected directive, set to "auth-done";

– the uri directive, set to the SIP URI of the domain name of the home network;

– the nonce directive, set to an empty value; and

– the response directive, set to an empty value;

5) set the Contact header field to include the SIP URI containing the IP address or FQDN of the MSC Server enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a "+sip.instance" header field parameter containing the instance ID. The MSC Server enhanced for ICS shall include a

a) g.3gpp.icsi-ref media feature tag as specified in 3GPP TS 24.229 [11] the value for the IMS Multimedia Telephony Communication Service as specified in 3GPP TS 24.173 [9]; and

b) g.3gpp.ics media feature tag set to server as specified in subclause annex B.

6) set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent-by field;

7) a registration expiration interval value of 600 000 seconds as the value desired for the duration of the registration;

NOTE 1: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network policy. Registration attempts with a registration period of less than a predefined minimum value defined in the registrar will be rejected with a 423 (Interval Too Brief) response.

8) populate the Supported header field with the option tag "gruu";

9) populate the Require header field with the option tag "path";

10) populate the Path header field with:

– a SIP URI identifying the MSC Server enhanced for ICS;

– an indication that requests routed in this direction of the path (i.e. from the S-CSCF towards the MSC Server enhanced for ICS) are expected to be treated as for the terminating case;

NOTE 2: This indication can e.g. be in a parameter in the URI, a character string in the user part of the URI or be a port number in the URI.

– if the MSC server supports indicating the traffic leg associated with a URI as specified in IETF RFC 7549 [50], the user is roaming and if required by local policy, append an "iotl" SIP URI parameter with a value set to "homeB-visitedB" to the SIP URI in the Path header field;

11) populate the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [18] and a type 1 "orig-ioi" header field parameter. The MSC Server enhanced for ICS shall set the type 1 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The MSC Server enhanced for ICS shall not include the type 1 "term-ioi" header field parameter;

12) populate the P-Visited-Network-ID header field with the value of a pre-provisioned string that identifies the network of the MSC server at the home network as specified in subclause 4.3;

13) include a P-Access-Network-Info header field as specified in 3GPP TS 24.229 [11] with the latest known access-type or access-class. The P-Access-Network-Info header field shall contain:

a) an access-type field set to "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD",, "3GPP-E-UTRAN-FDD", "3GPP-E-UTRAN-TDD" or an access-class field set to"3GPP-GERAN", "3GPP-UTRAN or "3GPP-E-UTRAN";

NOTE 2: The SC UE is registered with an E-UTRAN access-type or access-class when performing combined attached to LTE. If CSFB occurs, the access-type or access-class in SIP messages establishing the call will be changed to the UTRAN or the GERAN access-type or access-class. No re-registration is required when CSFB occurs. However, if it is time for re-registration (see subclause 6.3.5) the MSC server uses the GERAN or UTRAN access-type or access-class if the UE has not yet returned to LTE.

b) if available, a "cgi-3gpp", "utran-sai-3gpp" or an "utran-cell-id-3gpp" parameter;

c) if available a "local-time-zone" parameter;

d) if supported, a "daylight-saving-time" parameter; and

e) a "network-provided" parameter; and

14) forward the request as specified in subclause 6.3.3. If the MSC Server enhanced for ICS fails to forward the REGISTER request, the MSC Server enhanced for ICS shall abort the initial IMS registration attempt.

The MSC server enhanced for ICS shall not include the "reg-id" header field parameter in the Contact header field and the "outbound" option-tag in a Supported header field the in REGISTER request.

On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall:

1) store the expiration time of the registration for the public user identities found in the To header field value;

2) store the list of service route values contained in the Service-Route header fields preserving the order and bind the list to the contact address, in order to build a proper preloaded Route header field value for new dialogs and standalone transactions when using this contact address. The MSC Server enhanced for ICS shall store this list during the entire registration period of the respective public user identity;

3) void;

4) store as the default public user identity the first URI in the list of URIs present in the P-Associated-URI header field;

5) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header field;

6) find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" parameter or a "temp-gruu" parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity that was registered;

7) store the values received in the P-Charging-Function-Addresses header field;

8) if a "term-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "term- ioi" header field parameter; and

NOTE 3: Any received "term-ioi" header field parameter will contain a type 1 IOI. The type 1 IOI identifies the home network of the registered user.

9) if a "transit-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "transit-ioi" header field parameter.

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall:

– send another REGISTER request populating the registration expiration interval value with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response to a REGISTER request, the MSC server enhanced for ICS shall perform the procedures for initial registration as described in this subclause.

On receiving a 3xx response or a 480 (Temporarily Unavailable) response or a 503 (Service Unavailable) response response to a REGISTER request, the MSC server enhanced for ICS shall:

1) select a different exit or entry point as described in subclause 6.3.3; and

2) perform the procedures for initial registration as described in this subclause.

When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS shall:

1) select a different exit or entry point as described in subclause 6.3.3; and

2) perform the procedures for initial registration as described in this subclause.

After an unsuccessful initial registration attempt, if the Retry-After header field was present in the received 4xx, 5xx or 6xx response to the REGISTER request, the MSC server enhanced for ICS shall not automatically attempt any further initial registration for an implementation dependant time of at least the amount of time indicated in the received Retry-After header field.

NOTE 4: In all signalling procedures, the MSC server is assuming trusted node authentication (see 3GPP TS 24.229 [11], subclause 4.2B.1.

After a first unsuccessful initial registration attempt, if the Retry-After header field was not present and the initial registration was not performed as a consequence of a failed reregistration, the MSC server shall not wait more than 5 minutes before attempting a new registration.

After a maximum of 2 consecutive unsuccessful initial registration attempts, the MSC server enhanced for ICS shall implement the mechanism defined in subclause 4.5 of IETF RFC 5626 [49] for new registration attempts. The MSC server enhanced for ICS shall use the values of the parameters "max-time" and "base-time (if all failed)", of the algorithm defined in subclause 4.5 of IETF RFC 5626 [49]. If no values of the parameters "max-time" and "base-time (if all failed)" have been configured by operator policy, the default values defined in in subclause 4.5 of IETF RFC 5626 [49] shall be used.

After an unsuccessful initial registration attempt, the MSC server can fall back to the procedures for non ICS UE attached to a legacy MSC for call establishment as described in 3GPP TS 23.292 [6], until a successful initial registration attempt is completed.

6.3.3 Sending the REGISTER request

The MSC Server enhanced for ICS shall send the REGISTER request as follows:

1) if the MSC Server enhanced for ICS is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, the MSC Server enhanced for ICS shall send the REGISTER request to an IBCF in the visited network.

NOTE 1: The list of exit points can be either provisioned in the MSC Server enhanced for ICS or obtained as specified in IETF RFC 3263 [30].

NOTE 2: If the MSC Server enhanced for ICS sends the request to an IBCF in the visited network, the IBCF can determine the entry point of the home network, using the same mechanisms as described in NOTE 1 above. In that case the MSC Server enhanced for ICS does not need to determine the entry point of the home network.

2) determine the entry point of the home network and send the request to that entry point.

NOTE 3: The list of entry points can be either provisioned in the MSC Server enhanced for or obtained as specified in IETF RFC 3263 [30].

If the MSC Server enhanced for ICS fails to send the REGISTER request to any exit or entry point, the MSC Server enhanced for ICS shall abort the registration attempt.

6.3.4 Subscription to the registration-state event package

Upon receipt of a SIP 200 (OK) response to the initial registration, the MSC Server enhanced for ICS shall generate a SIP SUBSCRIBE request for the event package in accordance with IETF RFC 3680 [33], using the updated procedures for the subscribe and notify in IETF RFC 6665 [32], with the following elements:

– a Request-URI set to a SIP URI that contains the default public user identity received in the SIP 200 (OK) response to the SIP REGISTER request;

– a From header field set to a SIP URI that contains the default public user identity received in the SIP 200 (OK) response to the SIP REGISTER request;

– a To header field set to a SIP URI that contains the default public user identity received in the SIP 200 (OK) response to the SIP REGISTER request;

– a Route header field set to values received in the Service-Route header field saved from the SIP 200 (OK) response to the last registration.

1) If the MSC Server enhanced for ICS is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;

2) If the MSC Server enhanced for ICS is located in the visited network and the MSC server enhanced for ICS supports indicating the traffic leg as specified in IETF RFC 7549 [50], then the MSC server enhanced for ICS if required by local policy may:

a) if the bottommost URI does not contain the "tokenized-by" URI parameter, append the "iotl" SIP URI parameter set to "visitedA-homeA" to the URI of the bottommost Route header field; and

b) if the bottommost URI contains the "tokenized-by" URI parameter, append the "iotl" SIP URI parameter set to "visitedA-homeA" to the URI of the second Route header field from the bottom;

– an Event header field set to the "reg" event package;

– an Expires header field set to a value higher than the registration expiration interval value indicated in the SIP 200 (OK) response to the SIP REGISTER request;

– a Contact header field set to the SIP URI of the MSC Server enhanced for ICS;

– a P-Asserted-Identity header field set a SIP URI that contains the default public user identity received in the SIP 200 (OK) response to the SIP REGISTER request;

– a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [27] and with the type 1 "orig-ioi" header field parameter. The MSC server enhanced for ICS shall set the type 1 "orig-ioi" header field parameter to a value that identifies the network in which the MSC server enhanced for ICS resides. The MSC server enhanced for ICS shall not include the type 1 "term-ioi" header field parameter parameter; and

– a P-Access-Network-Info header field set as specified for the access network technology as specified in 3GPP TS 24.229 [11].

Upon receipt of a dialog establishing SIP NOTIFY request, as specified in IETF RFC 6665 [32], associated with the SIP SUBSCRIBE request, the MSC Server enhanced for ICS shall:

1) store the information for the established dialog;

2) store the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the SIP NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SIP SUBSCRIBE request;

3) store the value of the "term-ioi" header field parameter and the value of the "transit-ioi" header field parameter received in the P-Charging-Vector header field, if present; and

4) follow the procedures specified in IETF RFC 6665 [32].

The MSC Server enhanced for ICS shall automatically refresh the subscription for the reg event package for a previously registered public user identity for the period of time in which that registration remains active. The MSC Server enhanced for ICS shall refresh the subscription either 600 seconds before the expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or less. If a SIP SUBSCRIBE request to refresh a subscription fails with a non-481 response, the MSC Server enhanced for ICS shall still consider the original subscription valid for the duration of the most recently known "Expires" value according to IETF RFC 6665 [32]. Otherwise, the MSC Server enhanced for ICS shall consider the subscription invalid and start a new initial subscription according to IETF RFC 6665 [32].

Upon receipt of a SIP NOTIFY request for the dialog associated with the subscription to the reg event package with a state attribute "active", i.e. registered is received for one or more public user identities, the MSC Server enhanced for ICS shall:

1) store the information for the established dialog;

2) store the expiration time indicated in the "expires" header field parameter of the Subscription-State header field, if present, of the SIP NOTIFY request. Otherwise the expiration time is retrieved from the Expires header field of the 2xx response to SIP SUBSCRIBE request;

3) store the indicated public user identities as registered;

4) for each public user identity indicated in the notification that contains a <pub-gruu> element or a <temp-gruu> element or both (as defined in IETF RFC 5628 [35]) store the value of those elements in association with the public user identity;

5) store the value of the "orig-ioi" header field parameter and the value of "transit-ioi" header field parameter received in the P-Charging-Vector header field, if present; and

6) follow the procedures specified in IETF RFC 6665 [32].

When sending a final response to the SIP NOTIFY request, the MSC server enhanced for ICS shall insert in the P-Charging-Vector header field the "orig-ioi" header field parameter, if received in the request, and a type 1 "term-ioi" header field parameter. The MSC server enhanced for ICS shall set the type 1 "term-ioi" header field parameter to a value that identifies the network in which the MSC server enhanced for ICS resides, and the type 1 "orig-ioi" header field parameter is set to the previously received value of type 1 "orig-ioi" header field parameter.

6.3.5 Reregistration

The MSC Server enhanced for ICS can perform the reregistration of a previously registered public user identity with its contact address at any time after the initial registration has been completed.

Unless the MSC Server enhanced for ICS has determined that a continued registration is not required, the MSC Server enhanced for ICS shall reregister an already registered public user identity if that subscriber is still registered to that VLR. The MSC Server enhanced for ICS shall register the already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the MSC Server enhanced for ICS intends to update its capabilities according to IETF RFC 3840 [34].

On sending the REGISTER request for reregistration, the MSC Server enhanced for ICS shall populate headers as described in subclause 6.3.2.

If the MSC Server enhanced for ICS fails to forward the REGISTER request, the MSC Server enhanced for ICS shall abort the reregistration attempt.

NOTE: This will not affect the UE’s CS domain registration status at the MSC Server enhanced for ICS or HSS or HLR.

On receiving a 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall perform the actions defined for 200 (OK) response handling in subclause 6.3.2.

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the MSC Server enhanced for ICS shall perform the actions defined for 423 (Interval Too Brief) response handling in subclause 6.3.2.

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response for a reregistration, the MSC Server enhanced for ICS shall perform the procedures for initial registration as described in subclause 6.3.2.

On receiving a 3xx response response or a 480 (Temporarily Unavailable) response or a 503 (Service Unavailable) response for a reregistration, the MSC server enhanced for ICS shall:

1) select a different exit or entry point as described in subclause 6.3.3; and

2) perform the procedures for initial registration as described in subclause 6.3.2.

When the timer F expires at the MSC Server enhanced for ICS, the MSC Server enhanced for ICS shall:

1) select a different exit or entry point as described in subclause 6.3.3; and

2) perform the procedures for initial registration as described in subclause 6.3.2.

6.3.6 Deregistration

6.3.6.1 S-CSCF initiated deregistration

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package on behalf of the UE, as described in subclause 6.3.4, including a <registration> element which was registered by the MSC Server enhanced for ICS with either:

– the state attribute set to "terminated" and the event attribute within the <contact> element belonging to this UE set to "expired", "probation", "unregistered", "rejected" or "deactivated"; or

– the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated", and the event attribute within the <contact> element belonging to this UE set to "expired", "probation", "unregistered", "rejected" or "deactivated";

the MSC Server enhanced for ICS shall remove all stored information for these public user identities and remove these public user identities from the list of the public user identities that are registered for this user. In case of a "deactivated" event attribute, the MSC Server enhanced for ICS shall start the initial registration procedure as described in subclause 6.3.1. In case of a "rejected" event attribute, the MSC Server enhanced for ICS shall release all IMS dialogs related to those public user identities.

6.3.6.2 MSC Server enhanced for ICS initiated deregistration

The MSC Server enhanced for ICS initiated deregistration procedure consists of the MSC Server enhanced for ICS sending a REGISTER request on behalf of the UE upon receipt of any indication that the subscriber is no longer active at this MSC Server enhanced for ICS. On receiving Location Cancellation request, the MSC Server enhanced for ICS should delay sending the REGISTER request for deregistration for a specific time 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.

NOTE 1: Terminating calls received while the MSC server delays the sending of the REGISTER request for deregistration are handled according to 3GPP TS 29.292 [24], subclause 5.4.2.

If the source MSC server enhanced for ICS receives a NOTIFY request (indicating that its registration of the UE has been terminated, as described in subclause 6.3.4) on the dialog which was generated during subscription to the reg event package on behalf of the UE, while the timer is still running, the source MSC server shall not initiate the deregistration procedure on behalf of the UE.

Prior to sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall release all IMS dialogs related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities.

On sending a REGISTER request for deregistration, the MSC Server enhanced for ICS shall:

1) set the Request-URI to the SIP URI of the domain name of the home network used to address the REGISTER request;

2) set the From header field to the SIP URI that contains the temporary public user identity to be deregistered;

3) set the To header field to the SIP URI that contains the temporary public user identity to be deregistered;

4) set the Contact header field set to include the SIP URI containing the IP address or FQDN of the MSC Server enhanced for ICS in the hostport parameter. The MSC Server enhanced for ICS shall include a +sip.instance parameter containing the instance ID that was used during registration;

5) set the Via header field to include the IP address or FQDN of the MSC Server enhanced for ICS in the sent-by field;

5A) populate an Authorization header field, with:

– the username directive, set to the value of the private user identity;

– the realm directive, set to the domain name of the home network;

– the integrity-protected directive, set to "auth-done";

– the uri directive, set to the SIP URI of the domain name of the home network;

– the nonce directive, set to an empty value; and

– the response directive, set to an empty value;

6) a registration expiration interval value set to the value of zero;

7) send the request as specified in subclause 6.3.3.

On receiving the 200 (OK) response to the REGISTER request, the MSC Server enhanced for ICS shall:

1) remove all registration details relating to this public user identity; and

2) if a "term-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "term-ioi" header field parameter.

3) if a "transit-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "transit-ioi" header field parameter.

On receiving a 481 (Call Leg/Transaction Does Not Exist) response to the REGISTER request, the MSC Server enhanced for ICS shall remove all registration details relating to this public user identity.

NOTE 2: Other final responses than 200 (OK) and 481 (Call Leg/Transaction Does Not Exist) responses might require the MSC Server enhanced for ICS to perform cleanup such as removing details related to that public user identity. The details of such actions are not specified in this version of the specification.

The MSC Server enhanced for ICS shall consider any existing subscription to the reg event package cancelled (i.e. as if the MSC Server had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

6.4 SCC AS

The SCC AS can obtain registration state information that it needs to implement ICS specific requirements from:

a) any received third-party REGISTER request (e.g. including information contained in the body of the third-party REGISTER request) as specified in 3GPP TS 24.229 [11];

b) any received reg event package as specified in 3GPP TS 24.229 [11]; or

c) the Sh interface as specified in 3GPP TS 29.328 [25] and 3GPP TS 29.329 [26].

NOTE: Obtaining registration state information from HSS using Sh interface does not allow the SCC AS to know the capabilities supported by the user registered UE(s), including the used IP-CAN(s).