Method, system, and computer-readable medium for automatic domain name system (DNS) configuration for 5G core (5GC) network functions (NFs) using NF repository function (NRF)

Abstract

A method for automatic Domain Name System (DNS) configuration for a 5G Core (5GC) network function (NF) includes receiving a message related to the 5GC network function at an NF Repository Function (NRF) including at least one processor. The method further includes determining first DNS resource record parameters for the 5GC NF. The method further includes determining second DNS resource record parameters for the 5GC NF. The method further includes automatically configuring the DNS with a mapping between the first DNS resource record parameters and the second DNS resource record parameters for the 5GC NF.

Description

[Technical field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application No. 17 / 534,904, filed November 24, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to automatic DNS configuration. More particularly, the subject matter described herein relates to a method, system, and computer-readable medium for automatic DNS configuration for a 5GC NF using an NRF. [Background technology]

[0003] background In a 5G telecommunications network, a network function that provides a service is referred to as a producer NF or an NF service producer. A network function that consumes a service is referred to as a consumer NF or an NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or both consuming and producing a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0004] A given producer NF can have many service endpoints, which are contact points for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet protocol (IP) address and a port number or a fully qualified domain name that resolves to an IP address and a port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF can include two or more NF instances. Note also that multiple NF instances can share the same service endpoint.

[0005] A producer NF registers with a network function repository function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably in this specification. A consumer NF can obtain information about producer NF instances registered with the NRF through the NF service discovery procedure. According to the NF service discovery procedure, a consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters that are used by the NRF to search for NF profiles of producer NFs that can provide the service identified by the query parameters. An NF profile is a data structure that defines the type of service provided by the producer NF instance as well as contact and capacity information about the producer NF instance.

[0006] In addition to consumer NFs, another type of network node that can initiate NF service discovery procedures to obtain information about NF service instances is the service communication proxy (SCP). The case where an SCP uses NF service discovery procedures to obtain information about producer NF instances on behalf of a consumer NF is called delegated discovery. Consumer NFs are connected to an SCP, which load balances traffic among producer NF service instances that provide the required service or send traffic directly to the target producer NF instance. The communication model when a consumer NF communicates with a producer NF via an SCP is called the relayed communication model.

[0007] In addition to SCPs, another example of an intermediate proxy forwarding traffic between producer and consumer NFs is the security edge protection proxy (SEPP). A SEPP is a network function used to protect the control plane traffic exchanged between different 5G public land mobile networks (PLMNs). Thus, a SEPP performs message filtering, policing, and topology hiding for all application programming interface (API) messages transmitted between PLMNs.

[0008] One problem that may occur in 5G and other communication networks is that 3GPP standards allow 5G NFs to use self-constructed FQDNs to communicate with each other, and maintaining the mapping between the self-constructed FQDNs and IP addresses may require manual DNS configuration. A self-constructed FQDN is an FQDN that is generated by a 5GC network function according to a format defined in the 3GPP standards. For example, 3GPP TS23.003 defines a format for a self-constructed FQDN that may be used by 5GC NFs to identify each other. To communicate with a 5GC NF using the self-constructed FQDN, the NF formats a message and includes the self-constructed FQDN in the message. In order for the message to reach the target NF, the self-constructed FQDN in the message must be translated to an IP address via DNS. If the DNS records are not kept up to date, a 5G consumer NF seeking contact with a 5G producer NF using the self-constructed FQDN will not be able to determine the correct IP address to communicate with the 5G producer NF. Currently, manual DNS configuration is performed to keep DNS records up to date with mappings between self-constructed FQDNs and IP addresses for 5GC NFs. Performing manual DNS configuration to keep mappings up to date is undesirable, especially in a cloud network environment, where mappings between self-constructed FQDNs and IP addresses may change frequently. More generally, performing manual DNS configuration for any kind of DNS resource records related to 5GC NFs is undesirable.

[0009] Therefore, in light of these and other challenges, improved methods, systems, and computer-readable media for configuring DNS for 5GC NFs are desired. Summary of the Invention

[0010] overview A method for automatic domain name system (DNS) configuration for a 5G core (5GC) network function (NF), comprising receiving a message related to the 5GC network function at an NF repository function (NRF) including at least one processor. The method further comprises determining first DNS resource record parameters for the 5GC NF. The method further comprises determining second DNS resource record parameters for the 5GC NF. The method further comprises automatically configuring the DNS with a mapping between the first DNS resource record parameters and the second DNS resource record parameters.

[0011] According to another aspect of the subject matter described in this specification, receiving a message related to a 5GC NF includes receiving a message including an NF profile or a service profile of the 5GC NF.

