5.1 CSCF related procedures

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

5.1.0 Establishing IP-Connectivity Access Network bearer for IM CN Subsystem Related Signalling

Before the UE can request IM services, an appropriate IP‑CAN bearer must be available to carry IM Subsystem related signalling.

For a UE using the IMS Local Breakout procedure as shown in Annex M, the IP address of the UE obtained from the local Gateway (i.e. single IP address) is used for both IM Subsystem related signalling and media.

5.1.1 Procedures related to Proxy‑CSCF discovery

5.1.1.0 General

The Proxy‑CSCF discovery shall be performed using one of the following mechanisms:

– As part of the establishment of connectivity towards the IP-Connectivity Access Network, if the IP-Connectivity Access Network provides such means.

– Alternatively, the P‑CSCF discovery may be performed after the IP connectivity has been established. To enable P‑CSCF discovery after the establishment of IP connectivity, the IP-Connectivity Access Network shall provide the following P‑CSCF discovery option to the UE:

– Use of DHCP to provide the UE with the domain name and/or IP address of a Proxy‑CSCF and the address of a Domain Name Server (DNS) that is capable of resolving the Proxy‑CSCF name, as described below in clause 5.1.1.1.

– The UE may be configured (e.g. during initial provisioning or via a 3GPP IMS Management Object (MO), TS 24.167 [64] or in the ISIM, TS 31.103 [69]) to know the fully qualified domain name (FQDN) of the P‑CSCF or its IP address. If the domain name is known, DNS resolution is used to obtain the IP address.

If DNS is used to obtain the IP address of the P-CSCF, the name-address resolution mechanism is allowed to take the load information of the P-CSCFs (e.g. obtained using network management procedures) into consideration when deciding the address of the P-CSCF for the UE.

In the case where UE is aware of more than one P‑CSCF address, the selection shall be based on home operator configured policy to select the P‑CSCF.

NOTE: Subject to home operator policy, the UE selects the Home P‑CSCF to be used by either using a pre-configured Home P‑CSCF FQDN or according to TS 24.167 [64]. This can be done without the UE first performing the local P‑CSCF discovery (e.g. DHCP).

5.1.1.1 DHCP/DNS procedure for P‑CSCF discovery

The DHCP relay agent within the IP-Connectivity Access Network relays DHCP messages between UE and the DHCP server.

Figure 5.0a: P‑CSCF discovery using DHCP and DNS

1. Establish an IP-Connectivity Access Network bearer if not already available by using the procedures available in the IP-Connectivity Access Network.

2. The UE requests a DHCP server and additionally requests the domain name and/or IP address of the P‑CSCF and IP addresses of DNS servers. It may require a multiple DHCP Query/Response message exchange to retrieve the requested information.

3. The UE performs a DNS query to retrieve a list of P‑CSCF(s) IP addresses from which one is selected. If the response does not contain the IP addresses, an additional DNS query is needed to resolve a Fully Qualified Domain Name (FQDN) to an IP address.

After reception of domain name and IP address of a P‑CSCF the UE may initiate communication towards the IM subsystem.

5.1.1.2 Void

5.1.2 Procedures related to Serving‑CSCF assignment

5.1.2.1 Assigning a Serving‑CSCF for a user

When a UE attaches and makes itself available for access to IMS services by explicitly registering in the IMS, a S‑CSCF shall be assigned to serve the UE.

The assignment of an S‑CSCF is performed in the I‑CSCF. The following information is needed in the selection of the S‑CSCF:

1. Required capabilities for user services
This information is provided by the HSS.

2. Operator preference on a per-user basis
This information is provided by the HSS.

3. Capabilities of individual S‑CSCFs in the home network
This is internal information within the operator’s network. This information may be used in the S‑CSCF selection. This information is obtained by the I‑CSCF by methods not standardised in this release.

4. Topological (i.e. P‑CSCF) information of where the user is located
This is internal information within the operator’s network. This information may be used in the S‑CSCF selection. The P‑CSCF name is received in the registration request. The topological information of the P‑CSCF is obtained by the I‑CSCF by methods not standardised in this Release.

5. Topological information of where the S‑CSCF is located
This is internal information within the operator’s network. This information may be used in the S‑CSCF selection. This information is obtained by the I‑CSCF by methods not standardised in this release.

6. Availability of S‑CSCFs
This is internal information within the operator’s network. This information may be used in the S‑CSCF selection. This information is obtained by the I‑CSCF by methods not standardised in this release.

In order to support the S‑CSCF selection described above and to allow the S‑CSCF to perform its tasks, it is required that the following types of information be transferred between the CSCF and the HSS:

1 The Cx reference point shall support the transfer of CSCF-UE security parameters from HSS to CSCF.

– This allows the CSCF and the UE to communicate in a trusted and secure way (there is no à priori trust relationship between a UE and a CSCF)

– The security parameters can be for example pre-calculated challenge-response pairs, or keys for an authentication algorithm, etc.

2 The Cx reference point shall support the transfer of service parameters of the subscriber from HSS to CSCF.

– This may include e.g. service parameters, Application Server address, triggers, information on subscribed media etc. The information on subscribed media is provided in the form of a profile identifier; details of the allowed media parameters associated with the profile identifier are configured in the S‑CSCF.

3 The Cx reference point shall support the transfer of CSCF capability information from HSS to CSCF.

– This may include e.g. supported service set, protocol version numbers etc.

4 The Cx reference point shall support the transfer of session signalling transport parameters from CSCF to HSS. The HSS stores the signalling transport parameters and they are used for routing mobile terminated sessions to the Serving‑CSCF.

– The parameters may include e.g. IP-address and port number of CSCF, transport protocol etc.

The information mentioned in items 1 – 4 above shall be transferred before the CSCF is able to serve the user. It shall also be possible to update this information while the CSCF is serving the user, for example if new services are activated for the user.

5.1.2.2 Cancelling the Serving‑CSCF assignment

Cancellation of the assigned Serving CSCF is either:

– Initiated from the Serving CSCF itself, e.g. due to timeout of the registration

– Performed as a result of an explicit deactivation/de-registration from the IMS. This is triggered by the UE.

– Performed due to a request from the HSS over the Cx interface, e.g. due to changes in the subscription.

5.1.2.3 Void

5.1.3 Procedures related to Interrogating‑CSCF

The architecture shall support multiple I‑CSCFs for each operator. A DNS-based mechanism for selecting the I‑CSCF shall be used to allow requests to be forwarded to an I‑CSCF based, for example, on the location or identity of the forwarding node.

5.1.4 Procedures related to Proxy‑CSCF

The routing of the SIP registration information flows shall not take into account previous registrations (i.e., registration state). The routing of the session information flows (e.g., INVITE) shall take into account the information received during the registration process.

5.1.5 Subscription Updating Procedures

5.1.5.0 General

Whenever a modification has occurred in the subscription data that constitutes the data used by the S‑CSCF, the complete subscription data set shall be sent to the S‑CSCF by the HSS. HSS shall use the Push model for downloading the subscription data to the S‑CSCF.

5.1.5.1 Subscription updating information flow

This clause provides the information flows for subscription data updating procedure.

Figure 5.0b: Subscription data updating

1. The HSS sends the Cx-Update_Subscr_Data with the subscription data to the S‑CSCF.

2. The S‑CSCF sends Cx-Update_Subscr_Data Resp to the HSS to acknowledge the sending of Cx-Update_Subscr_Data