Targeting a specific SCP for indirect communication

Abstract

A first service communication proxy of a source public land mobile network and a hypertext transfer protocol request for a service of a target public land mobile network is received. Means for determi

Description

TECHNICAL FIELD

[0001] The examples and non-limiting example embodiments relate generally to communications and, more particularly, to targeting a specific SCP for indirect communication. BACKGROUND

[0002] It is known for a communication device to gain access to a communication network via an access network node. SUMMARY

[0003] In accordance with an aspect, an apparatus includes means for receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network; means for determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; and means for transmitting the hypertext transfer protocol request to a security edge protection proxy; wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

[0004] In accordance with an aspect, an apparatus includes means for receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request; wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header; means for extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; and means for transmitting, to the target service communication proxy, the hypertext transfer protocol request. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The foregoing aspects and other features are explained in the following description, taken in connection with the accompanying drawings.

[0006] FIG. 1 is a block diagram of one possible and non-limiting system in which the example embodiments may be practiced.

[0007] FIG. 2 shows an example 5GC SBA.

[0008] FIG. 3 shows delegated NF service discovery when the NF service consumer and the NF service producer are in different PLMNs with possible NF selection at the target PLMN.

[0009] FIG. 4 is an example call flow diagram for transmission of an HTTP request, based on the examples described herein.

[0010] FIG. 5 is an example apparatus configured to implement the examples described herein.

[0011] FIG. 6 shows a representation of an example of non-volatile memory media used to store instructions that implement the examples described herein.

[0012] FIG. 7 is an example method, based on the examples described herein.

[0013] FIG. 8 is an example method, based on the examples described herein. DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0014] Turning to FIG. 1, this figure shows a block diagram of one possible and nonlimiting example in which the examples may be practiced. A user equipment (UE) 110, radio access network (RAN) node 170, and network element(s) 190 are illustrated. In the example of FIG. 1, the user equipment (UE) 110 is in wireless communication with a wireless network 100. A UE is a wireless device that can access the wireless network 100. The UE HOincludes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127. Each of the one or more transceivers 130 includes a receiver, Rx, 132 and a transmitter, Tx, 133. The one or more buses 127 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The UE 110 includes a module 140, comprising one of or both parts 140-1 and / or 140-2, which may be implemented in a number of ways. The module 140 may be implemented in hardware as module 140-1, such as being implemented as part of the one or more processors 120. The module 140-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 140 may be implemented as module 140-2, which is implemented as computer program code 123 and is executed by the one or more processors 120. For instance, the one or more memories 125 and the computer program code 123 may be configured to, with the one or more processors 120, cause the user equipment 110 to perform one or more of the operations as described herein. The UE 110 communicates with RAN node 170 via a wireless link 111.

[0015] The RAN node 170 in this example is a base station that provides access for wireless devices such as the UE 110 to the wireless network 100. The RAN node 170 may be, for example, a base station for 5G, also called New Radio (NR). In 5G, the RAN node 170 may be a NG-RAN node, which is defined as either a gNB or an ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface (such as connection 131) to a 5GC (such as, for example, the network element(s) 190). The ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected via the NG interface (such as connection 131) to the 5GC. The NG-RAN node may include multiple gNBs, which may also include a central unit (CU) (gNB-CU) 196 and distributed unit(s) (DUs) (gNB-DUs), of which DU 195 is shown. Note that the DU 195 may include or be coupled to and control a radio unit (RU). The gNB-CU 196 is a logical node hosting radio resource control (RRC), SDAP and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB that control the operation of one or more gNB-DUs. The gNB-CU 196 terminates the Fl interface connected with the gNB-DU 195. The Fl interface is illustrated as reference 198, although reference 198 also illustrates a link between remote elements of the RAN node 170 and centralized elements of the RAN node 170, such as between the gNB-CU 196 and the gNB-DU 195. The gNB-DU 195 is a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU 196. One gNB-CU 196 supports one or multiple cells. One cell may be supported with one gNB-DU 195, or one cell may be supported / shared with multiple DUs under RAN sharing. The gNB-DU 195 terminates the Fl interface 198 connected with the gNB-CU 196. Note that the DU 195 is considered to include the transceiver 160, e.g., as part of a RU, but some examples of this may have the transceiver 160 as part of a separate RU, e.g., under control of and connected to the DU 195. The RAN node 170 may also be an eNB (evolved NodeB) base station, for LTE (long term evolution), or any other suitable base station or node.

[0016] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N / W I / F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 may include the processor(s) 152, one or more memories 155, and network interfaces 161. Note that the DU 195 may also contain its own memory / memories and processor(s), and / or other hardware, but these are not shown.

[0017] The RAN node 170 includes a module 150, comprising one of or both parts 150-1 and / or 150-2, which may be implemented in a number of ways. The module 150 may be implemented in hardware as module 150-1, such as being implemented as part of the one or more processors 152. The module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the module 150 may be implemented as module 150-2, which is implemented as computer program code 153 and is executed by the one or more processors 152. For instance, the one or more memories 155 and the computer program code 153 are configured to, with the one or more processors 152, cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the module 150 may be distributed, such as being distributed between the DU 195 and the CU 196, or be implemented solely in the DU 195.

[0018] The one or more network interfaces 161 communicate over a network such as via the links 176 and 131. Two or more gNBs 170 may communicate using, e.g., link 176. The link 176 may be wired or wireless or both and may implement, for example, an Xn interface for 5G, an X2 interface for LTE, or other suitable interface for other standards.

[0019] The one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for gNB implementation for 5G, with the other elements of the RAN node 170 possibly being physically in a different location from the RRH / DU 195, and the one or more buses 157 could be implemented in part as, for example, fiber optic cable or other suitable network connection to connect the other elements (eg., a central unit (CU), gNB-CU 196) of the RAN node 170 to the RRH / DU 195. Reference 198 also indicates those suitable network link(s).

[0020] A RAN node / gNB can comprise one or more TRPs to which the methods described herein may be applied. FIG. 1 shows that the RAN node 170 comprises TRP 51 and TRP 52, in addition to the TRP represented by transceiver 160. Similar to transceiver 160, TRP 51 and TRP 52 may each include a transmitter and a receiver. The RAN node 170 may host or comprise other TRPs not shown in FIG. 1.

[0021] A relay node in NR is called an integrated access and backhaul node. A mobile termination part of the IAB node facilitates the backhaul (parent link) connection. In other words, the mobile termination part comprises the functionality which carries UE functionalities. The distributed unit part of the IAB node facilitates the so called access link (child link) connections (i.e. for access link UEs, and backhaul for other IAB nodes, in the case of multi-hop IAB). In other words, the distributed unit part is responsible for certain base station functionalities. The IAB scenario may follow the so called split architecture, where the central unit hosts the higher layer protocols to the UE and terminates the control plane and user plane interfaces to the 5G core network.

[0022] It is noted that the description herein indicates that “cells” perform functions, but it should be clear that equipment which forms the cell may perform the functions. The cell makes up part of a base station. That is, there can be multiple cells per base station. For example, there could be three cells for a single carrier frequency and associated bandwidth, each cell covering one-third of a 360 degree area so that the single base station’s coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and a base station may use multiple carriers. So if there are three 120 degree cells per carrier and two carriers, then the base station has a total of 6 cells.