[0012] According to another aspect of the subject matter described herein, determining the first DNS resource record parameter includes reading a self-constructed fully qualified domain name (FQDN) of the 5GC NF from an NF profile or service profile of the 5GC NF.

[0013] According to another aspect of the subject matter described herein, determining the first DNS resource record parameters includes creating a self-constructed fully qualified domain name (FQDN) from parameters in a NF profile or service profile of the 5GC NF.

[0014] According to another aspect of the subject matter described herein, determining the second DNS record parameter includes reading an IP address from a NF profile or a service profile of the 5GC NF.

[0015] According to another aspect of the subject matter described herein, determining the second DNS resource record parameter includes determining that the NF profile or the service profile does not include an IP address, and obtaining the IP address from one of a load balancer, a cloud network service registry, and a local DNS.

[0016] According to another aspect of the subject matter described herein, determining the first DNS resource record parameter includes reading a NF set fully qualified domain name (FQDN) and a NF instance FQDN from a NF profile of the NF, and wherein automatically configuring the DNS includes automatically generating a naming authority pointer (NAPTR) record that maps from the NF set FQDN to the NF instance FQDN.

[0017] According to another aspect of the subject matter described in this specification, receiving a message including an NF profile or service profile for the 5GC NF includes receiving an NF registration message or an NF update message including an NF profile or service profile for the 5GC NF.

[0018] According to another aspect of the subject matter described herein, a method for automatically configuring a DNS includes determining that a mapping between a first DNS resource record parameter and a second DNS resource record parameter represents a new mapping or a change to an existing mapping maintained by the DNS for the first and second DNS resource record parameters, and automatically configuring the DNS includes automatically configuring the DNS in response to determining that the mapping between the first and second DNS resource record parameters represents a new mapping or a change to the existing mapping.

[0019] According to another aspect of the subject matter described herein, automatically configuring the DNS includes transmitting a message from the NRF to a DNS server, the message being formatted according to an application programming interface exposed by the DNS, including a mapping between the first and second DNS resource record parameters.

[0020] According to another aspect of the subject matter described herein, a system for automatic Domain Name System (DNS) configuration for a 5G Core (5GC) network function (NF) is provided. The system includes a network function (NF) repository function (NRF) including at least one processor. The system further includes a DNS auto updater implemented by the at least one processor for receiving a message related to the 5GC network function, determining a first DNS resource record parameter for the 5GC NF, determining a second DNS resource record parameter for the 5GC NF, and automatically configuring the DNS with a mapping between the first DNS resource record parameter and the second DNS resource record parameter.

[0021] According to another aspect of the subject matter described in this specification, a message related to a 5GC NF includes a message including an NF profile or service profile of the 5GC NF.

[0022] According to another aspect of the subject matter described in this specification, the DNS auto updater is configured to determine a first DNS resource record parameter by reading a self-constructed fully qualified domain name (FQDN) of the 5GC NF from an NF profile or a service profile of the 5GC NF.

[0023] According to another aspect of the subject matter described in this specification, the DNS auto updater is configured to determine a first DNS resource record parameter by creating a self-constructed fully qualified domain name (FQDN) of the 5GC NF from parameters in an NF profile or service profile of the 5GC NF.

[0024] According to another aspect of the subject matter described herein, the DNS auto updater is configured to determine the second DNS resource record parameters by reading an IP address from an NF profile or a service profile of the 5GC NF.

[0025] According to another aspect of the subject matter described herein, the DNS auto updater is configured to determine that the NF profile or the service profile does not include an IP address, and to determine the second DNS resource record parameter by obtaining the IP address from one of a load balancer, a cloud network service registry, and a local DNS.

[0026] According to another aspect of the subject matter described in this specification, the message including an NF profile or service profile for the 5GC NF includes an NF registration message or an NF update message including an NF profile or service profile for the 5GC NF.

[0027] According to another aspect of the subject matter described herein, a DNS auto updater is configured to determine a first DNS resource record parameter by reading a NF set fully qualified domain name (FQDN) and a NF instance FQDN from a NF profile of the NF, where automatically configuring the DNS includes automatically generating a Naming Authority Pointer (NAPTR) record that maps from the NF set FQDN to the NF instance FQDN.

[0028] According to another aspect of the subject matter described herein, the DNS auto updater automatically configures the DNS by transmitting messages formatted according to an application programming interface (API) exposed by the DNS from the NRF to a DNS server, including a mapping between first and second DNS resource record parameters.

