Patent Description:
The <NUM> architecture may implement a so-called Service-Based Architecture (SBA) for the core network. In this new architecture, a number of the interfaces within the core network (including roaming interfaces) are to be changed from the legacy telecom style interfaces to modern, web-based application interfaces (APIs). The service based architecture (SBA) allows a Network Function (NF) to expose one or more NF services as a NF service producer to other NFs within the 5GC network as NF service consumers through service based interfaces.

There are several alternatives available for the development and implementation of such an SBA architecture. One possible model is referred to as the Representational State Transfer (REST) architectural model. In this model, the different entities (services, network functions, etc.) in the <NUM> system may interact with each other by invoking actions on a so-called "resource", which is identified in Hypertext Transfer Protocol (HTTP) by a Uniform Resource Identifier (URI).

Then, the different actions to be invoked in the different system entities may be defined by the different HTTP standard commands (e.g., GET, POST, PUT, DELETE, etc.. ), while the HTTP messages may convey representations of the affected resources in the HTTP payload. These representations can be formatted in different data-encoding languages (e.g. JSON).

Unless the information regarding NF service providers is locally configured on the corresponding NF service consumers, e.g. the expected NF service or NF is in the same Public Land Mobile Network (PLMN) as the requesting NF, the NF service consumers discover and select NF service producers dynamically using a Network Repository Function (NRF). The NRF may be a logical function that is used to maintain the NF profile of available instances of NF service producers and their supported services. The NRF may also be used to receive NF service Discovery Requests from NF service consumers, and provide the information of the available instances of corresponding NF service producers to the requesting NF service consumer.

In order to enable access to a requested NF type or NF service, the requester NF initiates the NF or NF service discovery by providing the type of the NF or the specific service that it is attempting to discover (e.g. SMF, PCF, UE location Reporting) and any other service parameters, for example, slicing related information, to the NRF to discover the target NF. The detailed service parameter(s) used for specific NF discovery refer to the related NF discovery and selection clause.

Depending on the chosen message routing model, the NRF may provide the IP address or the FQDN or the identifier of relevant services and/or NF instance(s) to the requester NF for the target NF instance selection. Based on that identifying information, the requester NF may then select one specific NF instance or an NF instance that is able to provide a particular NF Service (e.g., an instance of the PCF that can provide Policy Authorization).

For roaming scenarios, in other words, where an NF in one PLMN is requesting services from an NF located in a different PLMN, communication between NFs of visited and home PLMNs is performed via SEPP (Security Edge Protection Proxy) nodes deployed in each PLMN. Two SEPPs of different PLMNs may communicate over an N32 reference point. The SEPP may be a non-transparent proxy, meaning that it may be directly addressed by the NFs. This is illustrated in <FIG>.

<FIG> illustrates an example of SBA in two PLMNs. The first PLMN <NUM>, which in this case is the visitor PLMN (VPLMN) comprises a number of network functions NFs. In this example the NFs illustrated are a Network Slice Selection Function (NSSF), a first Network Exposure Function (NEF), a NF Repository Function (NRF), a first Policy Control Function (PCF), an Application Function (AF), an Access and Mobility Management Function (AMF), a Session Management Function (SMF), and a User Plane Function (UPF). A User Equipment (UE) may then connect to this 5GC network via the Radio Access Network (RAN).

The second PLMN <NUM>, which in this case comprises the home PLMN (hPLMN), may comprises one or more NFs. In this example, the NFs illustrated comprise a Unified Data Management (UDM) function an Authentication Server Function (AUSF), a second NF Repository Function (NRF), a second PCF and a second NEF.

Each network function may discover other NFs by looking them up in the NRF of their PLMN.

In a roaming scenario, a requesting NF in a first PLMN (for example, the AMF in the VPLMN in <FIG>) that requires contact with a NF a different PLMN (for instance, the UDM in the HPLMN of <FIG>) may first executes a procedure to discover the location of the NF in the VPLMN.

For example, the requesting NF in the first PLMN may contact the NRF in the first PLMN to perform a lookup for the requested NF in the second PLMN. in other words, for the above example, the AMF in the VPLMN performs a lookup for the UDM in the first NRF of the VPLMN.

The NRF in the first PLMN <NUM> may then contact the NRF in the second PLMN <NUM> using the vSEPP in the first PLMN <NUM> and the hSEPP in the second PLMC <NUM> as proxies.

The NRF in the second PLMN <NUM> may then return the information relating to the requested NF, e.g. the UDM in the second PLMN, back to the NRF in the first PLMN through the hSEPP and vSEPP proxies in the first PLMN <NUM> and second PLMN <NUM>, respectively.

The NRF in the first PLMN <NUM> may then return the information to the requesting NF, e.g. the AMF in the first PLMN <NUM>.

Once the requesting NF, e.g. the AMF, in the first PLMN <NUM> learns the location of the requested NF, e.g. the UDM, in the second PLMN, it may execute the desired service of the requested NF in the second PLMN <NUM>.