[0023] The wireless network 100 may include a network element or elements 190 that may include core network functionality, and which provides connectivity via a link or links 181 with a further network, such as a telephone network and / or a data communications network (e.g., the Internet). Such core network functionality for 5G may include location management functions (LMF(s)) and / or access and mobility management function(s) (AMF(S)) and / or user plane functions (UPF(s)) and / or session management function(s) (SMF(s)). Such core network functionality for LTE may include MME (mobility management entity) / SGW (serving gateway) functionality. Such core network functionality may include SON (self-organizing / optimizing network) functionality. These are merely example functions that may be supported by the network element(s) 190, and note that both 5G and LTE functions might be supported. The RAN node 170 is coupled via a link 131 to the network element 190. The link 131 may be implemented as, e.g., an NG interface for 5G, or an SI interface for LTE, or other suitable interface for other standards. The network element 190 includes one or more processors 175, one or more memories 171, and one or more network interfaces (N / W I / F(s)) 180, interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. Computer program code 173 may include SON and / or MRO functionality 172.

[0024] The wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, or a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171, and also such virtualized entities create technical effects.

[0025] The computer readable memories 125, 155, and 171 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, non-transitory memory, transitory memory, fixed memory and removable memory. The computer readable memories 125, 155, and 171 may be means for performing storage functions. The processors 120, 152, and 175 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as nonlimiting examples. The processors 120, 152, and 175 may be means for performing functions, such as controlling the UE 110, RAN node 170, network element(s) 190, and other functions as described herein.

[0026] In general, the various example embodiments of the user equipment 110 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback devices having wireless communication capabilities, internet appliances including those permitting wireless internet access and browsing, tablets with wireless communication capabilities, head mounted displays such as those that implement virtual / augmented / mixed reality, as well as portable units or terminals that incorporate combinations of such functions. The UE 110 can also be a vehicle such as a car, or a UE mounted in a vehicle, a UAV such as e.g. a drone, or a UE mounted in a UAV. The user equipment 110 may be a terminal device, such as mobile phone, mobile device, sensor device etc., where the terminal device is a device used by the user or not used by the user.

[0027] UE 110, RAN node 170, and / or network element(s) 190, (and associated memories, computer program code and modules) may be configured to implement (e.g. in part) the methods described herein. Thus, computer program code 123, module 140-1, module 140-2, and other elements / features shown in FIG. 1 of UE 110 may implement user equipment related aspects of the examples described herein. Similarly, computer program code 153, module 150-1, module 150-2, and other elements / features shown in FIG. 1 of RAN node 170 may implement gNB / TRP related aspects of the examples described herein. Computer program code 173 and other elements / features shown in FIG. 1 of network element(s) 190 may be configured to implement network element related aspects of the examples described herein.

[0028] Having thus introduced a suitable but non-limiting technical context for the practice of the example embodiments, the example embodiments are now described with greater specificity.

[0029] FIG. 2 shows an example 5GC SBA 200. The 5GC (5G Core network) has been defined as a Service Based Architecture (SBA), with NF service producers (NFp) exposing services to NF service consumers (NFc). NF service producers register their NF profile in a Network Repository Function (NRF) (202, 204). The NF profile contains NF level specific information and the list of NF service instances supported by the NF with their associated attributes.

[0030] NF Service consumers or Service Communication Proxies (SCP) discover NF service producers by performing an NF Discovery procedure towards the NRF with query parameters describing the services or properties of the NF service producers they wish to discover. The NRF returns the NF profiles of candidate NF service producers matching the query parameters in the response. An NF Discovery response will typically contain NF profiles of multiple candidate producers.

[0031] In scenarios where the NFc and the NFp pertain to different domains (e.g. different PLMNs, SNPNs, or different regional organizations in a same PLMN) and using Indirect Communication with Delegated Discovery, the operator (or organization) of the target domain may prefer to perform the discovery and selection of the NFp in the target domain, e.g. for the following reasons (1-3): 1) to avoid disclosing information about candidate NFp that may be sensitive or that changes frequently (e.g. load and capacity info); 2) to enable the operator of the target domain to deploy its own discovery / selection policies, independently from NF implementations in other domains; 3) because SCPs in the target domain have the best knowledge about candidate NFp instances and sets, incl. load and capacity info, NF service status, etc.

[0032] SA#103 has approved a new 3GPP Rel-19 WID on NF discovery and selection by target PLMN (TEI19_NFsel_by_tPLMN), see SP-240490. The objective is to enable, for 5GC, the target PLMN / domain to perform the target NF producer selection based on target operator's policy, using indirect communication with or without delegated discovery (in the latter case, when the request indicates the NF set, the selection of the target NF instance in the set is delegated to the SCP of the target domain). SA#104 also relates to NF discovery and selection by the target PLMN.

[0033] The agreed procedure is included in TS 23.502: 4.17.10a Indirect Communication with possible delegated service discovery when NF service consumer and NF service producer are in different PLMNs with possible NF selection at target PLMN. This flow applies if NF service consumer and NF service producer are in different PLMNs and either indirect communication without delegated discovery" (Model C in Annex E of TS 23.501 [2]) or indirect communication with delegated discovery" (Model D in Annex E of TS 23.501 [2]) is used.

[0034] FIG. 3 shows delegated NF service discovery when the NF service consumer 302 and NF service producer 316 are in different PLMNs (308, 310) with possible NF selection at target PLMN 310. FIG. 3 shows the signaling between NF service consumer 302, SCP 304, and NRF 306 of PLMN-1 308, and SCP 312, NRF 314, and NF service producer 316 of PLMN-2 310, including steps 0-10 as described below:

[0035] 0. For indirect communication without delegated discovery (Model C in Annex E of TS 23.501), the NF-service consumer retrieves NF profiles as shown in Figure 4.17.5-1 and selects either an NF producer instance or an NF instance set. In this flow it is assumed that the NF service consumer is not updated to support the "indirect communication without delegated discovery with NF selection at target domain" feature and / or the "indirect communication with delegated discovery with NF selection at target domain" feature.

[0036] 1. The NF service consumer intends to communicate with an NF service producer. The NF service consumer sends the request to an SCP. The request includes at least the source PLMN ID and the target PLMN ID in the discovery (only for Model D in Annex E of TS 23.501) and selection parameters necessary for the SCP to discover and select aNF service producer instance. The discovery and selection parameters are included in the request by the NF service consumer in a way that the SCP does not need to parse the request body. For indirect communication without delegated discovery (Model C in Annex E of TS 23.501), see also step 1 of Figure 4.17.11-1. If a NF instance was selected by the NF consumer in step 0, steps 2 to 4 are optional.

[0037] 2. The SCP recognises that the request is for a NF service producer in another PLMN. SCP interacts with NRF using theNnrf NFDiscovery service. The SCP may include an indication of "support of indirect communication without delegated discovery with NF selection at target domain feature" (Model C in Annex E of TS 23.501) and / or an indication of "support of indirect communication with delegated discovery with NF selection at target domain feature" (Model D in Annex E of TS 23.501).

[0038] 3. NRF in PLMN-1 and NRF in PLMN 2 interact using the Nnrf_NFDiscovery service. See step 2 in clause 4.17.5. If the SCP provided an indication of "support of indirect communication with delegated discovery with NF selection at target domain feature" and / or of "support of indirect communication without delegated discovery with NF selection at target domain feature" in step 2 and the NRF in PLMN-1 supports those features, the NRF in PLMN-1 includes an indication of support of those features.

[0039] Based on operator's policy and the received indication of support of related features, the NRF in PLMN-2 provides an NF discovery response that contains one of (a-c):

[0040] a) Either NF profiles matching parameters provided in the NnrfDiscovery request; or