[0029] According to another aspect of the subject matter described herein, one or more non-transitory computer-readable media are provided having executable instructions stored thereon that, when executed by a processor of a Network Function (NF) Repository Function (NRF), control the NRF to perform steps. The steps include receiving a message related to a 5G Core (5GC) Network Function (NF). The steps further include determining first DNS resource record parameters for the 5GC NF. The steps further include determining second DNS resource record parameters for the 5GC NF. The steps further include automatically configuring DNS with a mapping between the first and second DNS resource record parameters for the 5GC NF.

[0030] The subject matter described herein may be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer-readable medium implementing the subject matter described herein may be located in a single device or computing platform, or may be distributed across multiple devices or computing platforms.

[0031] Example implementations of the subject matter described herein will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0032] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Diagram 2] A message flow diagram showing example messages exchanged for a NF registration service operation. [Diagram 3] FIG. 1 is a block diagram illustrating example attributes that may be included in an NF profile and an NF service profile. [Figure 4] FIG. 1 is a network diagram illustrating an example network architecture in which manual DNS configuration is required for self-built FQDNs of 5GC NFs. [Diagram 5] FIG. 13 is a message flow diagram illustrating example messages exchanged in a network in which manual DNS configuration is performed for a self-built FQDN of a 5GC NF. [Figure 6] FIG. 13 is a message flow diagram showing example messages exchanged when the NRF performs automatic DNS configuration for a 5GC NF. [Figure 7] FIG. 1 is a block diagram illustrating an example architecture for an NRF to perform automatic DNS configuration for a 5GC NF. [Figure 8] 1 is a flowchart illustrating an example process for implementing automatic DNS configuration for a 5GC NF. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] Detailed Description FIG. 1 is a block diagram illustrating an example 5G system network architecture. The architecture of FIG. 1 includes an NRF 100 and an SCP 101 that may be located in the same home public land mobile network (HPLMN). As described above, the NRF 100 may maintain a profile of available producer NF service instances and their supported services, and may enable consumer NFs or SCPs to subscribe to and notify the registration of new / updated producer NF service instances. The SCP 101 may further support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0034] The NRF 100 is a repository for the NF profile or service profile of a producer NF instance. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile or service profile of the producer NF instance from the NRF 100. The NF profile or service profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile or service profile includes attributes that indicate the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0035] In Figure 1, any of the network functions may be consumer NFs, producer NFs, or both, depending on whether they request a service, provide a service, or request and provide a service. In the illustrated embodiment, the NFs include a policy control function (PCF) 102 that enforces policy-related operations in the network, a unified data management function (UDM) 104 that manages user data, and an application function (AF) 106 that provides application services.

[0036] 1 further includes a session management function (SMF) 108 that manages sessions between an access and mobility management function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a mobility management entity (MME) in 4G networks. An authentication server function (AUSF) 112 performs authentication services for user equipment (UE), such as user equipment (UE) 114, seeking access to the network.

[0037] A network slice selection function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and properties associated with a network slice. A network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of things (IoT) devices and other UEs belonging to the network. The NEF 118 performs a function similar to the service capability exposure function (SCEF) in 4G networks.

[0038] A radio access network (RAN) 120 connects the user equipment (UE) 114 to the network via a wireless link. The radio access network 120 may be accessed using a g-Node B (gNB) (not shown in FIG. 1 ) or other wireless access points. A user plane function (UPF) 122 may support various proxy functionalities for user plane services. One example of such proxy functionalities is a multipath transmission control protocol (MPTCP) proxy functionality. The UPF 122 may further support performance measurement functionality that may be used by the UE 114 to achieve network performance measurements. Also shown in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0039] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for outgoing traffic from the home PLMN. The SEPP 126 can communicate with a SEPP in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one SEPP for the home PLMN and another SEPP for the non-home PLMN.

[0040] As mentioned above, one issue that may arise in 5G and other networks is that mappings between self-built FQDNs and IP addresses and other types of DNS mappings for 5GC NFs are maintained using manual DNS configuration. 3GPP has defined self-built FQDNs for 5G NFs that are utilized when consumers are unable to perform discovery of such producer NFs from the NRF. Example use cases for self-built FQDNs include NFs communicating with an NRF without local configuration for NF discovery, V-NRF to H-NRF communication, V-NSSF to H-NSSF communication, AMF to NSSF communication, etc. One issue with self-built FQDNs is that manual configuration of DNS is required. Furthermore, the self-built FQDN and IP address mappings in DNS need to be kept in sync with the ever-changing cloud-native 5G topology. Cloud-native 5G topology information already exists in the NRF. However, there is no clear mechanism to synchronize the topology maintained by the NRF to the DNS system. In accordance with the subject matter described herein, NRF can be utilized to configure and update DNS with changes in mappings between self-built FQDNs and IP addresses or other types of DNS mappings, even in cloud-native 5G topologies where the mappings change frequently.

