Method, system, and computer-readable medium for actively discovering and tracking addresses associated with a 4G service endpoint

Abstract

A method for discovering and tracking addresses associated with a 4G service endpoint includes receiving a first domain name system (DNS) resolution or monitoring request from a requesting node, the request including a fully qualified domain name (FQDN) of the 4G service endpoint. The method further includes querying a DNS server using the FQDN from the first DNS resolution or monitoring request. The method further includes receiving a first response from the DNS server, the response including an address associated with the 4G service endpoint, and storing the address associated with the 4G service endpoint in a database. The method further includes communicating the address associated with the 4G service endpoint to the requesting node. The method further includes monitoring the FQDN for changes in the address associated with the FQDN. The method further includes notifying the requesting node of changes in the address associated with the FQDN.

Description

Technical Field

[0001] Related Applications This application claims the benefit of priority of U.S. Patent Application Serial No. 17 / 074,553, filed Oct. 19, 2020, and U.S. Patent Application Serial No. 16 / 555,817, filed Aug. 29, 2019, the disclosures of which are incorporated herein by reference in their entireties.

[0002] Technical Field The subject matter described herein relates to discovering address information associated with service endpoints in a telecommunications network. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for actively discovering and tracking addresses associated with 4G service endpoints.

Background Art

[0003] Background In a telecommunications network, a service endpoint is an address on a network node that uniquely identifies an entity that provides a service to a service consumer. A service endpoint can include an Internet Protocol (IP) address, or a combination of an IP address and a transport layer port number, also referred to as an IP endpoint.

[0004] In a 5G telecommunications network, a network node that provides a service is called a producer network function (NF). A network node that consumes a service is called a consumer NF. A network function can be both a producer NF and a consumer NF, depending on whether it is consuming or providing a service.

[0005] A given producer NF may have multiple service endpoints. The producer NF registers with the Network Function Repository Function (NRF). The NRF maintains the NF profiles of the available NF instances and their supported services. A consumer NF can subscribe to receive information about the producer NF instances registered with the NRF.