[0041] b) If an indication of "support of indirect communication with delegated discovery with NF selection at target domain feature" was received and that option is preferred by NRF in PLMN-2, no candidate NF profiles but the indication that "indirect communication with delegated discovery with NF selection at target domain is requested",, optionally an indication that the reply applies to all NF types (otherwise the indication only relates to the NF type requested in the Nnrf NFDiscovery request), and optionally the address of an SCP in PLMN2 where to send the request.

[0042] c) If an indication of "support of indirect communication without delegated discovery with NF selection at target domain feature" was received and that option is preferred by NRF in PLMN-2, candidate NF profiles and the indication that "indirect communication without delegated discovery with NF selection at target domain is requested", optionally an indication that the reply applies to all NF types (otherwise the indication only relates to the NF type requested in the Nnrf NFDiscovery request), and optionally the address of an SCP in PLMN2 where to send the request.

[0043] For indirect communication without delegated discovery with NF selection at target PLMN, when the request indicates the NF set, the selection of the target NF instance in the set is delegated to the SCP of the target domain. This is also possible for follow-up requests if suitable binding information is received, e.g. NF instance reselection at the target PLMN.

[0044] The NRF in PLMN-1 may cache the response and use it to answer subsequent Nnrf NFDiscovery without interactions with the NRF in PLMN-2. The cached response can be applied for the entire PLMN-2 and it can be assumed that it does not depend on which NRF in PLMN-2 provided it.

[0045] The NRF in PLMN-1 can also interact with the NRFs in PLMN-2 already before receiving related discovery requests to inquire the support of indirect communication by PLMN-2, cache the received information, and use it to answer subsequent discovery requests.

[0046] If the SCP provided an indication of "support of indirect communication with delegated discovery with NF selection at target domain feature", based on operator's policy and configuration, the NRF in the PLMN-1 may also determine without interaction with the NRF in the PLMN-2 that indirect communication with delegated discovery with NF selection at target domain is requested for that remote PLMN, and the interaction with the NRF in PLMN-2 and step 3 does not apply. The NRF in PLMN-1 may then provide a configured address of an SCP in PLMN2 in the NnrfNFDiscovery service response (step 4).

[0047] 4. The NRF in PLMN-1 sends an Nnrf NFDiscovery service response with parameters as described in step 3 to the SCP in PLMN-1. The SCP may cache the response.

[0048] Steps 5 and 6 apply if steps 2 to 4 were not executed or the Nnrf NFDiscovery service response in step 4 contained NF profiles and no indication that "indirect communication with delegated discovery with NF selection at target domain is requested" and no indication that "indirect communication without delegated discovery with NF selection at target domain is requested".

[0049] 5. If a NF instance was not selected by the NF consumer, SCP in PLMN-1 selects a NF service producer instance in PLMN-2. Otherwise if this is allowed by binding information, the SCP in PLMN-1 may also select a NF service producer instance in PLMN-2

[0050] 6. SCP in PLMN-1 forwards the request to the selected NF service producer instance in PLMN-2.

[0051] Steps 7 to 10 apply if the Nnrf NFDiscovery service response in step 4 contained the indication that "indirect communication with delegated discovery with NF selection at target domain is requested" and / or the indication that "indirect communication without delegated discovery with NF selection at target domain is requested".

[0052] 7. If an indication that "indirect communication without delegated discovery with NF selection at target domain is requested" was received but an NF instance or NF set was not yet selected (because the NF consumer applied model D) the SCP may select an NF producer instance or a NF set (where the SCP in target network need to do the NF instance selection).

[0053] If an indication that "indirect communication with delegated discovery with NF selection at target domain is requested" and / or the indication that "indirect communication without delegated discovery with NF selection at target domain is requested" was received, SCP in PLMN-1 forwards the request with discovery and selection parameters to PLMN-2.

[0054] 8. Unless the SCP in PLMN-2 has appropriate cached information, it interacts with NRF in PLMN-2 using the NnrfNFDiscovery service. Candidate NF profiles are returned.

[0055] 9. If a NF instance was not selected, SCP in PLMN-2 selects a NF service producer instance in PLMN-2. Otherwise if this is allowed by binding information, the SCP in PLMN-2 may also reselect a NF service producer instance.

[0056] 10. SCP in PLMN-2 forwards the request to the selected NF service producer instance in PLMN-2.

[0057] Several definitions are included within TS 29.500:

[0058] 5.2.3.2.4 3gpp- Sb i -T arget-apiRoot

[0059] The header contains the apiRoot of the target URI (clause 4.4 of 3GPP TS 29.501) in a request sent to an SCP when using Indirect Communication. This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when the SCP selected or reselected a new HTTP server to route the request (or when the SCP sends the request to an alternative HTTP Server upon receiving a 3xx redirect message, see clause 6.10.9.1) and no Location HTTP header is included in the HTTP response. It may also be used in a request sent to a SEPP and in a request between SEPPs (see clause 6.1.4.3.2).

[0060] The encoding of the header follows the ABNF as defined in IETF RFC 9110. Sbi-Target-apiRoot-Header = "3gpp-Sbi-Target-apiRoot" OWS sbi-scheme sbi-authority [ prefix ] OWS sbi-scheme = "http" / "https" sbi-authority = host [port ] port = *DIGIT prefix = path-absolute ; path-absolute production rule from IETF RFC 3986, clause 3.3 EXAMPLE: 3gpp-Sbi-Target-apiRoot: https: / / example.eom / a / b / c

[0061] 6.1.4.3.3 Use of 3gpp-Sbi-Target-apiRoot between NFs and SEPP within a PLMN

[0062] When using the 3gpp-Sbi-Target-apiRoot header between the SEPP and NFs within the SEPP's PLMN, HTTP requests between the NFs and the SEPP shall be routed as specified in clause 6.10.2 for indirect communications, with the SEPP taking the role of the SCP.

[0063] When sending an HTTP request targeting a URI with an authority of a remote PLMN, NFs shall include the 3gpp-Sbi-Target-apiRoot header in the HTTP request, containing the apiRoot of the target URI in the remote PLMN, and shall set the apiRoot in the request URI to the apiRoot of the SEPP (or to the apiRoot of the SCP if the communication between the NF and SEPP goes through an SCP). The apiRoot of the SEPP (or SCP) may include an optional deployment-specific string of the SEPP (or SCP).

[0064] An SCP that receives an HTTP request targeting a URI with an authority of a remote PLMN shall route the HTTP request towards the SEPP as specified in clause 6.10.2 for indirect communications, i.e. the SCP shall forward the 3gpp-Sbi-Target-apiRoot header in the HTTP request it forwards to the SEPP, containing the apiRoot of the target URI in the remote PLMN, and it shall set the apiRoot in the request URI to the apiRoot of the SEPP.

[0065] If the SEPP receives an HTTP request from a NF with a request URI containing a telescopic FQDN and with a 3gpp-Sbi-Target-apiRoot header, the SEPP shall ignore the 3gpp-Sbi-Target-apiRoot header and route the request using the telescopic FQDN.

[0066] This is to address the case of a potentially malicious or misbehaving NF that would include the 3gpp-Sbi-Target-apiRoot header and a request URI containing a telescopic FQDN when communicating with the SEPP.

[0067] This solution does not require the SEPP to support TLS wildcard certificate for its domain name, nor the SEPP to modify URI attributes in HTTP request and response contents with telescopic FQDNs.

[0068] The communication between the NF and SEPP can be direct or go through an SCP.

[0069] 6.10.2.4 Pseudo-header setting