[0041] In a 5G communication network, 5GC NFs register their NF profile with the NRF. The NF profile may include the self-constructed FQDN of the NF, the IP address of the NF, or both. FIG. 2 is a message flow diagram illustrating example messages exchanged for an NF registration service operation. Referring to FIG. 2, in line 1 of the message flow, a consumer NF 200 initiates an NF registration service operation by sending a hypertext transfer protocol (HTTP) PUT message to the NRF 100. The HTTP PUT message includes the NF profile of the consumer NF 200. The NF profile may include the FQDN, IP address, or both, for the NF whose NF profile is registered with the NRF 100. If the NF registration operation is successful, the NRF 100 responds with a 201 generated message as shown in line 2a. If the NF registration service operation is not successful or the message is redirected to another NRF, the NRF 100 responds with a 4XX or 5XX message with problem detail as shown in line 2b or with a 3XX message indicating redirection. Once the NRF has the NF profile of the consumer NF, the NRF can use the information in the NF profile to configure DNS with a mapping between a self-constructed FQDN and an IP address. However, the current 3GPP standard does not define such a procedure for the NRF to maintain DNS records for a 5GC NF.

[0042] As shown above, the NF profile for the 5GG NF may include a self-constructed FQDN, an IP address, or both for the 5GC NF. FIG. 3 is a block diagram illustrating example attributes that may be included in the NF profile and the NF service profile. If the scheme in the URI portion of the FQDN does not require Transport Layer Security (TLS), the 5GC NF registers the NF profile with the NRF. If the scheme in the URI of the FQDN is HTTP and requires TLS, the 5GC NF registers the service profile with the NRF. In the illustrated embodiment, the NF profile 300 includes an FQDN attribute, an IPv4 address attribute, and an IPv6 address attribute. The service profile 302 includes an FQDN attribute and an IP endpoint attribute that includes an IPv4 address or an IPv6 address. Any of these parameters or attributes from the service profile or NF profile may be used to automatically configure DNS for the 5GC NF.

[0043] The self-constructed FQDN may be created by the 5GC NF according to the format specified in 3GPP TS 23.003, Section 28 of which specifies the following: N3 inter-working function (N3IWF) PLMN-level NRF and H-NRF ·NSSF AMF ·TAI (Tracking Area Identifier FQDN) AMF Set AMF Instance ·SMF Set Short message service function (SMSF) Define a self-constructed FQDN for An example of a self-constructed FQDN for NRF is: https: / / nrf.5gc.mnc345.mcc012.3gppnetwork.org / . An example of a self-constructed FQDN for NSSF is: https: / / nssf.5gc.mnc345.mcc012.3gppnetwork.org / . One point to emphasize is that to enable a consumer NF using a self-constructed FQDN to obtain the latest IP address for the self-constructed FQDN, the DNS needs to be configured and kept up to date with the IP address mapping for the self-constructed FQDN.

[0044] In the current 3GPP defined architecture for 5G, there is no mechanism for automatic DNS configuration for self-constructed FQDNs of 5G NFs. FIG. 4 is a network diagram illustrating an example network architecture, where manual DNS configuration is required for self-constructed FQDNs of 5GC NFs. Referring to FIG. 4, the network includes a visited PLMN and a home PLMN. The visited PLMN includes a visited SEPP 126A, a visited NRF 100A, a visited NSSF 116A, a SMSF 400, a gNodeB 402, an SMF 108, an N3IWF 404, and an AMF 110. The visited PLMN further includes a visited PLMN DNS 406A. The home PLMN includes a home SEPP 126B, a home NRF 100B, a home NSSF 116B, and a home PLMN DNS 406B. NFs in the home PLMN and the visited PLMN self-construct FQDNs to identify and communicate with each other. The IP addresses associated with the self-constructed FQDNs can change frequently, and since there is no automatic DNS configuration procedure defined in the 3GPP standard, manual configuration of DNS 406A and 406B is required to maintain an up-to-date mapping between the self-constructed FQDNs and IP addresses of the 5GC NFs.

[0045] Table 1 below shows some examples in which self-constructed FQDNs may be used in the architecture of FIG.

[0046] [Table 1]

[0047] In each scenario in Table 1, an NF that receives a message using the self-constructed FQDN of the target NF needs to query DNS to obtain the IP address of the target. It is therefore desirable to have an efficient mechanism for keeping DNS records for the self-constructed FQDN up to date that avoids or at least reduces the need for manual DNS configuration.