For example, the requesting NF, e.g. the AMF, in the first PLMN <NUM> may contact the requested NF, e.g. the UDM, in the second PLMN using the vSEPP in the first PLMN <NUM> and the hSEPP in the second PLMN <NUM> as proxies.

The requested NF, e.g. the UDM, in the second PLMN may then execute the service and return a response to the requesting NF, e.g. the AMF, in the first PLMN <NUM> through the hSEPP and vSEPP proxies in the first and second PLMN <NUM>, respectively.

Due to network topology hiding the NRF in the first PLMN <NUM> may provide to the requesting NF the IP address or the Fully Qualified Domain Name (FQDN) of a proxy function(s), for example the hSEPP, instead of providing the IP address of FQDN of the target instance(s) of the NF service producer within the HPLMN, i.e. the UDM itself. This may thereby hide the topology of the location of the UDM. The proxy function, e.g. the hSEPP, may be transparent to the requesting NF. The proxy function may then itself discover the location of the target NF instance via the local NRF, and forward service requests to the target NF instance.

A Split-horizon Domain Name System (DNS) refers to a functionality which may be implemented in a DNS server in which the address resolution of hostnames depends on the source address of the requesting NF. Split-Horizon DNS may commonly be used to offer separated domain resolutions, for example, to provide a different domain resolution for internal corporate requesting NFs and the external requesting NFs such as those from the public Internet. In other words, the split-horizon DNS may offer services under different IP addresses internally and externally.

Service discovery and service requesting in roaming scenarios occurs by utilizing the SEPP proxies of all PLMNs involved. It may therefore be necessary to force the routing of service requests across PLMNs via the corresponding SEPPs in the first and second PLMNs.

Among other functions, the SEPP may also be required to provide topology hiding. This means that NFs from other PLMNs interacting with NFs in the first PLMN may not be able to address NFs within the first PLMN directly, but rather may address a proxy function which is hiding the topology of the NFs, such as for example the SEPP in the first PLMN. It will however be appreciated that topology hiding may be realized in proxy functions other than the SEPP.

It may also be required that NFs within the first PLMN are able to access NFs which are also within the first PLMN directly without any topology hiding.

To achieve this, the NRF may provide for the registration of NFs with different addressing depending on the location of the requesting NF accessing the registered NF. For example, the NRF may provide an address of the NF, for requesting NFs that are accessing from the within same PLMN, and may provide an address of a node providing the topology hiding (such as the SEPP), for requesting NFs accessing from a different PLMN.

This means that an NRF is required to support a split-horizon setup for provisioning different set of addresses and the logic to serve the right set depending on the requesting NF and it complicates the provisioning of the NRF as it requires more information to be provisioned.

This may also affect the NFs that register themselves with the NRF, as they are required to provision different addresses, and to comprise logic to indicate whether the session they are requesting constitutes roaming.

NF discovery across PLMNs has been considered, for example, in the<NPL>". In 3GPP TS <NUM>, V15. <NUM>, procedures for the <NUM> system are discussed.

Differences in DNS queries has also been discussed, for example, in the online article "Difference between iterative and recursive dns query", hftps://www. slash root. in/ difference-between-iterative-and-recursive-dns-query.

The <NPL>", describes issues with TLS and inter-PLMN routing, and compares possible solutions, and the 3GPP Release <NUM> standard TS <NUM>, version <NUM>. <NUM>, <NUM> discusses numbering, addressing and identification.

The invention is defined by independent claims <NUM>, <NUM> and <NUM>.

For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:.

The scope of the invention is defined by the independent claims.

Embodiments described herein relate to methods and apparatus for configuring a Service Based Architecture, SBA, of a first Public Land Mobile Network, PLMN, in for discovery of a Network Function, NF. In particular embodiments described herein allows for the NFs to be registered based on the Fully Qualifying Domain Names (FQDN) of the NFs, and a provisioning of the DNS service in the PLMN in a split horizon setup, binding the FQDN of each NF to both the NF addressing (for requests from the same PLMN) and the SEPP addressing (for requests from other PLMNs).

Examples not forming part of the claimed invention but being useful for understanding the invention introduce a NF Discovery Orchestration (NFDO) function that advantageously simplifies the orchestration of the NF discovery by configuring the NF with an FQDN to be used when registering the NF in the NRF, gathering the IP addressing information of the NF and the SEPP and using the IP addressing information to provision the DNS service in the PLMN with a split horizon setup. This means that each NF is not required to comprise logic to indicate whether the session they are requesting constitutes roaming, nor is each NF required to provide at least two different types of addressing information to the NRF.

The examples disclosed herein therefore enable transparent routing of the different NFs (including the NRF) for both non-roaming and roaming scenarios with the following advantages. Firstly, the individual NFs do not need to implement dedicated discovery and routing logic for the roaming scenarios. This means that the interaction with the NRF and SEPP occurs transparently to the NF in roaming scenarios. Furthermore, the NFs do not need to register with the NRF with a plurality of different addresses for the roaming and non-roaming scenarios to induce routing via SEPPs and/or to support topology hiding. The NRF does not need to support separated NF addressing provisioning and logic for roaming and non-roaming scenarios. The overall provisioning of the <NUM> Core NFs is simplified by using domain names, e.g. FQDNs, as opposed to using a potentially large (and dynamic over time) set of IP addresses. The overall provisioning of the <NUM> Core NFs is simplified even further using an NF Discovery Orchestration (NFDO) Function, which eliminates the problems associated to the one-time registration of a NF composed of a potentially large number of individual instances.