[0070] For Indirect Communications with or without delegated discovery, when sending a request to the SCP, the HTTP client shall set the pseudo-headers as follows (1-3):

[0071] 1) ":scheme"set to "http" or "https";

[0072] 2) ":authority" set to the FQDN or IP address of the SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https");

[0073] 3) ":path" including the optional deployment-specific string of the SCP and the path and query components of the target URI excluding the optional deployment-specific string of the target URI.

[0074] An HTTP client which has not received information whether the callback URI contains any deployment specific string or not shall behave assuming that there is no deployment specific string in the callback (i.e. target) URI. If the HTTP client has previously received the prefix of the callback URI it shall include it, if available, in the 3gpp-Sbi-Target-apiRoot header (see clause 6.10. 2.5).

[0075] When an HTTP client sending a notification request corresponding to default notification subscription where the target URI is unknown (e.g. for Indirect Communication with Delegated Discovery, as specified in clause 6.10.3.3), it shall include the optional deployment-specific string of the SCP and the pseudo target URI for default subscription (" / scp-default-sub-notify-uri") in the ":path".

[0076] Additionally, for HTTP requests for which an HTTP client may cache responses (e g. GET request), the HTTP client should include the cache key (ck) query parameter set to an implementation specific value that is bound to the target NF (see clause 6.10.2.6).

[0077] The HTTP client shall include the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, in the 3gpp-Sbi-Target-apiRoot header (see clause 6.10. 2.5).

[0078] When forwarding a request to another SCP, an SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the next hop SCP. The SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource (including the optional deployment-specific string of the target URI), if available, e.g. if the 3gpp-Sbi-Target-apiRoot header was received in the request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions (a-d):

[0079] a) the SCP shall modify the "authority" HTTP / 2 pseudo-header field to the FQDN or IP address of the next hop SCP (if the scheme is "http"), or to the FQDN of the SCP (if the scheme is "https").

[0080] b) the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP / 2 pseudo-header and add any optional deployment-specific string of the next hop SCP;

[0081] c) the SCP shall remove the cache key query parameter, if this parameter was received in the request;

[0082] d) if the pseudo target URI for default subscription (" / scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.

[0083] When forwarding a request to the HTTP server, the SCP shall replace the apiRoot of the SCP received in the request URI of the incoming request by the apiRoot of the target NF service instance. If the 3gpp-Sbi-Target-apiRoot header was received in the request, the SCP shall use it as the apiRoot of the target NF service instance, if the SCP does not (re)select a different HTTP server, and regardless shall remove it from the forwarded request. The SCP shall set the pseudo-headers as specified in clause 6.1, with the following additions (a-d):

[0084] a) the SCP shall modify the "authority" HTTP / 2 pseudo-header field to the FQDN or IP address of the target NF service instance (if the scheme is "http"), or to the FQDN of the target NF service instance (if the scheme is "https").

[0085] b) the SCP shall remove any optional deployment-specific string of the SCP in the ":path" HTTP / 2 pseudo-header and add any optional deployment-specific string of the target URI;

[0086] c) the SCP shall remove the cache key query parameter, if this parameter was received in the request;

[0087] d) if the pseudo target URI for default subscription (" / scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registered in the selected default subscription.

[0088] EXAMPLE 1: For indirect communication without delegated discovery, if the NF Service Consumer needs to send the request "GET https: / / example.com / a / b / c / nudm-sdm / vl / {supi} / nssai" to the NF Service Producer (represented by the FQDN "example.com" and where " / a / b / c" is the "apiPrefix" of the NF service producer figured out from NRF discovery) (1-2):

[0089] 1) the NF service consumer shall send the request "GET https: / / scp.com / l / 2 / 3 / nudm- sdm / vl / {supi} / nssai" to the SCP (where " / 1 / 2 / 3" is the "apiPrefix" of the SCP), with the "3gpp-sbi-target-apiRoot" header set to "https: / / example.eom / a / b / c".

[0090] 2) the SCP shall send the request "GET https: / / example.com / a / b / c / nudm-sdm / vl / {supi} / nssai" to the NF Service Producer, without any "3gpp-sbi-target-apiRoot" header.

[0091] EXAMPLE 2: For indirect communication, if the NF Service Producer needs to send a notification request "POST https: / / example.eom / a / b / c / notification" to the NF Service Consumer (represented by the FQDN "example.com", i.e. the host part of the callback URI) (1-2):

[0092] 1) the NF service producer shall send the request "POST https: / / scp.eom / l / 2 / 3 / a / b / c / notification" to the SCP (where " / 1 / 2 / 3" is the "apiPrefix" of the SCP), with the "3gpp-sbi-target-apiRoot" header set to "https: / / example.com".

[0093] 2) the SCP shall send the request "POST https: / / example.eom / a / b / c / notification" to the NF Service Consumer, without any "3gpp-sbi-target-apiRoot" header.

[0094] EXAMPLES: For indirect communication with Delegated Discovery, if the NF Service Producer needs to send a notification request to a default subscription and SCP selects a target default notification subscription (with callback URI "https: / / example.eom / a / b / c / notification" registered) (1-2):

[0095] 1. the NF service producer shall send the request "POST https: / / scp.com / l / 2 / 3 / scp- default-sub-notify-uri" to the SCP (where " / 1 / 2 / 3" is the "apiPrefix" of the SCP).

[0096] 2. the SCP shall send the request "POST https: / / example.eom / a / b / c / notification" to the selected NF Service Consumer.

[0097] EXAMPLE 4: For indirect communication, if the NF Service Producer needs to send a notification request "POST https: / / example.eom / prefixl23 / a / b / c / notification" to the NF Service Consumer with a callback URI Prefix " / prefix 123" (1-2):

[0098] 1) the NF service producer shall send the request "POST https: / / scp.eom / l / 2 / 3 / a / b / c / notification" to the SCP (where '71 / 2 / 3" is the Prefix of the SCP), with the "3gpp-sbi-target-apiRoot" header set to "https: / / example.com / prefixl23".

[0099] 2) the SCP shall send the request "POST https: / / example.eom / prefixl23 / a / b / c / notification" to the NF Service Consumer, without any "3gpp-sbi-target-apiRoot" header.

[0100] 6.10.2.5 3gpp-Sbi-Target-apiRoot header setting

[0101] For Indirect Communications with or without delegated discovery, the HTTP client shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the SCP. In particular (1-3):

[0102] 1) for Indirect Communication without Delegated Discovery, a service request sent to the SCP to create a resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected NF service instance of the NF Service Producer, if the NF Service Consumer has indeed selected a specific NF service instance;

[0103] 2) after a resource has been created, subsequent service requests sent to the SCP and targeting the resource shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot received earlier in Location header of service responses from the NF Service Producer;

[0104] 3) notifications or callbacks sent via the SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the notification or callback URI (i.e. "http" or "https" 17 scheme, the fixed string and authority (host and optional port) as defined in IETF RFC 3986

[14] followed by the Callback URI prefix when available).

[0105] An SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular (1-3):

[0106] 1) if the received request does not include a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, and NF service discovery is not delegated to a next hop SCP, then the SCP shall select a target NF service instance (performing an NF service discovery with the NRF or based on local configuration (i.e. without interacting with NRF) according to the received "3gpp-Sbi-Discovery-*" request header(s)) and insert a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected target NF service instance;

[0107] 2) if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance, the SCP shall modify and set the 3gpp-Sbi-Target-apiRoot header to the apiRoot of the newly selected target NF service instance;