[0048] FIG. 5 is a message flow diagram showing example messages exchanged in a network, where manual DNS configuration is performed for a self-constructed FQDN of a 5GC NF. Referring to FIG. 5, when an NF registers its NF profile or service profile with the NRF 100A, it is necessary to manually configure the DNS 406A with a mapping between the self-constructed FQDN and an IP address for the NF. A similar operation is performed when an NF updates its profile with the NRF. The NRF DNS configuration must also be maintained with the DNS 406A. Referring to the message flow of FIG. 5, in lines 1 and 2, the AMF 110 registers its NF profile with the NRF 100A, and the NRF 100A responds to indicate successful registration of the NF profile of the AMF 110. In line 3, the NSSF 116A sends a NF registration message to the NRF 100A. In line 4, the NRF 100A responds with a success message indicating successful registration of the NSSF 116A. After line 4, or whenever registration with the NRF 100A is performed, DNS 406A must be configured with the self-constructed FQDN and corresponding IP address of the NF whose NF profile or service profile is being registered. In line 5, DNS 406A is manually configured with the IP address and self-constructed FQDN of the NRF 100A. In line 6, DNS 406A is manually configured with the self-constructed FQDN and IP address of the AMF 110. In line 7, DNS 406A is manually configured with the self-constructed FQDN and IP address of the NSSF 116A.

[0049] When a consumer NF seeks to communicate with a target NF, the consumer NF self-constructs an FQDN of the target NF according to the format defined in 3GPP TS 23.003. Because the consumer NF 200 does not know the IP address corresponding to the FQDN, either the consumer NF or the SCP or SEPP must send a DNS query to DNS 406A to translate the FQDN to an IP address. In line 9, the consumer NF 200 receives a response to the DNS query that includes a mapping between the FQDN and the IP address. After line 9, the consumer NF 200 can send a message to the target producer NF using the self-constructed FQDN and IP address obtained from DNS 406A.

[0050] In line 10 of the message flow diagram, the AMF 110 sends a NF update message to the NRF 100A to update the NF profile of the AMF 110 with the NRF 100A. In line 11, the NRF 100A responds with a success message indicating that the NF update service operation was successful. In line 12, the NSSF 116A sends a message to the NRF 100A to update the NF profile of the NSSF 116A with the NRF 100A. In line 13, the NRF 100A responds with a success message indicating that the NF update operation was successful. After line 13, the DNS 406A must be manually configured with any changes in the IP address mapping for the NRF 100A, the AMF 110, and the NSSF 116A. In line 14, the DNS 406A is manually configured with the updated IP address mapping information for the NRF 100A. In line 15, the DNS 406A is manually configured with the updated IP address mapping information for the AMF 110. In line 16, DNS 406A is manually configured with the updated IP address mapping information of NSSF 116A.

[0051] To avoid or reduce the need for manual DNS configuration after each NF registration and / or NF update, the subject matter described herein adds functionality to the NRF to automatically configure DNS when messages related to a 5G NF are received. FIG. 6 is a message flow diagram illustrating example messages exchanged when an NRF performs automatic DNS configuration for a self-built FQDN of a 5GC NF. In line 1, NRF 100A automatically configures its FQDN to IP address mapping with DNS 406A. NRF 100A can automatically update its FQDN to IP address mapping with DNS 406A upon NRF 100A startup or whenever NRF 100A's IP address changes.

[0052] When an NF registers or updates its NF profile or service profile with the NRF 100A, it is no longer necessary to manually configure the DNS 406A with a mapping between the self-constructed FQDN and an IP address for the NF. In line 2, the AMF 110 registers its NF profile with the NRF 100A, and in line 3, the NRF 100A responds to indicate successful registration of the NF profile of the AMF 110. In line 4, in response to registering the NF profile of the AMF 110, the NRF 100A automatically configures the DNS 406A with a mapping between the self-constructed FQDN of the AMF 110 and an IP address corresponding to the self-constructed FQDN. If both the IP address and the self-constructed FQDN are present in the NF profile, the NRF 100A can read the self-constructed FQDN and the IP address from the NF profile and can use the self-constructed FQDN and the IP address in a message transmitted by the NRF 100A to a DNS server that is part of the DNS 406A. The format of the message transmitted by the NRF 100A to the DNS server is determined by the application programming interface (API) used by the DNS server in the domain where the mapping is updated. If the IP address is not present in the NF profile, the NRF 100A may obtain the IP address by querying another source, such as a load balancer, a cloud network service registry, a local DNS cache, or other source.

[0053] In line 5, the NSSF 116A sends a NF registration message to the NRF 100A. In line 6, the NRF 100A responds with a success message indicating successful registration of the NSSF 116A. In line 7, the NRF 100A automatically configures the DNS 406A with a mapping between the self-constructed FQDN of the NSSF 116A and an IP address corresponding to the self-constructed FQDN. As with the AMF 110, the NRF 100A can obtain the IP address from the NF profile or service profile of the NSSF 116A, or from another source such as a load balancer, a local DNS cache, or a cloud network service registry.