[0006] In addition to the consumer NF, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Proxy (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about the producer NF service instances. The consumer NF connects to the service communication proxy, and the service communication proxy load-balances traffic between the producer NF service instances that provide the requested service or routes the traffic directly to the destination producer NF.

Summary of the Invention

Problems to be Solved by the Invention

[0007] One problem with the existing 3GPP service architecture is that the consumer NF or SCP may have insufficient information to load-balance traffic between the service endpoints exposed by the producer NF service instances. In one scenario, the producer NF may register its FQDN only at the NF service level and not register the domain name, IP address, or IP endpoint of the producer NF service individually. In another scenario, the producer NF may register its FQDN only at the NF instance level and not register the IP address or IP endpoint or FQDN of the service individually at the NF service level.

[0008] In any of these scenarios, the consumer NF or SCP has to obtain the IP address or IP endpoint associated with the service endpoint in order to communicate with the individual service endpoint. Generally, the IP address or IP endpoint corresponding to a domain name can be determined using the Domain Name System (DNS). In the 5G network architecture described above, the service consumer needs to be notified of the service endpoint IP address whenever an NF registers or updates its profile. Another scenario where the consumer NF or SCP needs to be updated with the service's IP address or IP endpoint is when the IP address or IP endpoint changes without a corresponding NF profile or service update. There is no automated process to notify the service consumer when the IP address or IP endpoint associated with the service changes, even though the IP address or IP endpoint is discoverable through DNS.

[0009] An additional problem associated with network architectures that include both 4G service endpoints is the inability to actively discover and maintain the IP address information of 4G NFs and the service endpoints associated with the 4G NFs. Existing 4G service endpoint discovery procedures require each consumer NF (4G or 5G) to contact the DNS server directly to discover the 4G NF and detect changes in the 4G NF status information. Requiring each consumer NF to communicate directly with the DNS server can be a burden for the consumer NF because the consumer NF has to maintain a timer for the DNS response expiration period and re-query the DNS server when the DNS response expiration occurs. In addition, currently, DNS does not provide a mechanism for the consumer NF to detect when the 4G NF has scaled up or down. Furthermore, if the DNS server goes down, scales up, or scales down, each consumer NF has to be reconfigured.

[0010] In view of these and other problems, there is a need for an improved method for actively discovering and maintaining address information for 4G service endpoints and for non-transitory media.

Means for Solving the Problems

[0011] Summary A method for discovering and tracking an address associated with a 4G service endpoint includes receiving, at a requesting node, a first Domain Name System (DNS) resolution or monitoring request that includes a fully qualified domain name (FQDN) of the 4G service endpoint. The method further includes querying a DNS server using the FQDN extracted from the first DNS resolution or monitoring request. The method further includes receiving, from the DNS server, a first response that includes an address associated with the 4G service endpoint and storing the address associated with the 4G service endpoint in a database. The method further includes communicating the address associated with the 4G service endpoint to the requesting node. The method further includes monitoring the FQDN for changes in the address associated with the FQDN. The method further includes notifying the requesting node of changes in the address associated with the FQDN.

[0012] According to an aspect of the subject matter described herein, receiving the first DNS resolution request includes receiving the first DNS resolution request from a Diameter Relay Agent (DRA) or a Service Communication Proxy (SCP).

[0013] According to another aspect of the subject matter described herein, receiving the first DNS resolution request includes receiving the first DNS resolution request from a 4G or 5G consumer NF.

[0014] According to another aspect of the subject matter described herein, receiving a first DNS resolution request includes receiving the first DNS resolution request at a Representational State Transfer (REST) server interface provided by a DNS discovery microservice.

[0015] According to yet another aspect of the subject matter described herein, querying a DNS server includes querying the DNS server from a DNS discovery microservice separated from the consumer NF or SCP and the DNS server. In this context, "separated from" means that the DNS discovery microservice is realized on a computing platform that is separate from the consumer NF or SCP that needs to resolve domain names and also separate from the computing platform that hosts the DNS server. In an alternative implementation, the DNS discovery microservice may be realized on the same computing platform as the consumer NF or SCP.

[0016] According to yet another aspect of the subject matter described herein, storing an address associated with a producer NF service includes storing the address, along with the lifetime of each address received from the DNS server, in a database local to the DNS discovery microservice.

[0017] According to yet another aspect of the subject matter described herein, for all addresses received from the DNS server along with a lifetime value, when stored in a record in the database, a timer is started for the period received in the lifetime field.

[0018] According to yet another aspect of the subject matter described herein, monitoring the FQDN includes detecting expiration of a record that stores an address associated with the producer NF service in a database, querying a DNS server using the FQDN in response to detecting expiration of the record, receiving a second response from the DNS server, comparing the address in the second response with the address stored in the record in the database, and determining that a change has occurred in the address associated with the FQDN in response to the address in the second response being different from the address stored in the record in the database.

[0019] According to yet another aspect of the subject matter described herein, a 4G service endpoint includes an endpoint associated with a 4G evolved packet core (EPC) network node.

[0020] According to another aspect of the subject matter described herein, a 4G EPC network node comprises one of a serving gateway (S-GW), a home subscriber server (HSS), an offline charging system (OFCS), an online charging system (OCS), a mobility management entity (MME), a policy and charging rules function (PCRF), a packet gateway (P-GW), and other 4G NFs.

[0021] According to yet another aspect of the subject matter described herein, monitoring the FQDN for changes in the address includes continuously monitoring the FQDN for changes in the address until stopped in response to a message from a requesting node to stop monitoring the FQDN.

[0022] According to yet another aspect of the subject matter described herein, a message from a requesting node to stop monitoring the FQDN includes a DELETE method type and, in response, includes a second DNS resolution request to stop monitoring the FQDN.

[0023] According to yet another aspect of the subject matter described herein, the DNS discovery micro-service includes a Representational State Transfer (REST) server interface for the requesting node to stop monitoring the FQDN.

[0024] According to yet another aspect of the subject matter described herein, a system for discovering and tracking producer network function (NF) service endpoints comprises a computing platform including at least one processor. The system further comprises a Domain Name System (DNS) discovery micro-service located on the computing platform and implemented by at least one processor, the Domain Name System (DNS) discovery micro-service being operative to receive from a requesting node a first Domain Name System (DNS) resolution or monitoring request including a fully qualified domain name (FQDN) of a 4G service endpoint, query a DNS server using the FQDN of the 4G service endpoint, receive from the DNS server a first response including an address associated with the 4G service endpoint, store the address associated with the 4G service endpoint in a database, communicate the address associated with the 4G service endpoint to the requesting node, monitor the FQDN for changes in the address associated with the FQDN, and notify the requesting node of changes in the address associated with the FQDN.

[0025] According to yet another aspect of the subject matter described herein, the DNS discovery micro-service is configured to receive a first DNS resolution request from a Diameter Relay Agent (DRA) or a Service Communication Proxy (SCP).

[0026] According to yet another aspect of the subject matter described herein, the DNS discovery micro-service is configured for a first DNS resolution request from a 4G or 5G consumer NF.

[0027] According to yet another aspect of the subject matter described herein, the DNS discovery unit microservice includes a Representational State Transfer (REST) server interface for receiving a first DNS resolution request from a requesting node.

[0028] According to yet another aspect of the subject matter described herein, the computing platform and the DNS discovery unit microservice are separated from the requesting node and the DNS server.

[0029] According to another aspect of the subject matter described herein, the database is local to the DNS discovery unit microservice.

[0030] According to yet another aspect of the subject matter described herein, the DNS discovery unit microservice includes a DNS record change discovery unit, and the DNS record change discovery unit performs by detecting the expiration of a record storing an address associated with a 4G service endpoint in a database for monitoring a Fully Qualified Domain Name (FQDN), querying a DNS server using the FQDN in response to detecting the expiration of the record, receiving a second response from the DNS server, comparing the address in the second response with the address stored in the record in the database, and determining that a change has occurred in the address associated with the FQDN in response to the address in the second response being different from the address stored in the record in the database.

[0031] According to yet another aspect of the subject matter described herein, the DNS record change discovery unit is configured to continuously monitor the FQDN for changes in the address associated with the FQDN until it is stopped in response to a message from the requesting node for stopping the monitoring of the FQDN.

[0032] According to yet another aspect of the subject matter described herein, a non-transitory computer-readable medium storing executable instructions that, when executed by a computer's processor, control the computer to perform a plurality of steps is provided. The plurality of steps includes receiving, from a requesting node, a first Domain Name System (DNS) resolution or monitoring request that includes a fully qualified domain name (FQDN) of a 4G service endpoint. The plurality of steps includes querying a DNS server using the FQDN of the 4G service endpoint from the first DNS resolution or monitoring request. The plurality of steps further includes receiving, from the DNS server, a first response that includes an address associated with the 4G service endpoint. The plurality of steps further includes storing the address associated with the 4G service endpoint in a database. The plurality of steps further includes communicating the address associated with the 4G service endpoint to the requesting node. The plurality of steps further includes monitoring the FQDN for changes in the address associated with the FQDN. The plurality of steps further includes notifying the requesting node of changes in the address associated with the FQDN. The plurality of steps may further include any one or more of the steps described herein in any combination.

[0033] The subject matter described in this specification may be implemented in hardware, software, firmware, or any combination thereof. Accordingly, the terms "function," "node," or "module" as used herein refer to hardware, but they may also include software and / or firmware components for realizing the described features. In an exemplary implementation, the subject matter described herein may be realized using a computer-readable medium storing computer-executable instructions that, when executed by a processor of a computer, control the computer to perform a plurality of steps. Exemplary computer-readable media suitable for realizing 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. Additionally, the computer-readable media for realizing the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms.

[0034] Here, the subject matter described in this specification is described with reference to the accompanying drawings.

Brief Description of the Drawings

[0035]

Fig. 1A

Fig. 1B

Fig. 2

Fig. 3

Fig. 4

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Mode for Carrying Out the Invention

[0036] Detailed Description The subject matter described in this specification relates to a method, system, and computer-readable medium for discovering and actively tracking address information associated with 4G service endpoints. FIG. 1A is a block diagram showing an exemplary 5G system network architecture. The architecture of FIG. 1A includes an NRF100 and an SCP101 that may be located in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF100 maintains profiles of available producer NF service instances and the services they support, and may enable a consumer NF or SCP to subscribe to a new / updated producer NF service instance and be notified of its registration. The SCP101 may also support service detection and selection of producer NFs. In addition, the SCP101 may perform load distribution of connections between a consumer NF and a producer NF.

[0037] The NRF100 is a repository of NF profiles. To communicate with a producer NF, a consumer NF or SCP must obtain an NF profile from the NRF100. The NF profile is a JSON data structure defined in 3GPP TS29.510. Table 1 below shows the attributes of the NF profile defined in 3GPP TS 29.510.

[0038]

Table 1-1

[0039]

Table 1-2

[0040]

Table 1-3

[0041]

Table 1-4

[0042]

Table 1-5

[0043]

Table 1-6

[0044]

Table 1-7

[0045] As shown in Table 1, the NF profile definition includes at least one of a FQDN, an IP version 4 address, or an IP version 6 address. However, the NF profile does not have the requirement of including individual IP addresses or IP endpoints associated with the producer NF service endpoints located on the producer NF service instance.

[0046] In FIG. 1A, any node (other than SCP101 and NRF100) can become a consumer NF or a producer NF depending on whether they are requesting or providing services. In the illustrated example, the nodes include a policy control function (PCF) 102 that performs policy-related operations within the network, a user data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services. The node shown in FIG. 1A further includes a session management function (SMF) 108 that manages the session between the access and mobility management (AMF) function 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by the mobility management entity (MME) in a 4G network. The authentication server function (AUSF) 112 performs an authentication service for user equipment (UE) seeking access to the network, such as the UE 114.

[0047] The network slice selection function (NSSF) 116 provides a network slice service for devices attempting to access specific network functions and characteristics associated with a network slice. The network exposure function (NEF) 118 provides an application programming interface (API) for application functions attempting to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs functions similar to the service capability exposure function (SCEF) in a 4G network.

[0048] The Radio Access Network (RAN) 120 connects the UE 114 to the network via a wireless link. The Radio Access Network 120 can be accessed using a g Node B (gNB) (not shown in Figure 1A) or other radio access points. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such a proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support a performance measurement function that can be used by the UE 114 to obtain network performance measurements. Also shown in Figure 1A is a Data Network (DN) 124 to which the UE has access to data network services such as Internet services.

[0049] The address information associated with a service endpoint resident in any of the NFs illustrated in Figure 1A that provides a service can be tracked using the DNS discovery unit microservice described herein. In addition, non-5G service endpoints that provide services under a given FQDN can be discovered and tracked by the DNS discovery unit microservice described herein. Thus, as used herein, the term "producer NF service endpoint" shall refer to a service endpoint that exists in either a 5G or non-5G service provider node. Non-5G service provider nodes include 3G, 4G, or subsequent generation (post-5G) compliant service provider nodes and non-3GPP service provider nodes.

[0050] As described above, the producer NF registers those NF profiles with the NRF. The consumer NF can discover the producer NF registered to provide a specific service by obtaining the NF profile from the NRF. The consumer NF can communicate directly with the NF service producer NF. Alternatively, the consumer NF can communicate indirectly with the producer NF via the SCP. In the direct communication mode, the consumer NF discovers the target producer NF either by local configuration or via the NRF. The consumer NF then communicates directly with the target service producer NF. In the indirect communication mode, the consumer NF sends a service request message to the SCP, and the SCP may perform service discovery and selection of the producer NF on behalf of the consumer NF. In either the direct or indirect communication mode, the DNS discovery unit microservice described herein receives a DNS resolution request from the consumer NF or the SCP, queries the DNS server on behalf of the consumer NF or the SCP, communicates the address information associated with the producer NF service endpoint to the consumer NF or the SCP, and may continuously monitor the FQDN received in the DNS resolution request for changes in the address associated with the FQDN.

[0051] Figure 1B shows an exemplary 4G evolved packet core (EPC) network architecture having two different public land mobile networks (PLMNs). In Figure 1B, PLMN A 150 and PLMN B 152 are shown. PLMN A 150 includes a plurality of EPC network nodes. In the illustrated example, the EPC network nodes include a serving gateway (S-GW) 154, a home subscriber server (FISS) 156, an offline charging system (OFCS) 158, an online charging system (OCS) 160, other NFs 162, a mobility management entity (MME) 164, a policy and charging rules function (PCRF) 166, and a packet gateway (P-GW) 168. PLMN 152 may also include an NF 170 that may include any of the MNFs shown in 4G PLMN 150.

[0052] A network node attempting to obtain a service from 4G NF154~170 or a service endpoint on 4G NF154~170 depends on the DNS service 172 for service discovery and monitoring of changes in IP addresses. When a consumer, which may include any of the NFs illustrated in FIG. 1A or FIG. 1B, attempts to obtain a service from a 4G service endpoint, the consumer relies on DNS to determine the IP address of the endpoint. Using DNS reduces the need for manual configuration of service consumers at the IP addresses of 4G service endpoints, and when the mapping from FQDN to IP address changes, DNS handles such changes seamlessly, facilitating traffic migration from one instance of an NF to another. The DNS response can include a weight factor that can be set based on optional preferences for each IP endpoint. The NF can perform load balancing when the FQDN resolves to multiple IP addresses that identify multiple NF instances. For example, when a new instance of a P-GW is installed on the network, it would preferably be selected in an attempt to balance traffic with existing P-GW instances. The DNS response includes a validity timer for the received IP endpoint / address. These addresses are generally cached and used by the NF to avoid DNS queries for all new requests for this expiration period. Caching the IP address mapping for the DNS expiration period saves processing bandwidth and latency compared to querying the DNS server again for every new service request.

[0053] As described above, the problem with such an approach of discovering 4G service endpoints using DNS involves the fact that DNS responses come with a expiration period that must be tracked by each consumer NF in order to avoid DNS queries for each service request. This further burdens the consumer NF to maintain a timer for each resolved IP address. When the target NF scales up (i.e., increases the number of 4G service instances), there is no way to actively detect this situation, so additional IP endpoints and addresses are detected upon expiration. When the target NF scales down or (in the case of migration) changes its IP address, there is no way to detect this change seamlessly. Routing failures to dropped IP addresses trigger DNS rediscovery. The DNS server also goes out of service, either for maintenance or for reasons of scaling up or down. When this occurs, all NF instances that depend on the DNS service need to be reconfigured to communicate with the scaled-up or scaled-down DNS instance. To avoid these and other difficulties, the subject matter described herein includes a DNS microservice, which is described in more detail below.

[0054] One problem that occurs in the architecture illustrated in FIGS. 1A and 1B is that the service communication proxy, the Diameter relay agent (DRA), or the consumer NF may have insufficient information to perform load distribution among service endpoints resident on the 4G service instance. FIG. 2 shows this problem. Referring to FIG. 2, the service communication proxy 101 or the DRA 203 exists between the 4G or 5G consumer NFs 200 and 202 and the 4G producer NFs 204 and 206. For example, if the consumer NFs 200 and 202 are 4G NFs, the SCP 101 or the DRA 203 will include the DRA function, which includes routing Diameter messages based on the Diameter layer information in the message and delivering such messages to the 4G producer NFs 204 and 206. If the consumer NFs 200 and 202 are 5G NFs, the SCP 101 or the DRA 203 will include the SCP function, which includes routing 5G messages based on the IP addresses in the message. In either case, the SCP 101 or the DRA 203 (as well as the consumer NFs 200 and 202) may utilize the DNS discovery microservice described herein to resolve the FQDN to the IP address of the 4G service endpoint and monitor for changes in the mapping between the FQDN and the IP address of the 4G service endpoint. It is also possible that the SCP or the DRA 101 and 203 may include both the SCP function and the DRA function. The 4G producer NF 204 includes producer NF service endpoints 204A and 204B. The 4G producer NF service instance 206 includes producer NF service endpoints 206A and 206B.

[0055] During operation, consumers NF200 and 202 connect to service communication proxy 101 or DRA203, and service communication proxy 101 or DRA203 load-balances traffic between producer NF service endpoints. Service communication proxy 101 or DRA203 determines producer NF service endpoints for load-balancing from the above-mentioned NF profiles (in the case of 5G) or DNS (in the case of 4G) and NF service content (only in the case of 5G) registered by producer NFs 204 and 206 with NRF100. However, as described above, since it is not necessary to register address information associated with individual service endpoints, the load-balancing performed by SCP101 or DRA203 may not evenly distribute the load among service endpoints.

[0056] As described above, in one scenario, a producer NF service instance may only register a fully qualified domain name at the NF service level. In another scenario, the IP endpoint and the fully qualified domain name may not be registered at the NF service level, and only the fully qualified domain name may be registered at the NF instance level. In either of these scenarios, the service communication proxy lacks sufficient information for proper load-balancing.

[0057] A consumer NF, DRA, or service communication proxy can directly determine the IP endpoint of a service instance via a DNS-SRV record by an NF service or NF service instance. In another example, an IP address may be published by an NF service or NF service instance via a DNS A / AAAA record, and the port is taken as an SCP configuration.

[0058] The address of the producer NF service endpoint needs to be known to the consumer NF, DRA, or SCP whenever any NF registers or updates its registration. The address of the producer NF service endpoint also needs to be known whenever the IP address or IP endpoint changes without any NF profile or NF service update. The consumer NF, DRA, or SCP needs to track these changes for the purposes of continuous routing and load distribution. The DNS discovery microservice described herein discovers the address of the producer NF service endpoint and monitors for changes in the address associated with the FQDN for the FQDN.

[0059] As described above, the DNS discovery unit (DNS-D) microservice solves at least some of the problems related to the discovery and tracking of service endpoints. The DNS discovery unit microservice queries the DNS server to obtain the address information of the producer NF service endpoint and provides that information to the SCP, DRA, or consumer NF. FIG. 3 is a network diagram showing a network architecture including the DNS discovery unit microservice. Referring to FIG. 3, the DNS discovery unit microservice 300 can be separated from or implemented on the same computing platform as the SCP / DRA microservice or consumer NF 302. The DNS discovery unit microservice 300 includes a DNS discovery unit DNS client 304 that interfaces with an external DNS server 306. The DNS discovery unit microservice 300 also includes a database adapter 308 that maintains NF service endpoint information in a persistent database 310. The DNS discovery unit microservice 300 includes a DNS discovery unit server interface 312 that exposes the DNS discovery unit microservice to the SCP / DRA microservice or consumer NF 302 or a non-5G service consumer. In the illustrated example, the server interface 312 is a representational state transfer (REST) interface that interfaces with a REST client 314 provided by the SCP / DRA microservice or consumer NF 302. The DNS discovery unit microservice 300 further includes a DNS discovery unit REST client 316 that interfaces with the server interface 318 of the SCP / DRA microservice or consumer NF 302.

[0060] The DNS discovery unit microservice 300 can be used to solve the problems identified above. In one example, the DNS discovery unit microservice 300 can expose a REST / HTTP interface to listen for DNS resolution / monitoring requests from an SCP, DRA, 4G or 5G NF, or any other service consumer. When a DNS response is expected, the consumer sends the DNS request as an HTTP POST message along with a callback uniform resource identifier (URI). The DNS discovery unit microservice 300 is an asynchronous service and returns a 201 Created message indicating that the request has been received. The DNS discovery unit microservice 300 queries an external DNS server using the requested fully qualified domain name (FQDN). After successfully obtaining DNS resolution from these external DNS servers, the DNS discovery unit microservice 300 sends a DNS response to the callback URI received in the DNS resolution request as an HTTP PUT request. The DNS discovery unit microservice 300 caches / remembers the DNS query response from the external DNS server and the time to live (TTL) (received in the response from the DNS server) to enable DNS change monitoring (discussed below).

[0061] The DNS discovery unit microservice 300 continuously monitors all requested FQDNs for the TTL received in the DNS query response until stopped. The DNS response from the external DNS server is compared with the remembered response in all iterations. Differences are shown to the consumer as an HTTP PUT request at the callback URI. The consumer can choose to stop monitoring by sending an HTTP DELETE request message to the DNS discovery unit microservice 300.

[0062] FIG. 4 is a call flow diagram showing DNS request handling executed by the DNS discovery unit microservice 300. The DNS discovery unit microservice 300 includes the components shown in and described above with respect to FIG. 3. In addition to the components illustrated in FIG. 3, the DNS discovery unit microservice 300 includes a DNS record change discovery unit 400, which monitors the requested fully qualified domain name for the time-to-live value received in the DNS query response, and when the TTL expires, queries the DNS server 306 again and communicates changes at the resolved IP address or IP endpoint to the consumer NF, SCP, or non-5G service consumer.

[0063] Referring to the call flow of FIG. 4, at line 1, a DNS consumer such as the SCP / DRA microservice or the consumer NF 302 sends a DNS resolution request to the server interface of the DNS discovery unit microservice 300. The DNS resolution request includes the FQDN to be resolved, the DNS query type indicating the IP address or IP endpoint, the cookie identifier, and the callback URI for the DNS response and update to be sent to the querying DNS consumer on the DNS discovery unit REST client 316.

[0064] At line 2 of the call flow diagram, the DNS discovery unit server interface 312 receives the request and sends a response indicating that it has been received.

[0065] At line 3 of the call flow diagram, the DNS client component 304 of the DNS discovery unit microservice 300 sends a query to the external DNS server 306 to resolve the fully qualified domain name in the DNS resolution request.

[0066] In line 4 of the call flow diagram, the DNS server 306 responds to the DNS client 304 in response to the DNS query. This response may include one or more IP addresses or IP endpoints that exist on the producer NF service instance corresponding to the FQDN within the DNS query.

[0067] In line 5 of the call flow diagram, the DNS client component 304 communicates the IP address or IP endpoint information to the DNS discovery section database adapter 308, and the DNS discovery section database adapter 308 transfers the response to the persistent database 310. This response includes the fully qualified domain name from the DNS resolution request, the resolved IP address (or IP address and port depending on the type of response), and the expiration time which is the lowest TTL value among all the TTL values of the DNS resource records received in the query response.

[0068] In line 6, the DNS discovery section database adapter 308 sends a message indicating that the database record has been created to the DNS discovery section REST client 316, and the DNS discovery section client 316 sends the DNS response to the SCP microservice or consumer NF 302. The DNS response is sent on the callback URI received in the request. In line 7, the SCP / DRA microservice or consumer NF 302 sends a 200OK response to the DNS discovery section REST client 316.

[0069] The DNS record change discovery unit 400 detects changes in the resolved IP address or IP endpoint corresponding to the monitored FQDN. The DNS record change discovery unit 400 can periodically fetch all DNS records from storage and identify records for which the TTL received in the DNS query response has elapsed. For each record for which the TTL has elapsed, the DNS record change discovery unit 400 can query an external DNS server again to determine if any changes have occurred. If any changes have occurred, no further action is required. If a change has occurred, the DNS record change discovery unit 400 may notify the consumer NF or SCP subscribed to a given service via a REST / HTTP PUT request with the callback URI received in the original DNS request. FIG. 5 is a call flow diagram showing the DNS change monitoring call flow. Referring to FIG. 5, at line 1, the DNS record change discovery unit 400 calculates the current timestamp. At line 2, the DNS record change discovery unit 400 queries the persistent database 310 for all records having an elapsed TTL or expiration time. At line 3 of the call flow diagram, the persistent database 310 returns the DNS records for which the call flow has elapsed to the DNS record change discovery unit 400.

[0070] In line 4 of the call flow diagram, the DNS record change discovery unit 400 notifies each FQDN for which the TTL has elapsed to the DNS discovery unit client 304. In line 5, the DNS discovery unit client 304 queries the external DNS server 306 about each FQDN for which the TTL has elapsed. In line 6 of the call flow diagram, the DNS discovery unit DNS client 304 receives a DNS query response for each FQDN queried in line 5. In line 7, the DNS discovery unit DNS client 304 notifies the DNS record change discovery unit of the IP address or IP endpoint received in the response in line 6. The DNS record change discovery unit 400 determines whether the received IP address or IP endpoint matches the data stored for each FQDN. If the IP address or IP endpoint matches, no further action is required on the part of the DNS record change discovery unit 400. However, if the IP address or IP endpoint does not match, in line 8, the DNS record change discovery unit 400 communicates the changed IP address or IP endpoint to the DNS discovery unit REST client 316. The DNS discovery unit REST client 316 uses an HTTP put request with the callback URI received in the original request to notify the SCP / DRA microservice or consumer NF302 of the change at the IP address or IP endpoint. In line 9 of the call flow diagram, the SCP / DRA microservice or consumer NF302 acknowledges receipt of the DNS response in line 8.

[0071] Another operation performed by the DNS discovery unit microservice 300 is, for example, to stop DNS monitoring when a 4G or 5G consumer NF, DRA, or SCP notifies the DNS discovery unit microservice 300 that it wishes to stop monitoring a given FQDN. FIG. 6 shows such a call flow. Referring to the call flow of FIG. 6, at line 1, the DRA / SCP microservice or consumer NF 302 has an FQDN to be resolved and sends a DNS resolution request specifying a deletion method to stop DNS monitoring for the FQDN. At line 2 of the call flow diagram, the DNS discovery unit server interface 312 responds to the client, indicating that the request has been accepted. At line 3 of the call flow diagram, the DNS discovery unit server interface 312 notifies the DNS discovery unit database adapter 308 that the consumer wishes to stop monitoring the FQDN. The DNS discovery unit database adapter 308 sends a message to the persistent database 310 to remove or update the record corresponding to the FQDN and notification URL specified in the original DNS resolution request from the persistent database 310. The message at line 3 stops the DNS record change discovery unit 400 from querying the DNS server 306 again about the FQDN for this particular consumer.

[0072] FIG. 7 is a block diagram showing an exemplary architecture for a computing platform including the DNS discovery unit microservice 300. Referring to FIG. 7, the computing platform 700 includes at least one processor 702 and a memory 704. The DNS discovery unit microservice 300 may be implemented by executable instructions embodied in the memory 704. In the illustrated example, the DNS discovery unit microservice 300 includes a DNS discovery unit server interface 312, a DNS discovery unit DNS client 304, a DNS discovery unit REST client 316, a DNS discovery unit database adapter 308, and a DNS record change discovery unit 400. A persistent database 310 may also reside within the computing platform 700 to store IP addresses or IP endpoints for the resolved FQDNs.

[0073] FIG. 8 is a flowchart showing an exemplary process for actively discovering and tracking address information associated with 5G and non-5G service endpoints. Referring to FIG. 8, at step 800, a DNS resolution or monitoring request is received from a requesting node. For example, the DNS discovery unit microservice 300 may receive a DNS resolution or monitoring request along with an FQDN from a DNS discovery unit consumer such as an SCP, DRA, 4G NF, or 5G NF. The DNS resolution or monitoring request may include the FQDN of a 4G service endpoint.

[0074] At step 802, the DNS server is queried using the FQDN within the DNS resolution request. For example, the DNS discovery unit microservice 300 can query an external DNS server 306 using the FQDN in the DNS request received from the DNS discovery unit consumer.

[0075] In step 804, a DNS response is received from the DNS server, and in step 806, the address of the 4G service endpoint is stored in the DNS discovery unit database (i.e., in the persistent database 310). For example, the DNS discovery unit microservice 300 may receive a DNS response from the DNS server 306 and store in the database 310 the IP address or IP endpoint associated with the producer NF service endpoint. In one example, the DNS resolution request from the DNS discovery unit microservice 300 may be a DNS-A resolution request, and the DNS server 306 may return one or more IPv4 addresses corresponding to one or more service endpoints associated with the FQDN. In another example, the DNS resolution request may be a DNS-AAAA request, and the DNS server 306 may return one or more IPv6 addresses corresponding to one or more service endpoints associated with the FQDN. In yet another example, the DNS resolution request may be a DNS-SRV request, and the DNS server may return the IP address and port number corresponding to one or more service endpoints associated with the FQDN.

[0076] In step 808, the DNS response is sent to the requesting node. For example, the DNS discovery unit microservice 300 may send a response containing the address associated with the producer NF service endpoint received in the DNS response from the DNS server 306 to the requesting node.

[0077] In step 810, the FQDN in the DNS discovery unit database is monitored for changes in the address. For example, the DNS record change discovery unit 400 can query the external DNS server 306 for each FQDN in the database 310 whose TTL has expired to determine any IP address or IP endpoint changes.

[0078] In step 812, the requesting node is notified of any changes in the IP address or IP endpoint associated with the FQDN. For example, the DNS record change discovery unit 400 can notify the SCP / DRA microservice or the consumer NF302 of any detected changes in the IP address or IP endpoint associated with the FQDN that the SCP / DRA microservice or the consumer NF302 queried the DNS discovery unit microservice 300 for.

[0079] Accordingly, the subject matter described herein includes a DNS discovery unit microservice that discovers an IP address or IP endpoint associated with a 4G service endpoint and monitors the FQDN for changes in such an address. One advantage of such a service is the fact that 4G and 5G consumer NFs, DRA, and SCP do not need to discover or actively monitor the 4G NF for changes in the IP address or IP endpoint associated with the service. The consumer NF, DRA, or SCP only needs to know the FQDN of the service and communicate that FQDN to the DNS discovery unit microservice. Additionally, since the DNS discovery unit microservice actively monitors the FQDN for changes in the IP address or IP endpoint, the load distribution by nodes such as DRA, SCP, and 4G and 5G consumer NFs will be more evenly distributed among the producer NF service endpoints.

[0080] It will be understood that various details of the subject matter of the present disclosure may be changed without departing from the scope of the subject matter of the present disclosure. Further, the foregoing description is for purposes of illustration only and not for purposes of limitation.

Claims

1. A method for discovering and tracking an address associated with a 4G service endpoint, comprising: Receiving, from a requesting node, a first Domain Name System (DNS) resolution or monitoring request including a fully qualified domain name (FQDN) of the 4G service endpoint; Querying a DNS server using the FQDN of the 4G service endpoint extracted from the first DNS resolution or monitoring request; Receiving a first response from the DNS server, the first response including an address associated with the 4G service endpoint associated with the FQDN, the method further comprising: Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; Notifying the requesting node of the change in the address associated with the FQDN, wherein receiving the first DNS resolution or monitoring request from the requesting node includes receiving the first DNS resolution or monitoring request from a Diameter Relay Agent (DRA) or a Service Communication Proxy (SCP).

2. A method for discovering and tracking an address associated with a 4G service endpoint, comprising: Receiving, from a requesting node, a first Domain Name System (DNS) resolution or monitoring request including a fully qualified domain name (FQDN) of the 4G service endpoint; Querying a DNS server using the FQDN of the 4G service endpoint extracted from the first DNS resolution or monitoring request; Receiving a first response from the DNS server, the first response including an address associated with the 4G service endpoint associated with the FQDN, the method further comprising: Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; notifying the requesting node of the change in the address associated with the FQDN, Receiving the first DNS resolution or monitoring request from the requesting node includes receiving the first DNS resolution or monitoring request from a 4G or 5G consumer NF. A method. **Claim 3** A method for discovering and tracking an address associated with a 4G service endpoint, comprising: receiving, from a requesting node, a first domain name system (DNS) resolution or monitoring request including a fully qualified domain name (FQDN) of a 4G service endpoint; querying a DNS server using the FQDN of the 4G service endpoint extracted from the first DNS resolution or monitoring request; receiving a first response from the DNS server, the first response including an address associated with a 4G service endpoint associated with the FQDN, the method further comprising: storing the address associated with the 4G service endpoint in a database; communicating the address associated with the 4G service endpoint to the requesting node; monitoring the FQDN for changes in the address associated with the FQDN; notifying the requesting node of the change in the address associated with the FQDN; Monitoring the FQDN includes: detecting expiration of a record storing the address associated with the 4G service endpoint in the database; in response to detecting expiration of the record, querying the DNS server using the FQDN; receiving a second response from the DNS server; comparing the address in the second response with the address associated with the FQDN stored in the record in the database; determining that a change has occurred in the address associated with the FQDN in response to the address in the second response being different from the address associated with the FQDN stored in the record in the database. A method. **Claim 4** A method for discovering and tracking an address associated with a 4G service endpoint, comprising: Receiving, from a requesting node, a first Domain Name System (DNS) resolution or monitoring request that includes a fully qualified domain name (FQDN) of a 4G service endpoint; Querying a DNS server using the FQDN of the 4G service endpoint extracted from the first DNS resolution or monitoring request; Receiving a first response from the DNS server, the first response including an address associated with the 4G service endpoint associated with the FQDN, the method further comprising: Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; Notifying the requesting node of the change in the address associated with the FQDN; Monitoring the FQDN for changes in the address includes continuously monitoring the FQDN for changes in the address until stopped in response to a message from the requesting node that stops monitoring the FQDN, a method.

5. Querying the DNS server includes querying the DNS server from a DNS discovery unit microservice separated from the requesting node and the DNS server, the method according to any one of claims 1 to 4.

6. Storing the address associated with the 4G service endpoint includes storing the address in a database local to the DNS discovery unit microservice, the method according to claim 5.

7. The 4G service endpoint includes an endpoint associated with a 4G evolved packet core (EPC) network node, the method according to any one of claims 1 to 6.

8. The 4G EPC network node includes one of a serving gateway (S-GW), a home subscriber server (HSS), an offline charging system (OFCS), an online charging system (OCS), a mobility management entity (MME), a policy and charging rules function (PCRF), and a packet gateway (P-GW), the method according to claim 7.

9. A system for discovering and tracking an address associated with a 4G service endpoint, a computing platform including at least one processor, and a domain name system (DNS) discovery unit microservice located on the computing platform and implemented by the at least one processor, the domain name system (DNS) discovery unit microservice receives a first domain name system (DNS) resolution or monitoring request from a requesting node, queries a DNS server using a fully qualified domain name (FQDN) of a 4G service endpoint from the first DNS resolution or monitoring request, receives from the DNS server a first response including an address associated with the 4G service endpoint associated with the FQDN, stores the address associated with the 4G service endpoint in a database, communicates the address associated with the 4G service endpoint to the requesting node, monitors the FQDN for changes in the address associated with the FQDN, and is implemented for notifying the requesting node of the change in the address associated with the FQDN, wherein the DNS discovery unit microservice is configured to receive the first DNS resolution or monitoring request from a Diameter relay agent (DRA) or a service communication proxy (SCP).

10. A system for discovering and tracking an address associated with a 4G service endpoint, a computing platform including at least one processor, and a domain name system (DNS) discovery unit microservice located on the computing platform and implemented by the at least one processor, the domain name system (DNS) discovery unit microservice receives a first domain name system (DNS) resolution or monitoring request from a requesting node, queries a DNS server using a fully qualified domain name (FQDN) of a 4G service endpoint from the first DNS resolution or monitoring request, Receiving, from the DNS server, a first response including an address associated with the 4G service endpoint associated with the FQDN; Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; Implemented for notifying the requesting node of the change in the address associated with the FQDN; The DNS discovery unit microservice is configured to receive the first DNS resolution or monitoring request from a 4G or 5G consumer NF, a system. [

11. ] A system for discovering and tracking an address associated with a 4G service endpoint, comprising: A computing platform including at least one processor; A domain name system (DNS) discovery unit microservice located on the computing platform and implemented by the at least one processor, the domain name system (DNS) discovery unit microservice comprising: Receiving a first domain name system (DNS) resolution or monitoring request from a requesting node; Querying a DNS server using the fully qualified domain name (FQDN) of the 4G service endpoint from the first DNS resolution or monitoring request; Receiving, from the DNS server, a first response including an address associated with the 4G service endpoint associated with the FQDN; Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; Implemented for notifying the requesting node of the change in the address associated with the FQDN; The DNS discovery unit microservice includes a DNS record change discovery unit for performing monitoring of the FQDN, and the DNS record change discovery unit monitors the FQDN, Detecting expiration of a record storing the address associated with the 4G service endpoint in the database; In response to detecting expiration of the record, querying the DNS server using the FQDN; Receiving a second response from the DNS server; Comparing the address in the second response with the address associated with the 4G service endpoint stored in the record in the database; Determining that a change has occurred in the address associated with the FQDN in response to the address in the second response being different from the address associated with the 4G service endpoint stored in the record in the database, a system performed by.

12. A system for discovering and tracking an address associated with a 4G service endpoint, comprising: A computing platform including at least one processor; A domain name system (DNS) discovery unit microservice located on the computing platform and implemented by the at least one processor, the domain name system (DNS) discovery unit microservice comprising: Receiving a first domain name system (DNS) resolution or monitoring request from a requesting node; Querying a DNS server using the fully qualified domain name (FQDN) of the 4G service endpoint from the first DNS resolution or monitoring request; Receiving a first response from the DNS server including an address associated with the 4G service endpoint associated with the FQDN; Storing the address associated with the 4G service endpoint in a database; Communicating the address associated with the 4G service endpoint to the requesting node; Monitoring the FQDN for changes in the address associated with the FQDN; Realized for notifying the requesting node of the change in the address associated with the FQDN, The DNS discovery unit microservice includes a DNS record change discovery unit for performing monitoring of the FQDN, The DNS record change discovery unit is configured to continuously monitor the FQDN for changes in the address until it is stopped in response to a message from the requesting node that stops the monitoring of the FQDN, system.

13. The DNS discovery unit microservice includes a Representational State Transfer (REST) server interface for receiving the first DNS resolution or monitoring request from the requesting node, the system according to any one of claims 9 to 12.

14. The computing platform and the DNS discovery unit microservice are separated from the requesting node and the DNS server, the system according to any one of claims 9 to 13.

15. The database is local to the DNS discovery unit microservice, the system according to claim 14.

16. The 4G service endpoint includes an endpoint associated with a 4G evolved packet core (EPC) network node, the system according to any one of claims 9 to 15.

17. The 4G EPC network node includes one of a serving gateway (S-GW), a home subscriber server (HSS), an offline charging system (OFCS), an online charging system (OCS), a mobility management entity (MME), a policy and charging rules function (PCRF), and a packet gateway (P-GW), the system according to claim 16.

18. A computer program for causing a computer processor to execute the method according to any one of claims 1 to 8.

Images