[0108] 3) if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance and the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP.

[0109] When forwarding the request to the HTTP server, the SCP shall set the pseudoheaders as specified in clause 6.10.2.4.

[0110] It is possible that the NF consumer in PLMN1 already selects a particular NF producer instance, for instance if it was informed in previous HTTP reply messages about the NF producer instance. According to existing procedures, if the NF consumer sends such an HTTP request to an SCP, the NF service consumer will indicate the producer instance in the authority part of the 3gpp-Sbi-Target-apiRoot header and provide the SCP in the authority part of the request URI. An SCP forwarding the HTTP request to another SCP2 will retain the 3gpp-Sbi-Target-apiRoot header and modify the Request URI to indicate the SCP2. An SCP sending the HTTP request to the NF service producer indicated in the 3gpp-Sbi-Target- apiRoot will update the request URI to include the indicated target API root. An SCP forwarding a request to a SEPP will include the SEPP in the authority part of the request URI.

[0111] According to the agreed procedures for delegated NF service discovery when NF service consumer and NF service producer are in different PLMNs with possible NF selection at target PLMN, the SCP in PLMN1 can obtain information about the SCP in PLMN2 from an NRF. However, it is unclear how to route a service request from the SCP in PLMN1 towards the SCP in the PLMN2 via the SEPP of PLMN1 and the SEPP of PLMN2, since no routing mechanisms exist to support such routing. In other words, it is unclear, how the SCP in PLMN1 can handle the information about that SCP in PLMN2. The SCP in PLMN1 will need to send the request to a SEPP.

[0112] FIG 4 is an example call flow diagram for transmission of an HTTP request, based on the examples described herein, including steps 1-5.

[0113] Referring to FIG. 4, an SCP-1 409 in the source PLMN 408 obtains information about an applicable SCP-2 414 in a target PLMN 410 from an NRF when querying for NF producers (such as NF service producer 416) in the target PLMN 410 and caches this information. At 401, when the SCP-1 409 receives an HTTP request for the target PLMN 410 (and possibly the cached NF type of the NF producer) that indicates an NF producer instance 416 or obtains a request and selects an NF producer instance 416, the SCP-1 409 at 402 sends the request to a SEPP 406 and indicates the applicable target SCP-2 414 in a new or extended HTTP header (such as new or extended header “3gpp-Sbi-SCP-apiRoot” 420). At 403, the SEPP 406 in PLMN1 408 forwards the request to a SEPP 412 in target PLMN2 410. The SEPP 412 in target PLMN2 410 extracts the information about the target SCP-2 414 from the new or extended HTTP header, removes the new HTTP header or the extended information from the HTTP header, and at 404 sends the request to the SCP2 414. The same mechanism can be used to route the HTTP request from the SCP1 409 to the SCP2 414 via the SEPP 406 in PLMN1 and the SEPP 412 in PLMN2 when no NF producer instance 416 has been selected or obtained by the NF service consumer or the SCP1 409.

[0114] As shown in FIG. 4, the HTTP request is transmitted at 401 by NF service consumer 407 to the SCP-1 409. At 405, the SCP-2 transmits the HTTP request to the NF service producer 416. In an embodiment, an SCP implements the functionality of SEPP-2 412 (the actions of SEPP 412 are performed by an SCP and not a SEPP).

[0115] In one embodiment (as shown in FIG. 4), a new “3gpp-Sbi-SCP-apiRoot” header 420 is introduced as shown below: Sbi-Scp-apiRoot-Header = "3gpp-Sbi-Scp-apiRoot" OWS sbi-scheme sbi-authority [ prefix ] OW S sbi-scheme = "http" / "https" sbi-authority = host [port ] port = *DIGIT prefix = path-absolute ; path-absolute production rule from IETF RFC 3986, clause 3.3 EXAMPLE: 3gpp-Sbi-Target-apiRoot: https: / / examplescp.eom / a / b / c

[0116] In another embodiment, the Sbi-Target-apiRoot-Header is extended or a new header is introduced that can carry both information about and SCP and an NF service producer instance. In one embodiment, the SCP is identified by the order of the entries, e.g. the SCP coming before the NF service producer.

[0117] In one variant the SCP-1 obtains information about multiple SCP-2 for a PLMN-2 and possible target NF produced type from the NRF, caches this information, and provides the multiple candidate SCP-2 in the HTTP header in the HTTP request it forwards. The SEPP-2 then selects the SCP-2 about of the received candidate SCP-2s and forwards the HTTP request to the selected SCP-2.

[0118] In another variant, when the SCP-1 receives an HTTP request for a target PLMN and has no cached information about a suitable SCP-2, the SCP-1 queries the NRF even if the HTTP request already indicates an NF producer instance.

[0119] The examples described herein can also be applied if SEPPs are deployed between different regions of a PLMN; then regions take the place of PLMNs in the description above.

[0120] The examples described herein may be implemented within SCP and SEPP network entities and / or devices that implement the herein described signaling.

[0121] Thus, based on the examples described herein, the 3gpp-Sbi-Scp-apiRoot header is used by an SCP in a source PLMN to indicate the apiRoot of an SCP in a target PLMN when using indirect communication with or without delegated discovery between different PLMNs 20 with possible NF selection at target PL MN.

[0122] The 3gpp-Sbi-Scp-apiRoot header contains the apiRoot of an SCP in the target PLMN (see clause 4.4 of 3GPP TS 29.50) in a request sent from a source PLMN to a target PLMN when using indirect communication with or without delegated discovery between different PLMNs with possible NF selection at target PLMN and the apiRoot of the SCP in the target PLMN is known by the source PLMN (see clause 6.10.x).

[0123] The encoding of the header follows the ABNF as defined in IETF RFC 9110. Sbi-Scp-ApiRoot-Header = "3gpp-Sbi-Scp-apiRoot" OWS sbi-scheme sbi-authority [ prefix ] OWS

[0124] The ABNF of sbi-scheme, sbi-authority and prefix is defined in clause 5.2.3.2.4. EXAMPLE: 3gpp-Sbi-Scp-apiRoot: https: / / scpl2.operator.eom / a / b / c

[0125] 1 Routing mechanisms

[0126] 1.1 General

[0127] 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

[0128] 1.2 Routing within the source PLMN

[0129] 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.

[0130] Service requests shall be routed between the SCP and the SEPP within the source PLMN (1-2):

[0131] 1) 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); additionally, 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;

[0132] 2) 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.

[0133] 1.3 Routing between SEPPs

[0134] 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.

[0135] 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 (1 or 2):

[0136] 1) if PRINS security is negotiated between the SEPPs, the service request shall be routed as specified in clause 6.1.4.3.4. Additionally (a-b): a) the cSEPP shall set the apiRoot of the Request URI of the encapsulated protected message to the apiRoot of the pSEPP; and b) the cSEPP shall forward the 3gpp-Sbi-Scp-apiRoot header in the encapsulated protected message, if this header was received in the incoming request.

[0137] 2) 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.

[0138] In either case (1) or (2) of 1.3 above, the pSEPP receives the service request from the cSEPP with the apiRoot of the Request URI set to the apiRoot of the pSEPP.

[0139] 1A Routing within the target PLMN

[0140] 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.

[0141] 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.

[0142] 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).