<FIG> illustrates the service based architecture of a Public Land Mobile Network (PLMN) according to not claimed examples described herein. An NF Discovery Orchestration (NFDO) function <NUM> provides orchestration of the NF discovery by orchestrating the registering of the NFs on the NRF <NUM> with the other network elements that are required for the proper realization of the NF discovery. The NFDO may be realized as a separate node as illustrated, which may be physical or virtualized, or may be part of a broader orchestration system, for instance, orchestrating the whole <NUM> core.

The NFDO scope may be that of a single PLMN, and may not require that other PLMNs have a NFDO for its proper operation.

The NFDO <NUM> in the PLMN may interact with a edge security node, for example a Security Edge Protection Proxy (hSEPP) <NUM>, in order to manage the SEPP address(es) of the external interface of the hSEPP <NUM> which communicates with other PLMNs. The NFDO <NUM> also communicates with the hNRF Proxy <NUM>, which comprises an optional proxy node that provides topology hiding of the NFs in the PLMN, in order to learn the NFs hidden by the proxy and the addresses of the proxy. The NFDO <NUM> may also communicate with the Domain Name System (hDNS) function <NUM>, in order to provision the FQDN and IP addresses of the NFs, considering the split-horizon setup. The NFDO may also communicate with the hNRF <NUM>, in order to register any NFs which are not configured to provide registration themselves. The NFDO may also communicate with the different NFs <NUM> in order to configure the details of the NF addressing and the registering of each NF in the hNRF <NUM>.

The network elements described above with relation to <FIG> may be physical, virtual, or a combination of both.

The NFDO provides a northbound interface (NBI) that may be in communication with other orchestration systems.

When an NF is deployed, the NFDO orchestrates the configuration of the entities that it interacts with. Within the overall orchestration flow for the deployment of a NF, the orchestration flow described in iError! No se encuentra el origen de la referencia. is executed. The steps illustrated in <FIG> may occur in the final steps of the NF deployment orchestration.

<FIG> illustrates a not claimed example of a process for registering NFs in the NRF according to some embodiments.

In step <NUM> the NFDO begins the configuration of the discovery for a NF.

In step <NUM>, the NFDO transmits an indication of a first domain name to be used by the NF. For example, the first domain name may comprise an Fully Qualified Domain Name (FQDN) to be used by the NF. In some examples, step <NUM> may further comprise the NFDO transmitting an indication of a second domain name associated with the NRF in the PLMN to the NF. For example, the second domain name may comprise an FQDN associated with the NRF.

In step <NUM> the NFDO may initiate registration of the NF in the Network Repository Function, NRF such that the NF is associated with the first domain name in the NRF. Depending on the NF capabilities, or the configuration set by the operator, the NF may register itself in the NRF. In this example, in step 304a the NFDO may transmit a registration request to the NF to instruct the NF to register the first domain name with the NRF. In this example, the NF may then register the first domain name with the NRF in step <NUM>.

In some examples, however, the NFDO may register the NF in the NRF directly in step 304b. In both examples, the NF is registered with one or more first domain names, which may comprise FQDNs, instead of IP addresses.

In step <NUM>, the NFDO determines the at least one NF Internet Protocol, IP, address of the NF. In some examples, the NF IP address may comprise virtual IP address (VIP) providing a single point of access, or a list of IP addresses. In some examples, the NFDO may know the IP addresses in advance or may transmit a first address request to the NF for the at least one NF IP address in step <NUM> and may receive the NF IP address from the NF in step <NUM>.

In step <NUM> the NFDO determines at least one edge security node (e.g. SEPP), IP address. For example, the NFDO may determine the IP address of the SEPP in step <NUM>. The at least one edge security node IP address may comprise a VIP providing a single point of access, or a list of IP addresses. The NFDO may already be aware of the at least one edge security node IP address in advance or may transmit a second address request to the edge security node (in this example the SEPP) for the at least one edge security node IP address in step <NUM> and may receive the at least one edge security node IP address in step <NUM>.

Optionally, if a topology hiding proxy is used, the NFDO may determine at least one IP address of the proxy (hNRFProxy), the FQDN of the proxy, and the NFs that the proxy is performing topology hiding for in step <NUM>. The NFDO may already be aware of this information or may transmit a request to the proxy for the information in step <NUM> and receive the information from the proxy in step <NUM>.

