Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 29.500  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   5…   5.2.3.2…   5.2.3.3…   5.2.4…   6…   6.3…   6.4…   6.5…   6.6…   6.7…   6.10…   6.10.3…   6.10.6…   6.10.11…   6.10.12…   6.11…   A   B   C   D…

 

6.10.12  Indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN |R19|p. 122

6.10.12.1  Generalp. 122

This clause specifies specific requirements to support indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN, as specified in clause 6.3.1 of TS 23.501 and clause 4.17.10a of TS 23.502.
The terms "source PLMN" and "target PLMN" throughout this clause refer respectively to the PLMN originating the request (i.e. the PLMN of the NF service consumer) and the PLMN receiving/serving the request (i.e. the PLMN of the NF service producer).
Up

6.10.12.2  NF Discovery and Selectionp. 122

6.10.12.2.1  NF Discovery and Selection for indirect communication with delegated discoveryp. 122
When using indirect communication with delegated discovery between different PLMNs, the NF service consumer and SCP in the source PLMN shall include the necessary NF service discovery factors (as specified in clause 6.10.3.2) in the service request sent towards the target PLMN. The service request shall also include the 3gpp-Sbi-Discovery-target-plmn-list (or 3gpp-Sbi-Discovery-target-snpn) header identifying the target PLMN (or SNPN) and the 3gpp-Sbi-Discovery-requester-plmn-list (or 3gpp-Sbi-Discovery-requester-snpn-list) header identifying the source PLMN (or SNPN) ID.
When the SCP in the target domain receives a request containing "3gpp-Sbi-Discovery-*" request headers and a selection/reselection of the target NF service instance is required, the SCP shall take into account all the NF service discovery factors contained in the "3gpp-Sbi-Discovery-*" request headers to perform the selection or reselection, as specified in clause 6.10.3.2.
Up
6.10.12.2.2  NF Discovery and Selection for indirect communication without delegated discoveryp. 122
When using indirect communication without delegated discovery between different PLMNs, the NF service consumer or the SCP of the source PLMN shall select the NF (Service) Set or a specific NF (service) instance.
If the source PLMN only selects the NF (Service) Set, the selection of the target NF service instance shall be done by an SCP in the target PLMN. If the source PLMN selects a specific NF (service) instance, an SCP in the target PLMN may reselect the target NF service instance within the same NF (Service) Set.
The requirements specified in clause 6.10.5 shall apply. Additionally, the service request sent from the source PLMN to the target PLMN shall also include the 3gpp-Sbi-Discovery-target-plmn-list (or 3gpp-Sbi-Discovery-target-snpn) header identifying the target PLMN (or SNPN) and the 3gpp-Sbi-Discovery-requester-plmn-list (or 3gpp-Sbi-Discovery-requester-snpn-list) header identifying the source PLMN (or SNPN) ID.
Up

6.10.12.3  Routing mechanismsp. 123

6.10.12.3.1  Generalp. 123
This clause specifies how to route a service request from an NF service consumer in a source PLMN towards an NF service producer in a different PLMN, with possible NF selection at the target PLMN.
6.10.12.3.2  Routing within the source PLMNp. 123
Service requests shall be routed between the NF service consumer and the SCP within the source PLMN as specified for indirect communications in clauses 6.10.2 and 6.10.2A.
Service requests shall be routed between the SCP and the SEPP within the source PLMN:
  • as specified in clause 6.1.4.3, if a target NF instance has been selected by the source PLMN (i.e. by the NF service consumer or the SCP); additionnaly, if the address of an SCP in the target domain is also available (i.e. was received in the NF Discovery response from the NRF), the SCP in the source PLMN shall include the 3gpp-Sbi-Scp-apiRoot header in the service request it forwards to the SEPP set to the apiRoot of the SCP in the target domain;
  • as specified for indirect communications from one SCP to a next hop SCP in clause 6.10.2, with the SEPP taking the role of the next hop SCP, if no target NF instance has been selected by the source PLMN; additionally, if the address of an SCP in the target domain is available (i.e. was received in the NF Discovery response from the NRF), the SCP in the source PLMN shall include the 3gpp-Sbi-Scp-apiRoot header in the service request it forwards to the SEPP set to the apiRoot of the SCP in the target domain. The SCP in the source PLMN shall determine the SEPP towards which to send the service request taking into account the target PLMN (or SNPN) ID indicated in the 3gpp-Sbi-Discovery-target-plmn-list (or 3gpp-Sbi-Discovery-target-snpn) header. In this case, no 3gpp-Sbi-Target-apiRoot header shall be included in the service request sent towards the SEPP and the apiRoot of the request URI shall be set to the apiRoot of the SEPP.
Up
6.10.12.3.3  Routing between SEPPsp. 123
A service request shall be routed between the cSEPP and the pSEPP as specified in clause 6.1.4.3.4 if it contains the address of the target NF instance, i.e. it if contains the 3gpp-Sbi-Target-apiRoot header or a telescopic FQDN identifying the target address.
A service request shall be routed between the cSEPP and the pSEPP as follows if it does not contain the address of the target NF instance, i.e. no 3gpp-Sbi-Target-apiRoot header is present and no telescopic FQDN was used:
  • if PRINS security is negotiated between the SEPPs, the service request shall be routed as specified in clause 6.1.4.3.4. Additionally:
    • the cSEPP shall set the apiRoot of the Request URI of the encapsulated protected message to the apiRoot of the pSEPP; and
    • the cSEPP shall forward the 3gpp-Sbi-Scp-apiRoot header in the encapsulated protected message, if this header was received in the incoming request.
or
  • if TLS security is negotiated between the SEPPs, the cSEPP shall set the apiRoot of the request URI it forwards on the N32-f interface to the apiRoot of the pSEPP. The cSEPP shall then send the service request towards the pSEPP, without including the 3gpp-Sbi-Target-apiRoot header. The cSEPP shall forward the 3gpp-Sbi-Scp-apiRoot header in the service request, if this header was received in the incoming request.
Up
6.10.12.3.4  Routing within the target PLMNp. 123
If the service request contains the 3gpp-Sbi-Scp-apiRoot header, the pSEPP shall route the request to the target SCP in the target domain indicated in the 3gpp-Sbi-Scp-apiRoot header. When forwarding the service request towards the target SCP, the pSEPP shall remove the 3gpp-Sbi-Scp-apiRoot header and it shall set the apiRoot of the request URI to the apiRoot of the target SCP; the pSEPP shall forward the 3gpp-Sbi-Target-apiRoot header, if this header was received in the incoming request.
If the service request does not contain the 3gpp-Sbi-Scp-apiRoot header and does not contain the target apiRoot (i.e. if the apiRoot of the Request URI corresponds to the apiRoot of the pSEPP), the pSEPP shall route the service request to an SCP in the target domain (e.g. pre-configured in the pSEPP or discovered from the NRF) as specified for indirect communication from one SCP to a next hop SCP in clause 6.10.2, with the pSEPP taking the role of the SCP and the SCP in the target domain taking the role of the next hop SCP. The apiRoot of the Request URI shall be set to the apiRoot of the SCP in the target domain. The service request shall not contain the 3gpp-Sbi-Target-apiRoot header.
The service request shall then be routed from the SCP in the target domain to the target NF instance (possibly (re)selected by the target NF instance) as specified in clauses 6.1 or 6.10.2 (if the request is sent directly, or via another SCP towards the target NF instance, respectively).
Up

6.10.12.4  Authorization of NF service accessp. 124


Up   Top   ToC