Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 23.228  Word version:  18.0.0

Top   Top   Up   Prev   None
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…

 

AA.3  SBI Capable HSS Discovery and Selectionp. 349

AA.3.1  Generalp. 349

An SBI capable IMS entity (e.g. I-CSCF, S-CSCF or IMS AS) performs HSS discovery to discover an HSS that manages the user subscriptions.
The SBI capable IMS entity shall utilize the NRF to discover the SBI capable HSS instance(s) unless the information about SBI capable HSS instances is available by other means, e.g. locally configured on the SBI capable IMS entity. The HSS selection function in SBI capable IMS entities selects an SBI capable HSS instance based on the available SBI capable HSS instances (obtained from the NRF or locally configured).
An SBI capable IMS entity always selects an HSS within its own PLMN. The HSS selection should consider one of the following factors when available to the SBI capable IMS entity:
  1. HSS Group ID of the IMS identity (IMPI or IMPU, or PSI).
  2. IMS private identity (IMPI); e.g. the SBI capable IMS entity selects an SBI capable HSS instance based on the IMPI set the UE's IMPI belongs to, configured locally or based on the results of a discovery procedure with NRF using the UE's IMPI as input for HSS discovery.
  3. IMS public identity (IMPU); e.g. the SBI capable IMS entity selects an SBI capable HSS instance based on the IMPU set the UE's IMPU belongs to, configured locally or based on the results of a discovery procedure with NRF using the UE's IMPU as input for HSS discovery.
  4. Public Service Identity (PSI); e.g. the SBI capable IMS entity selects an SBI capable HSS instance based on the PSI set the received PSI belongs to, configured locally or based on the results of a discovery procedure with NRF using the received PSI as input for HSS discovery.
  5. MSISDN; e.g. the SBI capable IMS entity selects an SBI capable HSS instance based on the MSISDN set the UE's MSISDN belongs to, configured locally or based on the results of a discovery procedure with NRF using the MSISDN as input for HSS discovery.
Unless the information about the interface type to be used towards HSS is locally configured on the SBI capable IMS entity, an SBI capable IMS entity can also use the NRF to decide the type of interface (SBI vs diameter) to be used towards HSS.
The following clause describes the procedure for HSS registration in NRF, SBI capable HSS discovery and interface type selection via NRF.
Up

AA.3.2  HSS Registration in NRFp. 350

An SBI capable HSS registers in the NRF using the Nnrf_NFManagement_NFRegister Request message as defined in TS 23.502. The NF profile of the HSS registered in NRF includes necessary information for an SBI capable IMS entity to send SBI service requests to the selected SBI capable HSS service instance.
Different SBI capable HSS instances managing different sets of IMPIs/IMPUs may be deployed in a given PLMN. In this case, the SBI capable HSS instances register in NRF using either different ranges of IMPIs/IMPUs and/or HSS Group IDs.
Up

AA.3.3  HSS Discovery and Selection via NRFp. 350

AA.3.3.1  Generalp. 350

During the IMS procedure, an SBI capable IMS entity sends a Nnrf_NFDiscovery_Request to NRF as defined in TS 23.502 to discover SBI capable HSS instances within a given PLMN. The SBI capable IMS entity may store all returned SBI capable HSS instances and their NF profiles for subsequent use, including, if applicable, supported IMPIs/IMPUs ranges, and/or HSS Group IDs. If no SBI capable HSS instance is available in the PLMN, then the NRF replies to the SBI capable IMS entity with no information. In this case, the SBI capable IMS may then attempt to communicate with the HSS using non-SBA protocols.
When an SBI capable IMS entity receives an NRF response that HSS supports SBI and stores the information received from the HSS, it shall make use of Nnrf_NFStatusSubscribe/Unsubscribe service operations with NRF as defined in TS 23.502 to receive Nnrf_NFStatusNotify service operation for updates to the NF profiles of SBI capable HSS instances registered in NRF.
Up

AA.3.3.2  HSS Discoveryp. 351

The call flow in Figure AA.3.3.2-1 illustrates the steps to locate the HSS instance for an IMS public identity.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AA.3.3.2-1: HSS discovery and selection
Figure AA.3.3.2-1: HSS discovery and selection
(⇒ copy of original 3GPP image)
Up
Steps 1 - 2 may be performed, any time after power up, e.g. in the scenario where only a single HSS instance or HSS group is deployed, and in the scenario where an operator has IMPI/IMPU ranges that are registered in NRF as described in clause AA.3.2. In this case there is no need for any IMPU to perform the 2 steps.
Step 1.
An SBI capable IMS entity may discover the SBI capable HSS instances available in the PLMN via Nnrf_NFDiscovery_Request.
Step 2.
The NRF provides the SBI capable IMS entity with the HSS instances and/or any HSS Group IDs registered in the PLMN. If no SBI capable HSS instance and/or any HSS Group ID is available in the PLMN, then the NRF will reply to the SBI capable IMS entity with no information about available SBI capable HSS instances.
Step 3.
The SBI capable IMS entity receives an IMS procedure related to a given IMS user (IMPI or IMPU depending on the procedure).
Steps 4 - 6 may be performed, e.g. if the SBI capable IMS entity did not retrieve and store information about HSS instances and/or HSS Group IDs registered in the PLMN at an earlier stage (performed steps 1-2).
Step 4.
An SBI capable IMS entity may discover the SBI capable HSS instances available in the PLMN via Nnrf_NFDiscovery_Request.
Step 5.
The NRF provides the SBI capable IMS entity with the HSS instances and/or any HSS Group IDs registered in the PLMN. If no SBI capable HSS instance and/or any HSS Group ID is available in the PLMN, then the NRF will reply to the SBI capable IMS entity with no information about available SBI capable HSS instances.
Step 6.
The SBI capable IMS entity stores the result of the NRF discovery, if any is received. The IMS capable entity may store the received response for future use, otherwise the IMS entity must perform the query in response to each IMS request it receives.
If the SBI capable IMS entity received no results at all, the procedure is exited, and the SBI capable IMS entity may use Diameter interfaces to interact with an HSS.
Steps 7 - 10 are performed only if the SBI capable IMS entity cannot locate an HSS instance corresponding to the IMS public identity based on stored information.
Step 7.
The SBI capable IMS entity sends to NRF an Nnrf_NFDiscovery_Request with the IMS public identity received in step 3.
Step 8.
NRF may query the UDR, via the Nudr_GroupIDmap service, for the HSS Group ID corresponding to the IMS public identity.
Step 9.
If requested the UDR returns the HSS-IMS Group ID to NRF.
Step 10.
NRF locates HSS instance(s) corresponding to the HSS Group ID. NRF returns and provides and them to the SBI capable IMS entity the HSS instance(s) profile which includes the HSS Group ID.
Step 11.
The SBI capable IMS entity selects the HSS instance.
Step 12.
The SBI capable IMS entity can then start interaction with the selected HSS instance.
Up