The NFDO may then determine in step <NUM> what data to provision to the DNS server serving the PLMN. For example, the NFDO may utilize the at least one NF IP address determined in step <NUM>, the at least one edge security node IP address determined in step <NUM>, and/or the proxy information determined in step <NUM> to configure DNS entries to be used for resolution by NFs within the same PLMN in step <NUM>, and DNS entries to be used for resolution by NFs from other PLMN in step <NUM>. This will be described in more detail with respect to <FIG> below.

In particular, the NFDO may therefore be configured to configure, in a domain name system, DNS, a first DNS entry associating a first domain name of the NF with at least one NF Internet Protocol, IP, address of the NF, and a second DNS entry associating the first domain name with at least one edge security node IP address of an edge security node in the first PLMN, wherein, the first DNS entry is for use in resolving requests for the NF which originate from within the first PLMN, and the second DNS entry is for use in resolving requests for the NF which originate from outside the first PLMN. In other words, the first DNS entry may be configured in step <NUM> and the second DNS entry may be configured in step <NUM>.

<FIG> illustrates the provisioning of the DNS server serving a first PLMN as it is configured by the NFDO as described above.

As illustrated in <FIG>, the DNS is configured such that there are at least two DNS entries for each NF. DNS entries <NUM> and <NUM> are configured for use in processing DNS requests that originate from outside of the first PLMN, for example, requests coming from NFs which are located in other PLMNs.

Conversely, DNS entries <NUM> and <NUM> are configured for use in processing DNS requests that originated from within the first PLMN, for example, requests originating from NFs within the same PLMN as the DNS.

It will be appreciated that the FQDNs illustrated in the example of <FIG> are illustrative.

For each NF in the first PLMN, the NFDO provides for DNS requests that originate from within the first PLMN, a first DNS entry <NUM> associating the first domain name of the NF with at least one NF IP address (VIP) or list of IP addresses that the NF is listening at, and are to be used by other NFs that are in the first PLMN. This corresponds to the DNS entry named nf<name>. 3gppnetwork. org in <FIG> and step <NUM> in <FIG>.

The NFDO also provides for DNS requests that originate from outside of the first PLMN of the DNS, a second DNS entry <NUM> associating the first domain name of the NF with the at least one edge security node IP address (VIP) or list of IP addresses of the SEPP or the, hNFProxy, the network element doing the topology hiding. This second DNS entry may be used by NFs in other PLMNs. This corresponds to the DNS entry named nf<name>. 3gppnetwork. org in <FIG> and step <NUM> in <FIG>.

For example, the NFDO also provides for DNS requests that originate from within the first PLMN which are for NFs which are not within the first PLMN, a third DNS entry <NUM> for each of the different PLMNs that the first PLMN communicates with. The third entry may comprise one DNS entry per PLMN and NF, in other words an entry indicating the PLMN for each requested NF outside the first PLMN. If using a proxy for topology hiding (hNFProxy), the proxy itself may be registered instead of the individual NFs it hides.

Alternatively, the third entry may comprise one entry per PLMN which uses wildcards (*) to match all the NFs in the PLMN to the request. In other words, any FDQN which has the structure comprising the wildcard, for example, *. 3gppnetwork. org would be mapped to the third entry for the PLMN outside of the first PLMN.

The third entries in the DNS are then associated with the at least one edge security node IP address.

The NFDO then further provides a fourth DNS entry <NUM> configured to delegate the domain name resolution to different PLMNs that the NFDO interacts with. This entry is beutilized where the request is received from a NF in a second PLMN, and the request is for a second NF in a third PLMN, where the DNS is part of the first PLMN. The fourth entries <NUM> may comprise one entry per PLMN and NF. If using a proxy for topology hiding (hNFProxy), the proxy itself may be registered instead of the individual NFs it hides. Alternatively, the fourth entries <NUM> may comprise one entry per PLMN, using wildcards (*) to match all the NFs in the PLMN. This corresponds to the entries named *. 3gppnetwork. org in <FIG>.

<FIG>illustrates a method, in a Domain Name System, DNS, in a first Public Land Mobile Network, PLMN, according to the invention.

In step <NUM>, the DNS receives an address request from a first Network Function, NF, for an Internet Protocol, IP, address associated with a domain name of a second NF.

In step <NUM>, the DNS determines whether the second NF is within the first PLMN.

In step <NUM>, based on the determination, the DNS generates an address response comprising an IP address associated with the second NF.

Step <NUM> is further based on whether the first NF is within the first PLMN.

According to the invention, responsive to the second NF and the first NF being within the first PLMN, step <NUM> comprises generating the address response comprising the IP address of the second NF. This feature is as described with respect to DNS entry <NUM> in <FIG>.

According to the invention, responsive to the second NF being within the first PLMN, and the first NF not being within the first PLMN; step <NUM> comprises generating the address response comprising the IP address of a first edge security node of the first PLMN. This feature is as described with respect to DNS entry <NUM> in <FIG>.

According to the invention, responsive to the first NF being within the first PLMN, and the second NF not being within the first PLMN, step <NUM> comprises generating the address response comprising the IP address of a first edge security node in the first PLMN. This feature is as described with respect to DNS entry <NUM> in <FIG>.