[0054] When a consumer NF seeks to communicate with a target NF, the consumer NF self-constructs an FQDN of the target NF according to the format defined in 3GPP TS 23.003. Because the consumer NF 200 does not know the IP address corresponding to the FQDN, either the consumer NF or the SCP or SEPP must send a DNS query to the DNS 4046A to translate the FQDN to an IP address. In line 9, the consumer NF 200 receives a response to the DNS query that includes a mapping between the FQDN and the IP address. After line 9, the consumer NF 200 can send a message to the target producer NF using the self-constructed FQDN and IP address obtained from the DNS 406A. Because the DNS records for the producer NF are maintained by the NRF 100A, no manual DNS configuration is required and the consumer NF 200 will receive an IP address for the self-constructed FQDN synchronized to the IP address mapping data available to the NRF 100A.

[0055] In line 10 of the message flow diagram, the NRF 100A configures its IP address mapping information with the DNS 406A. As described above, the NRF 100A can automatically update the IP address corresponding to the NRF 100A's self-constructed FQDN whenever the IP address changes, for example, due to a change in cloud network resource allocation.

[0056] In line 11 of the message flow diagram, the AMF 110 sends an NF update message to the NRF 100A to update the NF profile of the AMF 110 with the NRF 100A. In line 12, the NRF 100A responds with a success message indicating that the NF update service operation was successful. In line 13, the NRF 100A automatically configures the AMF 110 with a mapping between the self-constructed FQDN of the AMF 110 and an IP address corresponding to the self-constructed FQDN.

[0057] In line 14, the NSSF 116A sends a NF update message to the NRF 100A to update the NF profile of the NSSF 116A with the NRF 100A. In line 15, the NRF 100A responds with a success message indicating that the NF update operation was successful. In line 16, the NRF 100A automatically configures the DNS 406A with a mapping between the self-constructed FQDN of the NSSF 116A and an IP address corresponding to the self-constructed FQDN.

[0058] FIG. 7 is a block diagram illustrating an example architecture for an NRF to implement automatic DNS configuration for self-built FQDNs of 5GC NFs. Referring to FIG. 7, the NRF 100A includes at least one processor 700 and a memory 702. The NRF 100A further includes an NF / service profile database 704 that may reside in the memory 702. The NF / service profile database 704 stores NF profiles and service profiles of NFs that are registered with the NRF 100A. The NRF 100A further includes an NF registration / update handler 706 that receives and processes NF registration-update messages to store and update the NF profiles and NF service profiles in the NF / service profile database 704.

[0059] The NRF 100A further includes a DNS auto-updater 708 that automatically configures DNS in response to detecting changes in the mapping between the NF's self-constructed FQDN and IP address and other types of DNS mappings. The DNS auto-updater 708 can update DNS records in response to receiving an NF registration message or an NF update message from a consumer NF. The NF registration / update handler 706 and the DNS auto-updater 708 can be implemented using computer-executable instructions stored in the memory 702 and executable by the processor 700.

[0060] The DNS auto updater 708 can interact with the DNS using APIs provided by the DNS in the particular network in which the DNS auto updater 708 resides. The NRF 100A can be configured with the following attributes of the API to enable the DNS auto updater 708 to interact with the DNS:

[0061] [Table 2]

[0062] In Table 2, the value of the DNS API Endpoint attribute is the FQDN of the DNS server that the NRF contacts to update the DNS records. The value of the DNS API Prefix attribute is a prefix for the FQDN of the DNS server that the NRF contacts to update the DNS records. The value of the DNS Security Credentials attribute contains any security credentials required for the DNS server to enable the NRF to update the DNS records for the 5GC NFs.

[0063] 8 is a flow chart illustrating an example process for implementing automatic DNS configuration for a self-constructed FQDN of a 5GC NF. Referring to FIG. 8, in step 800, the process includes receiving a message related to the 5GC NF. For example, the DNS auto updater 708 of the NRF 101A may receive an NF registration request or an NF update request to register or update an NF profile or service profile of the NRF 100A.

[0064] In step 802, the process includes determining a first DNS resource record parameter for the 5GC NF. For example, if the FQDN exists in the NF profile or service profile, the DNS auto updater 708 of the NRF 100A can load a self-constructed FQDN from the NF profile or service profile. Alternatively, the NRF 100A can self-construct an FQDN for the 5GC NF using parameters available in the NF profile or service profile. In another embodiment, the NRF 100A can load or construct a uniform resource name (URN) from the NF profile or service profile of the 5GC NF.