AA.3.3.3  Handling of HSS Group ID in IMS Procedures |R17|p. 352

The HSS group ID may be transported in SIP signalling related to the following procedures:
  • Initial IMS Registration procedure.
  • IMS Terminating session establishment procedure.
  • IMS Originating session establishment procedure.
An SBI enabled I-CSCF receiving an HSS Group ID during the NRF-based HSS discovery procedure should include the HSS Group ID for transportation to the next hop in subsequent SIP signalling related to the above procedures.
In addition, every IMS node receiving an HSS Group ID in SIP signalling (e.g. S-CSCF and IMS AS) should store it as part of the UE information, and should use the received HSS Group ID to select an SBI capable HSS. Additionally, an IMS node receiving an HSS Group ID in SIP signalling should include it in subsequent SIP signalling related to the above procedures.
The HSS Group ID in SIP signalling is specific to the UE served by this IMS and shall not be sent to any other party involved in the session/communication (e.g. to the terminating side and/or outside the HPLMN).
Up

AB  Support of IMS in SNPN |R17|p. 353

AB.1  IMS in SNPNp. 353

AB.1.0  Generalp. 353

Annex AB describes deployment options for SNPNs to enable access to IMS services for SNPN subscribers. Two potential deployment options are described below.
For the purpose of this Annex, an IMS Subscription Holder (ISH) identifies the administrative domain holding the IMS subscription for a UE subscribed to receive IMS services.
The ISH can be the same or independent from the SNPN domain which deploys the 5GS. In the case the ISH is different from the administrative domain of the SNPN, the UE needs to have two separate subscriptions, one for accessing the 5GS of the SNPN (provided by the SNPN or Credentials Holder (CH) as defined in TS 23.501) and one for accessing IMS services provided by the ISH. The UE needs to be successfully authenticated in each domain, using the appropriate subscription, before able to receive IMS services.
Up

AB.1.1  SNPN deployed IMSp. 353

In this option, the SNPN deploys its own IMS used by subscribers with a SNPN 5GS subscription. The SNPN and the ISH belong to the same administrative domain. In this deployment scenario, either USIM/ISIM or IMC is used to authenticate and authorize a UE for accessing IMS services.

AB.1.2  IMS services provided by independent IMS providerp. 353

AB.1.2.1  Generalp. 353

This option is applicable to SNPNs not providing own IMS services. It enables the SNPN to use IMS services from an independent IMS provider, e.g. PLMN or another entity, which is the ISH, providing IMS services for SNPN subscribers.
It is assumed that the SNPN has an agreement with the ISH. This agreement describes e.g. P-CSCF address provisioning and security aspects for all standardized reference points that are implemented between both administrative domains.
In this deployment option either IMC or USIM/ISIM credentials are used to authenticate and authorize a UE for IMS services.
The UE holds an association between an SNPN subscription and the corresponding IMS subscription to ensure proper credentials are used to access SNPN and IMS services in this deployment option. The mechanism how this association is stored in the UE is out of scope of 3GPP.
A potential architecture for this deployment option is depicted in Figure AB.1.2.1-1.
Copy of original 3GPP image for 3GPP TS 23.228, Fig. AB.1.2.1-1: Potential deployment architecture for IMS services in SNPN provided by independent IMS provider
Up

AB.1.2.2  Support for Emergency Servicesp. 354

Support for Emergency Services requires that the SNPN, based on an agreement with the ISH, broadcasts IMS Emergency Services support as described in TS 23.501.

AB.1.2.3  SNPN Support for Multiple Independent IMS Providersp. 354

In order for an SNPN to enable IMS services to be provided via multiple independent ISH, it is required that for every SNPN subscriber, the IMS DNN stored in UDM of the SNPN contains the information, which is used to identify the corresponding ISH, e.g. ISH domain name is encoded as part of IMS DNN. At PDU session setup, the SMF selects the P-CSCF of the ISH based on clause 5.16.3.11 and clause 5.16.3.4 of TS 23.501.
The CH and SNPN need to agree that the AMF in SNPN that receives the subscription information that includes the IMS DNN and contains information to identify the corresponding ISH, is able to determine the ISH and therefore derive correctly the IMS voice over PS Session Supported Indication as defined in clause 5.16.3.2 of TS 23.501.
Up

$  Change historyp. 355


Up   Top