According to the invention, responsive to the neither first NF or the second NF being within the first PLMN; step <NUM> comprises generating the address response comprising the IP address of a second edge security node in a different PLMN to the first PLMN. This feature is as described with respect to DNS entry <NUM> in <FIG>.

<FIG> illustrates a not claimed method in a first Network Repository Function, NRF, within in a first Public Land Mobile Network, PLMN, for discovery of a second NF in a second Public Land Mobile Network, PLMN.

In step <NUM>, the first NRF receives a first discovery request from a first NF for the discovery of the second NF.

In step <NUM>, the first NRF determines that the second NF is within a second PLMN.

In step <NUM> the first NRF determines a second NRF domain name associated with a second NRF in the second PLMN.

In step <NUM>, the first NRF, transmits, to a domain name system, DNS, an address request for an IP address associated with the second NRF.

In step <NUM>, the first NRF, receives the IP address. The IP address may comprise a edge security node IP address of an edge security node in the first PLMN capable of forwarding the discovery request either to the second PLMN or a third PLMN in closer communication with the second PLMN.

In step <NUM>, the first NRF, forwards the discovery request to the IP address.

In step <NUM>, the first NRF receives a first discovery response comprising a first domain name associated with the second NF. In some examples, the first domain name comprises a domain name of the second NF. In some examples, the first domain name comprises a domain name of the second NF.

In some examples, the first NRF may then forward the first discovery response to the first NF.

In some examples, the first NRF may be configured to receive a second discovery request from a third NF within the first PLMN for the discovery of a fourth NF in the first PLMN; and generate a second discovery response comprising a second domain name associated with the fourth NF; and transmit the second discovery response to the third NF. The second domain name may comprise one of a domain name of the fourth NF, and a domain name of a second proxy NF performing topology hiding of the fourth NF. In other words, if the received discovery request is for a NF in the same PLMN as the NRF, the NRF may respond with the stored domain name associated with the requested NF which was stored during registration of the requested NF, as described above in <FIG>.

<FIG> illustrates a method, in a first edge security node of a first Public Land Mobile Network, PLMN, according to the invention.

In step <NUM>, the first edge security node receives, from a first network function, NF, a request for a second NF.

In step <NUM>, the first edge security node determines whether the second NF is within the first PLMN.

In step <NUM>, responsive to the second NF not being within the first PLMN, the first edge security node generates a first address request for the second NF.

In step <NUM> the first edge security node transmits the first address request to a domain name system, DNS, within the first PLMN from an external interface of the first edge security node located outside of the first PLMN.

According to the invention, responsive to transmitting the first address request, first edge security node receives a first address response comprising an IP address of a second edge security node in a second PLMN.

According to the invention, responsive to the second NF being within the first PLMN, first edge security node generates a second address request for the second NF and transmits the second address request to the DNS from an internal interface of the first edge security node. According to the invention, responsive to transmitting the second address request, first edge security node receives a second address response comprising an IP address of the second NF.

In other words, the SEPP is configured, when it receives a request for an NF which is outside of the PLMN of the SEPP, to sends an address request to the DNS using the external interface of the SEPP. In this way, the DNS will view the address request as having originated from outside of the PLMN, and the DNS therefore responds accordingly as illustrated in <FIG>.

Conversely, when the SEPP receives an address request for an NF which is within the first PLMN, the SEPP may transmit an address request for the second NF to the DNS using an internal interface of the SEPP. In this way the DNS will view the address request as having originated from within the PLMN and will respond accordingly as illustrated in <FIG>.

The request may comprise either a discovery request to discover a domain name of the second NF, or a service request to request service from the second NF.

<FIG> illustrates a not claimed example of an NF service discovery signaling flow for a roaming scenario where the requested NF is not in the same PLMN as the requesting NF.

In step <NUM> a first NF <NUM> in the first PLMN <NUM> determines that a service from a second NF <NUM> is required. The first NF <NUM> then transmits a discovery request to the first DNS <NUM> in the first PLMN <NUM> to discover the location of the second NF <NUM> by interacting with first NRF <NUM> in the first PLMN <NUM>. The first DNS <NUM> may be configured to operate as described with reference to <FIG>.

The first NF <NUM> therefore transmits in step <NUM>, a discovery request to the first DNS <NUM> for the IP address of the first NRF <NUM> in the first PLMN <NUM>. The first DNS <NUM> may then respond to the first NF <NUM> in step <NUM> with the IP address of the first NRF <NUM>. The first DNS <NUM> is in this example using the entry <NUM> illustrated in <FIG> as the request originated from within the same PLMN, for an NF (i.e. the first NRF) also within the same PLMN.

In step <NUM>, the first NF <NUM> transmits a discovery request to the first NRF <NUM> for the second NF <NUM>. The first NRF <NUM> may be configured to operate as described with respect to <FIG>. The first NRF <NUM> may then determine, in step <NUM>, that the second NF <NUM> is in the second PLMN <NUM> and may determine a domain name of the second NRF <NUM> in the second PLMN <NUM>. In step <NUM>, the first NRF <NUM> transmits a request to the first DNS <NUM> for an IP address associated with the domain name of the second NRF <NUM>. The first NRF <NUM> may use vendor-specific mechanisms or provisioning data for this purpose.