[0065] In step 804, the process includes determining a second DNS resource record parameter for the 5GC NF. For example, if the IP address is present in the NF profile or service profile, the DNS auto updater 708 of the NRF 100A can read the IP address from the received NF profile or service profile in the NF registration message or NF update message. Alternatively, the DNS auto updater 708 of the NRF 100A can determine the IP address corresponding to the FQDN from an external source, such as a load balancer, a cloud network service registry, or a local DNS server or cache.

[0066] At step 806, the process includes automatically configuring the DNS with the mapping between the first and second DNS resource record parameters. For example, the DNS auto updater 708 of the NRF 100A can transmit a message to a DNS server to update the DNS records for the 5GC NF to include a mapping between the 5GC NF's self-constructed FQDN and the NF's IP address. In another embodiment, the DNS auto updater 708 can generate a naming authority pointer record (NAPTR) record for the 5GC NF and transmit the NAPTR record to the DNS server. The following is an example of a NAPTR record that may be generated by the DNS auto updater 708 using parameters from the NF profile of the 5GC NF:

[0067]

number

[0068] In this example, the NAPTR record includes the AMF set FQDN, which is AMF set001.region48.amfset, and the NF instance FQDNs, which are topoff.amf11.amf and topoff.amf12.amf, that are members of the AMF set. Lines beginning with a semicolon are comments. The DNS autoupdater 708 can generate the NAPTR record content using the FQDNs and IP addresses extracted from the NF profile for the NF set.

[0069] In one embodiment, the DNS auto updater 708 may hold or maintain a local DNS cache of mappings between the FQDN and IP address of the 5GC NF and may check the cache to determine if an update is required by the DNS record before sending a message to the DNS. If the IP address received or determined from the NF registration message or NF update message is a new or updated IP address for the self-constructed FQDN of the 5GC NF, the DNS auto updater 708 may transmit a message to the DNS server to update the mapping between the IP address and the self-constructed FQDN maintained by the DNS server. If the IP address received or determined from the NF registration message or NF update message is not a new IP address for the self-constructed FQDN, the DNS auto updater 708 may refrain from updating the DNS record with the DNS server.

[0070] Example advantages of the subject matter described herein include automating DNS configuration for on-demand topology changes (e.g., adding / removing / updating a network slice resulting in a change in IP addresses for a self-built FQDN or a change in other mappings maintained by the DNS). In general, the NRF described herein obtains NF topology information from the NF profile and service profile of the 5GC NF and uses the NF topology information to automatically update DNS resource records for the 5GC NF. The dynamic nature of cloud-native topologies that change very frequently will benefit from automatic updates of DNS records, as manual changes cannot keep up with the pace of topology changes. DNS details for the self-built FQDN and other FQDNs do not need to be manually configured. Mappings between IP addresses and FQDNs of 5GC NFs can be synchronized by the NRF operating with both 5GC and DNS systems. For example, local DNS configuration maintained by the NRF can be synchronized to an external DNS. Implementing automatic DNS configuration using the NRF reduces implementation complexity. The NRF is only required to implement DNS configuration. The DNS configuration maintained by the NRF is continually audited for changes as new NF registration and update messages are received. If an IP address change is detected, the NRF automatically injects this change into the DNS.

[0071] The disclosure of each of the following references is incorporated herein by reference in its entirety. References 1. 3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification; (Release 17) 3GPP TS 23.003 V17.3.0 (2021-09) twenty three rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; Technical Realization of Service Based Architecture (5GS); Stage 3 (Release 17) 3GPP TS 29.500 V17.4.0 (2021-09) 3. 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 17) 3GPP TS 23.501 V17.2.0 (2021-09) 4. 3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17) 3GPP TS 23.502 V17.2.1 (2021-09) 5. 3 rd Generation Partnership Project; Technical Specification Group Croup Core Network and Terminals; Principles and Guidelines for Services Definitions; Stage 3 (Release 17) 3GPP TS 29.501 V17.3.1 (2021-09) 6. 3 rdGeneration Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.3.0 (2021-09) 7.3 rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security architecture and procedures for 5G System (5GS) (Release 17) 3GPP TS 33.501 V17.3.0 (2021-09) 8. 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Domain Name System Procedures (Release 17) 3GPP TS 29.303 V17.0 (2021-03) It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Moreover, the above description is merely illustrative and not limiting, and thus the subject matter described herein is defined by the claims set forth below.

Claims

1. 1. A method for automatic domain name system (DNS) configuration for a 5G Core (5GC) Network Function (NF), the method comprising: in an NF Repository Function (NRF) including at least one processor: receiving a message related to the 5GC network functionality; determining a first DNS resource record parameter for the 5GC NF; determining second DNS resource record parameters for the 5GC NF; automatically configuring a DNS with a mapping between the first DNS resource record parameters and the second DNS resource record parameters; A method comprising:

2. The method of claim 1 , wherein receiving a message related to a 5GC NF includes receiving a message including an NF profile or a service profile of the 5GC NF.

3. 3. The method of claim 2, wherein determining the first DNS resource record parameter includes reading a self-constructed fully qualified domain name (FQDN) of the 5GC NF from the NF profile or the service profile of the 5GC NF.

4. 3. The method of claim 2, wherein determining the first DNS resource record parameters includes creating a self-constructed fully qualified domain name (FQDN) from parameters in the NF profile or the service profile of the 5GC NF.

5. The method of claim 2 , wherein determining the second DNS record parameters includes reading an IP address from the NF profile or the service profile of the 5GC NF.

6. 3. The method of claim 2, wherein determining the second DNS resource record parameter comprises determining that the NF profile or the service profile does not include an IP address; and obtaining the IP address from one of a load balancer, a cloud network service registry, and a local DNS.

7. 3. The method of claim 2, wherein determining the first DNS resource record parameters includes reading an NF set fully qualified domain name (FQDN) and an NF instance FQDN from the NF profile of the NF, and automatically configuring the DNS includes automatically generating a Naming Authority Pointer (NAPTR) record that maps from the NF set FQDN to the NF instance FQDN.

8. 3. The method of claim 2, wherein receiving a message including an NF profile or a service profile for the 5GC NF includes receiving an NF registration message or an NF update message including the NF profile or the service profile for the 5GC NF.

9. determining that the mapping between the first DNS resource record parameters and the second DNS resource record parameters represents a new mapping or a change to an existing mapping maintained by the DNS for the first and second DNS resource record parameters; Including, 2. The method of claim 1, wherein automatically configuring the DNS comprises automatically configuring the DNS in response to determining that the mapping between the first and second DNS resource record parameters represents a new mapping or a change to an existing mapping.

10. 2. The method of claim 1, wherein automatically configuring the DNS includes transmitting a message from the NRF to a DNS server, the message formatted according to an application programming interface (API) exposed by the DNS, including the mapping between the first and second DNS resource record parameters.

11. 1. A system for automatic Domain Name System (DNS) configuration for a 5G Core (5GC) Network Function (NF), the system comprising: a Network Function (NF) Repository Function (NRF) including at least one processor; a DNS auto-updater implemented by the at least one processor for receiving messages related to 5GC network functions, determining first DNS resource record parameters for the 5GC NF, determining second DNS resource record parameters for the 5GC NF, and automatically configuring a DNS using a mapping between the first DNS resource record parameters and the second DNS resource record parameters; A system comprising:

12. The system of claim 11 , wherein the message related to a 5GC NF includes a message including an NF profile or a service profile of the 5GC NF.

13. 13. The system of claim 12, wherein the DNS auto-updater is configured to determine a first DNS resource record parameter by reading a self-constructed fully qualified domain name (FQDN) of the 5GC NF from the NF profile or the service profile of the 5GC NF.

14. 13. The system of claim 12, wherein the DNS auto-updater is configured to determine the first DNS resource record parameters by creating a self-constructed fully qualified domain name (FQDN) of the 5GC NF from parameters in the NF profile or the service profile of the 5GC NF.

15. The system of claim 12 , wherein the DNS auto-updater is configured to determine a second DNS resource record parameter by reading an IP address from the NF profile or the service profile of the 5GC NF.

16. 13. The system of claim 12, wherein the DNS auto-updater is configured to determine that the NF profile or the service profile does not include an IP address, and to determine the second DNS resource record parameter by obtaining an IP address from one of a load balancer, a cloud network service registry, and a local DNS.

17. The system of claim 12, wherein the message including the NF profile or the service profile for the 5GC NF includes an NF registration message or an NF update message including the NF profile or the service profile for the 5GC NF.

18. 13. The system of claim 12, wherein the DNS auto-updater is configured to determine the first DNS resource record parameters by reading an NF set fully qualified domain name (FQDN) and an NF instance FQDN from the NF profile of the NF, and wherein automatically configuring the DNS includes automatically generating a naming authority pointer (NAPTR) record that maps from the NF set FQDN to the NF instance FQDN.

19. 19. The system of claim 11, wherein the DNS auto-updater automatically configures the DNS by transmitting a message from the NRF to a DNS server, the message being formatted according to an application programming interface (API) exposed by the DNS, including the mapping between the first and second DNS resource record parameters.

20. A program comprising executable instructions that when executed by a processor of a Network Function (NF) Repository Function (NRF) control said NRF to perform the method of any one of claims 1 to 10.

Images