Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.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.5.3…   5.6…   5.6.3…   5.7…   5.7.3…   5.7.5…   5.7.8…   5.8…   5.10…   5.11…   5.11.3…   5.11.3.3   5.11.3.4   5.11.4…   5.11.5…   5.11.5.3…   5.11.6…   5.12…   5.16…   5.16.2…   5.19…   5.20…   A…   E…   E.2.2…   G…   G.5…   H   I…   J…   K…   L…   M…   M.3…   N…   P…   Q…   Q.2.5…   R…   S…   T…   U…   U.2…   V…   W…   X…   Y…   Z…   AA…   AA.3…   AB…   AC…   AC.7…   AC.7.2…   AC.7.2.2   AC.7.2.3…   AC.7.4…   AC.9…

 

5.8  Procedures related to routing information interrogationp. 146

5.8.0  General |R6|p. 146

When a mobile terminated session set-up arrives at an I-CSCF that is authorized to route sessions, the I-CSCF interrogates the HSS for routing information. The mobile terminated sessions for a user shall be routed to a S-CSCF.
The Cx reference point shall support retrieval of routing information from HSS to I-CSCF. The resulting routing information is the contact information of S-CSCF.

5.8.1  User identity to HSS resolutionp. 146

This clause describes the resolution mechanism, which enables the I-CSCF, the S-CSCF and the AS to find the address of the HSS, that holds the subscriber data for a given user identity when multiple and separately addressable HSSs have been deployed by the network operator. This resolution mechanism is implemented using a Subscription Locator Function (SLF) or a Diameter Proxy Agent that proxies the request to the HSS. This resolution mechanism is not required in networks that utilise a single HSS e.g. optionally, it could be switched off on the I-CSCF and on the S-CSCF and/or on the AS using O&M mechanisms. An example for a single HSS solution is a server farm architecture. By default, the resolution mechanism shall be supported.
On REGISTER and on MT INVITEs, the I-CSCF queries the HSS for user's subscription specific data, e. g. the actual location or authentication parameters. This also has to be accomplished by the S-CSCF on REGISTER. In the case when more than one independently addressable HSS is utilized by a network operator, the HSS where user information for a given subscriber is available has to be found. To get the HSS name the I-CSCF and the S-CSCF query the SLF entity or the I-CSCF and the S-CSCF send the query to the HSS via a Diameter Proxy Agent.
The SLF is accessed via the Dx interface or via the Dh interface. The Dx interface is the standard interface between the CSCF and the SLF and the Dh interface is the standard interface between the AS and the SLF. The synchronisation between the SLF and the different HSSs is an O&M issue.
A way to use the SLF is described in the following.
The Dx interface provides:
  • an operation to query the SLF from the I-CSCF or from the S-CSCF, respectively.
  • a response to provide the HSS name towards the I-CSCF or towards the S-CSCF, respectively.
By sending the Dx-operation DX_SLF_QUERY the I-CSCF or the S-CSCF indicates a user identity of which it is looking for an HSS. By the Dx-operation DX_SLF_RESP the SLF responds with the HSS name. The I-CSCF or the S-CSCF, respectively, continues by querying the selected HSS. The I-CSCF may forward the HSS name towards the S-CSCF. The S-CSCF may use this name to find the subscriber's HSS.
Clause 5.8.2 presents the session flows on REGISTER and clause 5.8.3 on INVITE messages.
The Dh interface provides:
  • an operation to query the SLF from the AS.
  • a response to provide the HSS name towards the AS.
By sending the Dh-operation DH_SLF_QUERY the AS indicates a Public User Identity of which it is looking for an HSS. By the Dh-operation DH_SLF_RESP the SLF responds with the HSS name. The AS continues by querying the selected HSS. The AS may store the HSS name for the subsequent Sh-operations.
Clause 5.8.4 presents the message flow on the Dh interface.
Up

5.8.2  SLF on registerp. 147

Reproduction of 3GPP TS 23.228, Fig. 5.20: SLF on register (1st case)
Up
Step 1.
I-CSCF receives a REGISTER request and now has to query for the location of the user's subscription data.
Step 2.
The I-CSCF sends a DX_SLF_QUERY to the SLF and includes as parameter the user identity which is stated in the REGISTER request.
Step 3.
The SLF looks up its database for the queried user identity.
Step 4.
The SLF answers with the HSS name in which the user's subscription data can be found.
Step 5.
The I-CSCF can proceed by querying the appropriate HSS.
Reproduction of 3GPP TS 23.228, Fig. 5.20a: SLF on register (2nd case)
Up
Step 1.
I-CSCF sends a REGISTER request to the S-CSCF. This now has to query for the location of the user's subscription data.
Step 2.
The S-CSCF sends a DX_SLF_QUERY to the SLF and includes as parameter the user identity which is stated in the REGISTER request.
Step 3.
The SLF looks up its database for the queried user identity.
Step 4.
The SLF answers with the HSS name in which the user's subscription data can be found.

5.8.3  SLF on UE invitep. 148

Reproduction of 3GPP TS 23.228, Fig. 5.21: SLF on UE invite
Up
Step 1.
I-CSCF receives an INVITE request and now has to query for the location of the user's subscription data.
Step 2.
The I-CSCF sends a DX_SLF_QUERY to the SLF and includes as parameter the user identity which is stated in the INVITE request. If the user identity is an E.164 number in the SIP URI with user=phone parameter format the I-CSCF shall first translate it into the Tel: URI format per RFC 3966 prior to sending to the SLF the DX_SLF_QUERY.
Step 3.
The SLF looks up its database for the queried user identity.
Step 4.
The SLF answers with the HSS name in which the user's subscription data can be found.
To prevent an SLF service failure e.g. in the event of a server outage, the SLF could be distributed over multiple servers. Several approaches could be employed to discover these servers. An example is the use of the DNS mechanism in combination with a new DNS SRV record. The specific algorithm for this however does not affect the basic SLF concept and is outside the scope of this document.
Up

5.8.4  SLF on AS access to HSS |R6|p. 149

The flow shown below is where the AS queries the SLF to identify the HSS to access.
Reproduction of 3GPP TS 23.228, Fig. 5.21a: SLF on AS access to HSS
Up
Step 1.
An AS sends a DH_SLF_QUERY to the SLF and includes as a parameter the Public User Identity.
Step 2.
The SLF looks up its database for the queried Public User Identity.
Step 3.
The SLF answers with the HSS name in which the user's subscription data can be found.
Step 4.
The AS sends the Sh message towards the correct HSS.

5.9  Routing of mid-session signallingp. 149

During the signalling exchanges that occur to establish an IM Session, the following elements must ensure future signalling messages related to this session are routed through them:
  • P-CSCF serving the originating UE, in order to generate the CDR record in the roaming case, and to force release of the resources used for the session.
  • S-CSCF serving the originating UE, in order to invoke any service logic required at session setup completion, and to generate the CDR record at session termination.
  • S-CSCF serving the terminating UE, in order to invoke any service logic required at session setup completion, and to generate the CDR record at session termination.
  • P-CSCF serving the terminating UE, in order to generate the CDR record in the roaming case, and to force release of the resources used for the session.
Other CSCFs (e.g. I-CSCFs) may optionally request this as well, for example if they perform some function needed in handling mid-session changes or session clearing operations.
All signalling message from the UE related to IMS sessions shall be sent to the P-CSCF.
Up

Up   Top   ToC