In this occasion, as the request is from within the first PLMN <NUM>, i.e. from the first NRF <NUM>, but is for a NF, i.e. the second NRF <NUM>, which is located outside of the first PLMN <NUM>, the first DNS <NUM> uses the DNS entry <NUM> and responds to the first NRF <NUM> in step <NUM> with the IP address of the first SEPP <NUM>.

In step <NUM> the first NRF <NUM> forwards the discovery request for the second NF <NUM> received from the first NF <NUM> to the IP address received in step <NUM>, i.e. the IP address of the first SEPP <NUM>. The first SEPP <NUM> may be configured to operate as described with respect to <FIG>. The discovery request sent to the first SEPP <NUM> for the second NF <NUM> may comprise a header set to the domain name of the second NRF <NUM>.

In step <NUM> the first SEPP <NUM> determines that the discovery request is for an NF in the second PLMN <NUM>. The first SEPP <NUM> may determine the second PLMN <NUM> by inspecting the header of the discovery request to extract the domain name of the second NRF <NUM>.

In step <NUM>, the first SEPP <NUM> may then transmit an address request to the first DNS <NUM> from an external interface of the first SEPP <NUM> located outside of the first PLMN <NUM>. In this example, the first SEPP <NUM> uses the external interface as the second NF <NUM> is located outside of the first PLMN <NUM>. The address request may comprise the domain name of the second NRF <NUM> which was part of the header of the discovery request received by the first SEPP <NUM> in step <NUM>.

The first DNS <NUM>, as the address request received in step <NUM> is sent from the external interface of the first SEPP <NUM> will treat the request as having originated from outside of the first PLMN <NUM>. The address request of step <NUM> is therefore originating from outside the first PLMN <NUM> for a NF also located outside of the first PLMN <NUM>. The first DNS <NUM>, as described in <FIG>, therefore transmits an address response back to the first SEPP <NUM> in step <NUM> comprising an IP address of second SEPP <NUM> of the second PLMN <NUM>. The second SEPP <NUM> may be configured to operate similarly to the first SEPP <NUM> as described in <FIG>.

The first SEPP <NUM> may then forward the discovery request to the second SEPP <NUM> using the IP address received in step <NUM>. The discovery request forwarded to the second SEPP <NUM> may comprise a header set to the domain name of the second NRF <NUM>. In step <NUM>, the second SEPP <NUM> may inspect the header of the discovery request received in step <NUM> and determines the second NRF <NUM> domain name.

The second SEPP <NUM> may then use a second DNS <NUM> in the second PLMN <NUM> to resolve the domain name of the second NRF <NUM>. For example, the second SEPP <NUM> may transmit an address request to the second DNS <NUM> comprising the domain name of the second NRF in step <NUM>. The second DNS <NUM> may be configured to operate similarly to the first DNS <NUM> as described in <FIG>.

The second DNS <NUM> may then use receive the address request in step <NUM> and, as the address request originated from within the same PLMN as the second DNS <NUM> and is a request for an NF (the second NRF) which is also in the same PLMN, the second DNS may respond with the IP address of the second NRF <NUM> in step <NUM>.

The second SEPP <NUM> may then transmit a discovery request for the second NF <NUM> to the second NRF <NUM> in step <NUM>. The second NRF <NUM> may be configured to operate similarly to the first NRF <NUM> as described in <FIG>. The second NRF <NUM> may analyze the received discovery request in step <NUM>. The second NF <NUM> may be registered in the second NRF <NUM> at it is in the same PLMN, i.e. the second PLMN <NUM>. The second NRF <NUM> may therefore transmit a discovery response in step <NUM> comprising the domain name of the second NF <NUM> which was registered during registration of the second NF <NUM>.

In some examples, a proxy function <NUM> may be providing topology hiding for the second NF <NUM>. In these examples, the discovery response may comprise the domain name of the proxy function <NUM>. The discovery response may then be transmitted back to the first NF <NUM> in steps <NUM>, <NUM> and <NUM>.

In this example therefore, the first NF <NUM> simply sends a discovery request for the second NF <NUM> and receives in response a discovery response in step <NUM>. The first NF <NUM> does not therefore need to indicate that the second NF <NUM> is in a different PLMN to the first PLMN <NUM>. In other words, the first NF <NUM> need not be aware of whether the discover request constitutes a roaming scenario.

<FIG> illustrates a not claimed example of NF service request signaling flow for a roaming scenario.

Once the second NF <NUM> (or the proxy function <NUM> realizing topology hiding for the second NF) is discovered by the first NF <NUM>, the first NF <NUM> may invoke a service from the second NF <NUM> in step <NUM>.

The first NF <NUM> may first transmit an address request to the first DNS <NUM> to resolve the domain name of the second NF <NUM> or the proxy function <NUM> in step <NUM>. The domain name of the second NF <NUM> or the proxy function <NUM> may be as received in the discovery response in step <NUM> of <FIG>.