[0143] FIG. 5 is an example apparatus 500, which may be implemented in hardware, configured to implement the examples described herein. The apparatus 500 comprises at least one processor 502 (e.g. an FPGA and / or CPU), one or more memories 504 including computer program code 505, the computer program code 505 having instructions to carry out the methods described herein, wherein the at least one memory 504 and the computer program code 505 are configured to, with the at least one processor 502, cause the apparatus 500 to implement circuitry, a process, component, module, or function (implemented with control module 506) to implement the examples described herein. The one or more memories 504 may include a non-transitory memory, a transitory memory, a volatile memory (e.g. RAM), or a non-volatile memory (e.g. ROM).

[0144] SCP targeting 530 implements the examples described herein related to targeting a specific SCP for indirect communication.

[0145] The apparatus 500 includes a display and / or I / O interface 508, which includes user interface (UI) circuitry and elements, that may be used to display aspects or a status of the methods described herein (e.g., as one of the methods is being performed or at a subsequent time), or to receive input from a user such as with using a keypad, camera, touchscreen, touch area, microphone, biometric recognition, one or more sensors, etc. The apparatus 500 includes one or more communication e.g. network (N / W) interfaces (I / F(s)) 510. The communication I / F(s) 510 may be wired and / or wireless and communicate over the Intemet / other network(s) via any communication technique including via one or more links 524. The link(s) 524 may be the link(s) 131 and / or 176 from FIG. 1. The link(s) 131 and / or 176 from FIG. 1 may also be implemented using transceiver(s) 516 and corresponding wireless link(s) 526. The communication I / F(s) 510 may comprise one or more transmitters or one or more receivers.

[0146] The transceiver 516 comprises one or more transmitters 518 and one or more receivers 520. The transceiver 516 and / or communication I / F(s) 510 may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de)modulator, and encoder / decoder circuitries and one or more antennas, such as antennas 514 used for communication over wireless link 526.

[0147] The control module 506 of the apparatus 500 comprises one of or both parts 506-1 and / or 506-2, which may be implemented in a number of ways. The control module 506 may be implemented in hardware as control module 506-1, such as being implemented as part of the one or more processors 502. The control module 506-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module 506 may be implemented as control module 506-2, which is implemented as computer program code (having corresponding instructions) 505 and is executed by the one or more processors 502. For instance, the one or more memories 504 store instructions that, when executed by the one or more processors 502, cause the apparatus 500 to perform one or more of the operations as described herein. Furthermore, the one or more processors 502, the one or more memories 504, and example algorithms (e.g., as flowcharts and / or signaling diagrams), encoded as instructions, programs, or code, are means for causing performance of the operations described herein.

[0148] The apparatus 500 to implement the functionality of control 506 may be UE 110, RAN node 170 (e.g. gNB), or network element(s) 190 (e.g. LMF 190). Thus, processor 502 may correspond to processor(s) 120, processor(s) 152 and / or processor(s) 175, memory 504 may correspond to one or more memories 125, one or more memories 155 and / or one or more memories 171, computer program code 505 may correspond to computer program code 123, computer program code 153, and / or computer program code 173, control module 506 may correspond to module 140-1, module 140-2, module 150-1, and / or module 150-2, and communication I / F(s) 510 and / or transceiver 516 may correspond to transceiver 130, antenna(s) 128, transceiver 160, antenna(s) 158, N / W I / F(s) 161, and / or N / W I / F(s) 180. Alternatively, apparatus 500 and its elements may not correspond to either of UE 110, RAN node 170, or network element(s) 190 and their respective elements, as apparatus 500 may be part of a self-organizing / optimizing network (SON) node or other node, such as a node in a cloud.

[0149] Apparatus 500 may correspond to any of the other apparatuses described herein, including NF service consumer 407, SCP-1 409, SEPP-1 406, SEPP-2 412, SCP-2 414, and NF service producer 416.

[0150] The apparatus 500 may also be distributed throughout the network (e.g. 100) including within and between apparatus 500 and any network element (such as a network control element (NCE) 190 and / or the RAN node 170 and / or UE 110).

[0151] Interface 512 enables data communication and signaling between the various items of apparatus 500, as shown in FIG. 5. For example, the interface 512 may be one or more buses such as address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. Computer program code (e.g. instructions) 505, including control 506 may comprise object-oriented software configured to pass data or messages between objects within computer program code 505, or computer program code (e.g. instructions) 505, including control 506 may include functional, scripting, or procedural code. The apparatus 500 need not comprise each of the features mentioned, or may comprise other features as well. The various components of apparatus 500 may at least partially reside in a common housing 528, or a subset of the various components of apparatus 500 may at least partially be located in different housings, which different housings may include housing 528.

[0152] FIG. 6 shows a schematic representation of non-volatile memory media 600a (e.g. computer / compact disc (CD) or digital versatile disc (DVD)) and 600b (e.g. universal serial bus (USB) memory stick) and 600c (e.g. cloud storage for downloading instructions and / or parameters 602 or receiving emailed instructions and / or parameters 602) storing instructions and / or parameters 602 which when executed by a processor allows the processor to perform one or more of the steps of the methods described herein. Instructions and / or parameters 602 may represent a computer readable medium.

[0153] FIG 7 is an example method 700 based on the examples described herein. At 710, the method includes receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network. At 720, the method includes determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy. At 730, the method includes transmitting the hypertext transfer protocol request to a security edge protection proxy. At 730, the method includes wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header. Method 700 may be performed with SCP 304 in PLMN-1 308, SCP-1 409 in PLMN-1 408, or apparatus 500.

[0154] FIG. 8 is an example method 800 based on the examples described herein. At 810, the method includes receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request. At 820, the method includes wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header. At 830, the method includes extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header. At 840, the method includes transmitting, to the target service communication proxy, the hypertext transfer protocol request. Method 800 may be performed with SEPP-2 412, a network entity such as an SCP in PLMN-2 310, a network entity such as an SCP in PLMN-2 410, or apparatus 500.

[0155] The following examples are provided and described herein.

[0156] Example 1. An apparatus including: means for receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network; means for determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; and means for transmitting the hypertext transfer protocol request to a security edge protection proxy; wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

[0157] Example 2. The apparatus of example 1, further including: means for obtaining a network function service producer instance in the target public land mobile network based on the hypertext transfer protocol request for the target public land mobile network.

[0158] Example 3. The apparatus of example 2, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises the network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

[0159] Example 4. The apparatus of any of examples 2 to 3, wherein the new second hypertext transfer protocol header and the extension of the first hypertext transfer protocol header comprise information about the network function service producer instance.

[0160] Example 5. The apparatus of any of examples 2 to 4, wherein the apparatus is further caused to: configure the target second service communication proxy and the network function service producer instance within the hypertext transfer protocol request transmitted to the security edge protection proxy, based on an order of the target second service communication proxy and the network function service producer instance within the hypertext transfer protocol request transmitted to the security edge protection proxy.

[0161] Example 6. The apparatus of example 5, wherein the order comprises the target second service communication proxy being before the network function service producer instance.

[0162] Example 7. The apparatus of any of examples 1 to 6, further including: means for caching a network function type of a network function service producer instance in the target public land mobile network; wherein the hypertext transfer protocol request for the target public land mobile network received in the first service communication proxy comprises the network function type of the network function service producer instance; wherein the target second service communication proxy of the target public land mobile network is determined based on the cached network function type of the network function service producer instance.

[0163] Example 8. The apparatus of any of examples 1 to 7, further including: means for querying a network repository function to determine the target second service communication proxy of the target public land mobile network.

[0164] Example 9. The apparatus of any of examples 1 to 8, further including: means for determining an address of the target second service communication proxy of the target public land mobile network from a network repository function from the source public land mobile network.

