Content for  TS 23.228  Word version:  16.6.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.2.4…   4.3…   4.4…   4.13…   4.16…   5…   5.2…   5.3…   5.4…   5.4.7…   5.4.8…   5.4a…   5.5…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.8…   5.11…   5.11.3…   5.11.4…   5.11.5…   5.11.6…   5.12…   5.16…   5.19   5.20…   A…   E…   E.2.2…   G…   G.5…   H…   J…   L…   N…   Q…   Q.2.5…   R…   S…   U…   U.2…   V…   Y…   Z…   AA…   AA.3…


5  IP multimedia subsystem procedures

5.0  General

This clause documents the main procedures that are used for the provision of services in the IP multimedia subsystem. These procedures are described using text description as well as information flow diagrams. The procedures described in this document are meant to provide a high level description and are not intended to be exhaustive.
In the following clauses, user roaming procedures apply to cases where P-CSCF is located in the visited network. Procedures for cases where the user is roaming and the P-CSCF is located in the home network are similar to procedures for a non-roaming user.

5.0a  Session-unrelated procedures |R6|Word‑p. 69
The IM CN Subsystem provides means to conduct session-unrelated interactions between users, e.g. OPTIONS query, outband REFER. These interactions are described in RFC 3261, and other possible IETF RFCs. The generic capability exchange mechanism is defined in TS 23.279.
These interactions shall use and fully comply with the basic mechanisms described for session-related procedures of the IM CN Subsystem. These mechanisms include e.g. routing, security, service control, network hiding as described in other clauses and specifications.

5.1  CSCF related procedures

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  General |R6|

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
  • The UE may be configured (e.g. during initial provisioning or via a 3GPP IMS Management Object (MO), TS 24.167 or in the ISIM, TS 31.103) 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.
Up  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.
(not reproduced yet)
Figure 5.0a: P-CSCF discovery using DHCP and DNS
Step 1.
Establish an IP-Connectivity Access Network bearer if not already available by using the procedures available in the IP-Connectivity Access Network.
Step 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.
Step 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.2  Procedures related to Serving-CSCF assignmentWord‑p. 70  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 a 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.
Up  Cancelling the Serving-CSCF assignmentWord‑p. 71
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.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-CSCFWord‑p. 72
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  General |R6|

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.  Subscription updating information flow

This clause provides the information flows for subscription data updating procedure.
(not reproduced yet)
Figure 5.0b: Subscription data updating
Step 1.
The HSS sends the Cx-Update_Subscr_Data with the subscription data to the S-CSCF.
Step 2.
The S-CSCF sends Cx-Update_Subscr_Data Resp to the HSS to acknowledge the sending of Cx-Update_Subscr_Data

Up   Top   ToC