The first DNS <NUM> may then, as the address request of step <NUM> was for a NF which is outside of the first PLMN, transmit a response in step <NUM> to the first NF <NUM> comprising the IP address of the first SEPP <NUM>.

The first NF <NUM> may the transmit in step <NUM> a service request for the second NF <NUM> to the first SEPP <NUM> using the IP address received in step <NUM>.

The service request may comprise a header set to the domain name of the second NF <NUM> or the proxy function <NUM>. The first SEPP <NUM> may then inspect the header of the service request in step <NUM> and may extract the domain name of the second NF <NUM> or the proxy function <NUM>.

The first SEPP <NUM> may then use the first DNS <NUM> to resolve the domain name of the second NF <NUM> or the proxy function <NUM>. For example, the first SEPP <NUM> may transmit an address request to the first DNS <NUM> for the second NF <NUM> using the external interface of the first SEPP <NUM>. As illustrated in <FIG>, the first SEPP <NUM> uses the external interface here as the second NF <NUM> is located outside of the first PLMN <NUM>.

The first DNS <NUM> may then transmit a response to the first SEPP <NUM> comprising the IP address of the second SEPP in <NUM>.

The first SEPP <NUM> may then transmit the service request or the service from the second NF to the second SEPP <NUM> in step <NUM>. The service request may comprise a header set to the domain name of the second NF <NUM> or the proxy function <NUM>. The second SEPP <NUM> may inspect the header of service request in step <NUM> and determines the NF to address.

If topology hiding is applicable, i.e. the server request comprises a header set to the domain name of the proxy function <NUM>, then steps 909a to 917a may be performed.

In step 909a, the second SEPP <NUM> uses the second DNS <NUM> to resolve the domain name of the proxy function <NUM>. The second DNS <NUM> may, as illustrated in <FIG>, transmit an address response to the second SEPP <NUM> comprising the IP address of the proxy function <NUM> in step 910a.

In step 911a the second SEPP <NUM> may then transmit the service request to the IP address of the proxy function <NUM>. The service request may comprise a header set to the domain name of the proxy function <NUM>.

As the header of the service request comprises the domain name of the proxy function, the proxy function may not be able to determine the NF to address from inspecting the service request. The proxy function <NUM> may therefore, determine the domain name of the second NF <NUM> in step 212a by for example, inspecting the Request-URI of the service request and inferring the second NF <NUM> from the Request-URI. in some examples, an additional lookup on the second NRF <NUM> made by the proxy function <NUM> may be required (not depicted).

The proxy function <NUM> may then utilize the second DNS <NUM> to resolve the domain name of the second NF <NUM>. For example, the proxy function <NUM> may transmit an address request to the second DNS for the address of the second NF <NUM> in step 913a. The second DNS <NUM> may the respond with the IP address of the second NF <NUM> in step 914a.

The proxy function <NUM> may then transmit the service request to the second NF <NUM> in step 915a.

The second NF <NUM> may then return a service response in step 916a, which traverses the proxy function <NUM> in reverse order up to the second SEPP <NUM> in step 917a.

If no topology hiding is used steps 909b to 912b are performed. The second SEPP <NUM> uses the second DNS <NUM> to resolve the domain name of the second NF. For example, in 909b, the second SEPP <NUM> transmits an address request to the second DNS for the address of the second NF <NUM>. The second DNS <NUM> responds in step 210b with the IP address of the second NF <NUM>.

The second SEPP <NUM> may then transmit the service request to the second NF <NUM> in step <NUM>. The second NF <NUM> returns a service response 912b to the second SEPP <NUM>.

Once the second SEPP receives the service response, either in step 912b or 917a, it transmits the service response back to the first SEPP <NUM> in step <NUM> which in turns transmits the service response to the first NF in step <NUM>.

<FIG> illustrates communication between a plurality of PLMNs according to some examples not forming part of the invention. For example, if a NF <NUM> in a first PLMN <NUM> requests discovery or a service from a second NF located in a third PLMN <NUM> which the SEPP in the first PLMN <NUM> is not capable of communicating with, the first PLMN <NUM> may pass the request to a second PLMN <NUM>, which is closer communication with the third PLMN <NUM>. The second PLMN <NUM> may then pass the request on to the third PLMN <NUM> (using DNS entry <NUM> as illustrated in <FIG>) where the requested NF may be discovered, or the service may be requested.

<FIG> illustrates a Network Function Discovery Orchestration (NFDO) node <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the NFDO node <NUM> and can implement the method described herein in relation to a NFDO node <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NFDO node <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NFDO node <NUM>.

Briefly, the processing circuitry <NUM> of the NFDO node <NUM> is configured to configure, in a domain name system, DNS, a first DNS entry associating a first domain name of the NF with at least one NF Internet Protocol, IP, address of the NF, and a second DNS entry associating the first domain name with at least one edge security node IP address of an edge security node in the first PLMN, wherein, the first DNS entry is for use in resolving requests for the NF which originate from within the first PLMN, and the second DNS entry is for use in resolving requests for the NF which originate from outside the first PLMN.