[0165] Example 10. The apparatus of any of examples 1 to 9, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises the indication of the target second service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

[0166] Example 11. The apparatus of any of examples 1 to 10, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises the indication of the target second service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

[0167] Example 12. The apparatus of any of examples 1 to 11, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an address of the target second service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

[0168] Example 13. The apparatus of any of examples 1 to 12, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an address of the target second service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

[0169] Example 14. The apparatus of any of examples 1 to 13, wherein the extension of the first hypertext transfer protocol header and the new second hypertext transfer protocol header indicate an application programming interface root of the target second service communication proxy of the target public land mobile network.

[0170] Example 15. The apparatus of any of examples 1 to 14, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises multiple target service communication proxies of the target public land mobile network in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header.

[0171] Example 16. An apparatus including: means for receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request; wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header; means for extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; and means for transmitting, to the target service communication proxy, the hypertext transfer protocol request.

[0172] Example 17. The apparatus of example 16, further including: means for removing, from the hypertext transfer protocol request, the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

[0173] Example 18. The apparatus of any of examples 16 to 17, wherein: the hypertext transfer protocol request received from the security edge protection proxy of the source public land mobile network comprises a network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header, and the hypertext transfer protocol request transmitted to the target service communication proxy comprises information about the network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

[0174] Example 19. The apparatus of example 18, further including: means for identifying the target service communication proxy and the network function service producer instance based on an order of the target service communication proxy and the network function service 29 producer instance within the hypertext transfer protocol request.

[0175] Example 20. The apparatus of example 19, wherein the order comprises the target service communication proxy being before the network function service producer instance.

[0176] Example 21. The apparatus of any of examples 16 to 20, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises the indication of the target service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

[0177] Example 22. The apparatus of any of examples 16 to 21, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

[0178] Example 23. The apparatus of any of examples 16 to 22, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises an address of the target service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

[0179] Example 24. The apparatus of any of examples 16 to 23, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises an address of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

[0180] Example 25. The apparatus of any of examples 16 to 25, wherein the extension of the first hypertext transfer protocol header and the new second hypertext transfer protocol header indicate an application programming interface root of the target service communication proxy of the target public land mobile network.

[0181] Example 26. The apparatus of any of examples 16 to 25, further including: means for selecting the target service communication proxy among multiple target service communication proxies of the target public land mobile network that are indicated in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header; wherein the hypertext transfer protocol request received from the security edge protection proxy of the source public land mobile network comprises the multiple target service communication proxies of the target public land mobile network in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header.

[0182] Example 27. The apparatus of any of examples 16 to 26, wherein: the network entity of the target public land mobile network that receives the hypertext transfer protocol request from the security edge protection proxy of the source public land mobile network comprises another security edge protection proxy, the hypertext transfer protocol request received with the another security edge protection proxy comprising the indication of target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is transmitted from the another security edge protection proxy to the target service communication proxy of the target public land mobile network, and the apparatus comprises the another security edge protection proxy, or the another security edge protection proxy comprises the apparatus.

[0183] Example 28. The apparatus of any of examples 16 to 27, wherein: the network entity of the target public land mobile network that receives the hypertext transfer protocol request from the security edge protection proxy of the source public land mobile network comprises another service communication proxy, the hypertext transfer protocol request received with the another service communication proxy comprising the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is transmitted from the another service communication proxy to the target service communication proxy of the target public land mobile network, and the apparatus comprises the another service communication proxy, or the another service communication proxy comprises the apparatus.

[0184] Example 29. The apparatus of any of examples 16 to 28, wherein the hypertext transfer protocol request comprising the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is for a service of the target public land mobile network.

[0185] Example 30. A method including: receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network; determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; and transmitting the hypertext transfer protocol request to a security edge protection proxy; wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

[0186] Example 31. A method including: receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request; wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header; extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; and transmitting, to the target service communication proxy, the hypertext transfer protocol request.

[0187] Example 32. An apparatus including: means for receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network; means for determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; and means for transmitting the hypertext transfer protocol request to a security edge protection proxy; wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

[0188] Example 33. An apparatus including: means for receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request; wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target 32 public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header; means for extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; and means for transmitting, to the target service communication proxy, the hypertext transfer protocol request.

[0189] Example 34. A computer readable medium including instructions stored thereon for performing at least the following: receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network; determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; and transmitting the hypertext transfer protocol request to a security edge protection proxy; wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

[0190] Example 35. A computer readable medium including instructions stored thereon for performing at least the following: receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request; wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header; extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; and transmitting, to the target service communication proxy, the hypertext transfer protocol request.

[0191] References to a ‘computer’, ‘processor’, etc. should be understood to encompass not only computers having different architectures such as single / multi-processor architectures and sequential or parallel architectures but also specialized circuits such as field-programmable gate arrays (FPGAs), application specific circuits (ASICs), signal processing devices and other processing circuitry. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware 33 such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed-function device, gate array or programmable logic device etc.

[0192] The memories as described herein may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, non-transitory memory, transitory memory, fixed memory and removable memory. The memories may comprise a database for storing data.

[0193] The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0194] As used herein, the term ‘circuitry’ may refer to the following: (a) hardware circuit implementations, such as implementations in analog and / or digital circuitry, and (b) combinations of circuits and software (and / or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s) / software including digital signal processor(s), software, and memories that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. As a further example, as used herein, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

[0195] It should be understood that the foregoing description is only illustrative. Various alternatives and modifications may be devised by those skilled in the art. For example, features recited in the various dependent claims could be combined with each other in any suitable combination(s). In addition, features from different example embodiments described above could be selectively combined into a new example embodiment. Accordingly, this description is intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.

[0196] The following acronyms and abbreviations that may be found in the specification and / or the drawing figures are given as follows (the abbreviations and acronyms may be appended / combined with each other or with other characters using e.g. a dash, hyphen, slash, letter, or number, and may be case insensitive): 5 3 GPP third generation partnership project 3 XX category of status codes in the Hypertext Transfer Protocol (HTTP) that indicate redirection 4G fourth generation 5G fifth generation 10 5G core network ABNF augmented Backus-Naur form AF application function AMF access and mobility management function API application programming interface 15 ASIC application-specific integrated circuit AUSF authentication server function CD compact / computer disc CHF charging function ck cache key 20 CPU central processing unit cSEPP consumer’s SEPP cu central unit or centralized unit DSP digital signal processor DU distributed unit 25 DVD digital versatile disc eNB evolved Node B (e.g., an LTE base station) EN-DC E-UTRAN new radio - dual connectivity en-gNB node providing NR user plane and control plane protocol terminations towards the UE, and acting as a secondary node in EN- 30 E-UTRA DC evolved UMTS terrestrial radio access, i.e., the LTE radio access technology E-UTRAN E-UTRA network Fl interface between the CU and the DU FPGA field-programmable gate array FQDN fully qualified domain name GMLC gateway mobile location center 5 gNB base station for 5G / NR, i.e., a node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC HPLMN home public land mobile network HTTP hypertext transfer protocol 10 https hypertext transfer protocol secure IAB integrated access and backhaul ID identifier IETF Internet Engineering Task Force I / F interface 15 I / O input / output IP internet protocol LMF location management function LTE long term evolution (4G) MAC medium access control 20 MME mobility management entity MRO mobility robustness optimization N indication of a service-based interface (e.g. Nnrf is the service based interface for a network repository function (nrf)) N27 reference point between NRF in the visited network and the NRF in 25 the home network N32-f forwarding interface between the SEPPs NCE network control element NEF network exposure function NF network function 30 NFc network function service consumer NFp network function service producer ng or NG new generation ng-eNB new generation eNB NG-RAN new generation radio access network NPN non-public network NR new radio NRF network repository function nssai network slice selection assistance information 5 N / W network ows optional white space PCF policy control function PDA personal digital assistant PDCP packet data convergence protocol 10 PHY physical layer PLMN public land mobile network PRINS protocol for N32 interconnect security pSEPP producer’s SEPP RAM random access memory 15 RAN radio access network Rei release RFC request for comments RLC radio link control ROM read-only memory 20 RRC radio resource control RU radio unit Rx receive, or receiver, or reception SA system aspects SBA service based architecture 25 Sbi service based interface SCP service communication proxy SDAP service data adaptation protocol sei selection SEPP security edge protection proxy 30 serv prod service producer SGW serving gateway SMF session management function SON self-organizing / optimizing network SNPN standalone non-public network SUPI TEI 19 subscription permanent identifier Small Technical Enhancements and Improvements TLS transport layer security tPLMN target PLMN 5 TRP transmission and reception point TS technical specification Tx transmit, or transmitter, or transmission UAV unmanned aerial vehicle UDM unified data management 10 UDR unified data repository UE user equipment (e.g., a wireless, typically mobile device) UI user interface UMTS Universal Mobile Telecommunications System UPF user plane function 15 URI uniform resource identifier USB universal serial bus UTRAN UMTS terrestrial radio access network VPLMN visited public land mobile network WID work item description 20 X2 network interface between RAN nodes and between RAN and the core network Xn network interface between NG-RAN nodes

Claims

What is claimed is:

1. An apparatus comprising:means for receiving, in a first service communication proxy of a source public land mobile network, a hypertext transfer protocol request for a service of a target public land mobile network;means for determining a target second service communication proxy of the target public land mobile network, wherein the hypertext transfer protocol request is to be routed to the target second service communication proxy; andmeans for transmitting the hypertext transfer protocol request to a security edge protection proxy;wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an indication of the target second service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header.

2. The apparatus of claim 1, further comprising:means for obtaining a network function service producer instance in the target public land mobile network based on the hypertext transfer protocol request for the target public land mobile network.

3. The apparatus of claim 2, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises the network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

4. The apparatus of claim 2, wherein the new second hypertext transfer protocol header and the extension of the first hypertext transfer protocol header comprise information about the network function service producer instance.

5. The apparatus of claim 2, wherein the apparatus is further caused to:configure the target second service communication proxy and the network function service producer instance within the hypertext transfer protocol request transmitted to the security edge protection proxy, based on an order of the target second service communication proxy and the network function service producer instance within the hypertext transfer protocol request transmitted to the security edge protection proxy.

6. The apparatus of claim 5, wherein the order comprises the target second service communication proxy being before the network function service producer instance.

7. The apparatus of claim 1 or 2, further comprising:means for caching a network function type of a network function service producer instance in the target public land mobile network;wherein the hypertext transfer protocol request for the target public land mobile network received in the first service communication proxy comprises the network function type of the network function service producer instance;wherein the target second service communication proxy of the target public land mobile network is determined based on the cached network function type of the network function service producer instance.

8. The apparatus of clam 1 or 2, further comprising:means for querying a network repository function to determine the target second service communication proxy of the target public land mobile network.

9. The apparatus of claim 1, further comprising:means for determining an address of the target second service communication proxy of the target public land mobile network from a network repository function from the source public land mobile network.

10. The apparatus of claim 1, wherein the hypertext transfer protocol requesttransmitted to the security edge protection proxy comprises the indication of the target second service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

11. The apparatus of claim 1, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises the indication of the target second service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

12. The apparatus of claim 1, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an address of the target second service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

13. The apparatus of claim 1, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises an address of the target second service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

14. The apparatus of claim 1, wherein the extension of the first hypertext transfer protocol header and the new second hypertext transfer protocol header indicate an application programming interface root of the target second service communication proxy of the target public land mobile network.

15. The apparatus of claim 1, wherein the hypertext transfer protocol request transmitted to the security edge protection proxy comprises multiple target service communication proxies of the target public land mobile network in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header.

16. An apparatus comprising:means for receiving, in a network entity of a target public land mobile network from a security edge protection proxy of a source public land mobile network, a hypertext transfer protocol request;wherein the hypertext transfer protocol request comprises an indication of a target service communication proxy of the target public land mobile network in: an extension of a first hypertext transfer protocol header, or a new second hypertext transfer protocol header;means for extracting information about the target service communication proxy from the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header; andmeans for transmitting, to the target service communication proxy, the hypertext transfer protocol request.

17. The apparatus of claim 16, further comprising:means for removing, from the hypertext transfer protocol request, the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

18. The apparatus of claim 16, wherein:the hypertext transfer protocol request received from the security edge protection proxy of the source public land mobile network comprises a network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header, andthe hypertext transfer protocol request transmitted to the target service communication proxy comprises information about the network function service producer instance within the first hypertext transfer protocol header or the new second hypertext transfer protocol header.

19. The apparatus of claim 18, further comprising:means for identifying the target service communication proxy and the network function service producer instance based on an order of the target service communication proxy and the network function service producer instance within the hypertext transfer protocol request.

20. The apparatus of claim 19, wherein the order comprises the target service communication proxy being before the network function service producer instance.

21. The apparatus of claim 16, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises the indication of the target service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

22. The apparatus of claim 16, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

23. The apparatus of claim 16, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises an address of the target service communication proxy of the target public land mobile network in the new second hypertext transfer protocol header.

24. The apparatus of claim 16, wherein the hypertext transfer protocol request received from the security edge protection proxy comprises an address of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header.

25. The apparatus of claim 16, wherein the extension of the first hypertext transfer protocol header and the new second hypertext transfer protocol header indicate an application programming interface root of the target service communication proxy of the target public land mobile network.

26. The apparatus of claim 16, further comprising:means for selecting the target service communication proxy among multiple target service communication proxies of the target public land mobile network that are indicated in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header;wherein the hypertext transfer protocol request received from the security edgeprotection proxy of the source public land mobile network comprises the multiple target service communication proxies of the target public land mobile network in: the extension of the first hypertext transfer protocol header, or the new second hypertext transfer protocol header.

27. The apparatus of claim 16, wherein:the network entity of the target public land mobile network that receives the hypertext transfer protocol request from the security edge protection proxy of the source public land mobile network comprises another security edge protection proxy,the hypertext transfer protocol request received with the another security edge protection proxy comprising the indication of target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is transmitted from the another security edge protection proxy to the target service communication proxy of the target public land mobile network, andthe apparatus comprises the another security edge protection proxy, or the another security edge protection proxy comprises the apparatus.

28. The apparatus of claim 16, wherein:the network entity of the target public land mobile network that receives the hypertext transfer protocol request from the security edge protection proxy of the source public land mobile network comprises another service communication proxy,the hypertext transfer protocol request received with the another service communication proxy comprising the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is transmitted from the another service communication proxy to the target service communication proxy of the target public land mobile network, andthe apparatus comprises the another service communication proxy, or the another service communication proxy comprises the apparatus.

29. The apparatus of claim 16, wherein the hypertext transfer protocol request comprising the indication of the target service communication proxy of the target public land mobile network in the extension of the first hypertext transfer protocol header or the new second hypertext transfer protocol header is for a service of the target public 5 land mobile network.

Images