in some examples not forming part of the invention, the NFDO node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the NFDO node <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the NFDO node <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the NFDO node <NUM> may be configured to control the communications interface <NUM> of the NFDO node <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the NFDO node <NUM> may comprise a memory <NUM>. in some embodiments, the memory <NUM> of the NFDO node <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the NFDO node <NUM> to perform the method described herein in relation to the NFDO node <NUM>. Alternatively or in addition, the memory <NUM> of the NFDO node <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the NFDO node <NUM> may be configured to control the memory <NUM> of the NFDO node <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a first Network Repository Function (NRF) <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first NRF <NUM> and can implement the method described herein in relation to a first NRF <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first NRF <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the NRF <NUM>.

Briefly, the processing circuitry <NUM> of the first NRF <NUM> is configured to receive a first discovery request from a first NF for the discovery of a second NF; determine that the second NF is within a second PLMN; determine a second NRF domain name associated with a second NRF in the second PLMN, transmit, to a domain name system, DNS, an address request for an IP address associated with the second NRF; receive the IP address; forward the discovery request to the IP address; and receiving a first discovery response comprising a first domain name associated with the second NF.

in some examples not forming part of the invention, the first NRF <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first NRF <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the first NRF <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the first NRF <NUM> may be configured to control the communications interface <NUM> of the first NRF <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the first NRF <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the first NRF <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the first NRF <NUM> to perform the method described herein in relation to the first NRF <NUM>. Alternatively or in addition, the memory <NUM> of the first NRF <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the first NRF <NUM> may be configured to control the memory <NUM> of the first NRF <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a Domain Name System (DNS) <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the DNS <NUM> and can implement the method described herein in relation to a DNS <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the DNS <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the DNS <NUM>.

Briefly, the processing circuitry <NUM> of the DNS <NUM> is configured to receive an address request from a first Network Function, NF, for an Internet Protocol, IP, address associated with a domain name of a second NF; determine whether the second NF is within the first PLMN; and based on the determination, generate an address response comprising an IP address associated with the second NF.

In some embodiments, the DNS <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the DNS <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the DNS <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the DNS <NUM> may be configured to control the communications interface <NUM> of the DNS <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the DNS <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the DNS <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the DNS <NUM> to perform the method described herein in relation to the DNS <NUM>. Alternatively or in addition, the memory <NUM> of the DNS <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the DNS <NUM> may be configured to control the memory <NUM> of the DNS <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a first edge security node <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the first edge security node <NUM> and can implement the method described herein in relation to a first edge security node <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the first edge security node <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first edge security node <NUM>.

Briefly, the processing circuitry <NUM> of the first edge security node <NUM> is configured to receive, from a first network function, NF, a request for a second NF, determine whether the second NF is within the first PLMN; and responsive to the second NF not being within the first PLMN, generate a first address request for the second NF; and transmit the first address request to a domain name system, DNS, within the first PLMN from an external interface of the first edge security node located outside of the first PLMN.

In some embodiments, the first edge security node <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the first edge security node <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the first edge security node <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the first edge security node 1400may be configured to control the communications interface <NUM> of the first edge security node <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the first edge security node <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the first edge security node <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the first edge security node <NUM> to perform the method described herein in relation to the first edge security node <NUM>. Alternatively or in addition, the memory <NUM> of the first edge security node <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the first edge security node <NUM> may be configured to control the memory <NUM> of the first edge security node <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

There is therefore provided methods and apparatus in a Service Based Architecture, SBA, of a first Public Land Mobile Network, PLMN, for enabling NF requests using roaming and non-roaming scenarios.

Claim 1:
A method, in a Domain Name System, DNS, in a first Public Land Mobile Network, PLMN, wherein the DNS is configured to have at least two DNS entries for each Network Function, NF, and wherein first DNS entries (<NUM>, <NUM>) are configured for use in processing DNS requests that originate from outside of the first PLMN, and wherein second DNS entries (<NUM>, <NUM>) are configured for use in processing DNS requests that originated from within the first PLMN, the method comprising:
receiving an address request from a first NF for an Internet Protocol, IP, address associated with a domain name of a second NF;
determining whether the second NF is within the first PLMN; and
based on a determination and whether the first NF is within the first PLMN, and based on the determination of whether the second NF is within the first PLMN, generating an address response comprising an IP address associated with the second NF by:
- responsive to the second NF and the first NF being within the first PLMN, generating the address response comprising the IP address of the second NF;
- responsive to the second NF being within the first PLMN, and the first NF not being within the first PLMN, generating the address response comprising the IP address of a first edge security node of the first PLMN;
- responsive to the first NF being within the first PLMN, and the second NF not being within the PLMN, generating the address response comprising the IP address of a first edge security node in the first PLMN; and
- responsive to the neither first NF nor the second NF being within the first PLMN, generating the address response comprising the IP address of a second edge security node in a different PLMN to the first PLMN.