Method for identifying services suitable for edge grooming and suitable for service steering in a mobile network

Abstract

The present disclosure relates to a method performed in a Domain Name System (DNS) proxy, and to a DNS proxy, device or system for application server (AS) discovery for edge computing in a mobile network. The method includes receiving a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE). Based on the FQDN, retrieve the location of the UE that sent the DNS query; add (one or more) subnets or (one or more) full IP addresses for accessing one or more preferred locations of a data network (DN) in the DNS query as one or more DNS extension mechanism (EDNS) client subnet (ECS) options; forward the DNS query to a mobile network operator (MNO) DNS; receive a DNS response, and determine the AS site and (one or more) AS IP addresses based on the DNS response; request business steering and send a DNS response to the UE.

Description

[0001] Priority declaration

[0002] This patent application claims priority based on the previous U.S. provisional patent application with application number 62 / 910,767 (titled "DYNAMIC ACTIVATION OF LOCAL BREAKOUT WITH COORDINATION BETWEEN APPLICATION DOMAIN AND MOBILE NETWORK", filed on October 4, 2019 in the name of Jan Backman and Jari Vikberg). This patent application also claims priority based on the previous PCT application with application number PCT / CN2019 / 126159 (titled "METHOD FOR IDENTIFICATION OF TRAFFIC SUITABLE FOR EDGE BREAKOUT AND FOR TRAFFIC STEERING IN A MOBILE NETWORK", filed on December 18, 2019 in the name of Maria Luisa Mas Rosique, Attila Mihaly, Jan Backman and Wenliang Xu). Technical Field

[0003] The present disclosure relates to edge computing and traffic steering in mobile networks. Background Art

[0004] Edge computing is a network architecture concept that enables cloud computing capabilities and service environments to be deployed at the edge of cellular networks. It promises several benefits, such as lower latency, higher bandwidth, reduced backhaul traffic, and the possibility of several new services.

[0005] Domain Name System (DNS)

[0006] The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with the domain name assigned to each of the participating entities. Most notably, it converts easier-to-remember domain names into the numeric Internet Protocol (IP) addresses required to locate and identify computer services and devices using the underlying network protocols.

[0007] The Domain Name System is defined by the Internet Engineering Task Force (IETF) and specifies the technical functionality of the database service at its core. It defines the DNS protocol as part of the Internet Protocol Suite, i.e., the detailed specifications of the data structures and data communication exchanges used in the DNS.

[0008] The Internet maintains two main name spaces, the domain name hierarchy (3GPP TS23.501v.16.2.0 System Architecture for the 5G System (5GS); Stage 2, Release 16) and the Internet Protocol (IP) address space (RFC 7871, Client Subnet in DNS Queries, C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari, May 2016). The domain name system maintains the domain name hierarchy and provides translation services between it and the address space. A DNS name server is a server that stores DNS records for a domain; a DNS name server responds to queries to its database with an answer.

[0009] The following aspects are mentioned in this article:

[0010] Stub Resolver: A simple DNS protocol implementation on the client side as described in RFC1034 Section 5.3.1.

[0011] Authoritative Nameserver: A name server that is authoritative for one or more DNS zones. These are not usually contacted directly by stub resolvers or end-user clients, but rather by recursive resolvers, as described in RFC1035 section 6.

[0012] Recursive resolver: A name server responsible for resolving a client's domain name by following the domain's delegation chain. Recursive resolvers frequently use a cache in order to be able to respond quickly to client queries, as described in RFC1035 Section 7.

[0013] Forwarding resolver: Passes that responsibility to another recursive resolver (called a "forwarder"), as described in RFC2308, section 1.

[0014] Intermediate name server: Any name server between a stub resolver and an authoritative name server, such as a recursive resolver or a forwarding resolver.

[0015] DNS is the most common mechanism for application clients to discover the IP addresses of applications on the Internet. It allows users to handle application host names and have them converted to the IP addresses of application servers.

[0016] Today, DNS can return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location. Since most queries come from intermediate recursive resolvers, the source address is the address of the recursive resolver rather than the address of the query originator. Traditionally, and probably still in most cases, the recursive resolver is fairly close to the query originator in a topological sense. For these resolvers, it is sufficient to use their own IP addresses to tailor the authoritative name servers that respond based on the location of the queryer.

[0017] RFC 7871: Client Subnet in DNS Queries

[0018] To address the situation where the recursive resolver is not topologically close to the query originator, the IETF has defined RFC7871. This document defines the EDNS0 (i.e., DNS extensions according to RFC6891) option to convey network information associated with a DNS message. It can carry sufficient network information about the originator for the authoritative name server to customize the response. It also specifies that the authoritative name server indicates the range of network addresses for which the customized answer is expected.

[0019] RFC 7871 defines the format and protocol handling of edns-client-subnet, also known as the Extensions to DNS (EDNS) Client Subnet (ECS) EDNS0 option. That is meant to be sent in queries sent by intermediate name servers in a way that is transparent to the query originator (e.g., stub resolver) and to the end user. An authoritative name server may use the ECS as a hint to the end user's network location and provide a better response. Its response will also contain the ECS option, explicitly instructing the server to utilize this information and that the response is tied to the client's network. The ECS option in the response is expected to guide caching of the provided response.

[0020] This protocol uses the EDNS0 option defined in RFC6891 to include client address information in DNS messages. Option 100 is as follows: Figure 1 As shown and constructed as described below.

[0021] The OPTION-CODE (2 octets) of ECS is 8 (0x000x08) (defined in RFC6891).

[0022] OPTION-LENGTH (2 octets) contains the length of the payload (everything after OPTION-LENGTH), in octets, (defined in RFC6891).

[0023] FAMILY (2 octets) indicates the family of the address contained in the option, using the address family code as assigned by the Internet Assigned Numbers Authority (IANA) in Address Family Numbers [Address_Family_Numbers]. The format of the address portion depends on the value of FAMILY. This document defines only the formats for FAMILY 1 (IPv4) and FAMILY 2 (IPv6) as described below.

[0024] SOURCE PREFIX-LENGTH, unsigned octet, represents the number of leftmost significant bits of the ADDRESS that will be used for the lookup. In the response, it reflects the same value as in the query.

[0025] SCOPE PREFIX-LENGTH, unsigned octet, indicating the number of left-most significant bits of the ADDRESS covered by the response. In queries, it MUST be set to 0.

[0026] ADDRESS (variable number of octets) contains either an IPv4 or IPv6 address, depending on FAMILY, which must be truncated to the number of bits indicated by the SOURCE PREFIX-LENGTH field, or padded with zero bits to the end of the last octet required.

[0027] Edge computing in 3GPP

[0028] The 5G network architecture is defined in 3GPP Release 16. Figure 2a A 5G reference architecture 200 as defined by 3GPP TS 23.501 is shown.

[0029] It is worth emphasizing the role of some of the network functions shown in this diagram.

[0030] The Session Management Function (SMF) is responsible for session establishment, modification and release, including the selection and control of the User Plane Function (UPF) entity, maintaining the topology of the involved Protocol Data Unit (PDU) Session Anchor (PSA) UPF, establishing and releasing tunnels between the Access Network (AN) and UPF and between UPFs. It also configures service forwarding at the UPF. The SMF interacts with the UPF over the N4 reference point using the Packet Forwarding Control Protocol (PFCP) process.

[0031] The User Plane Function (UPF) handles user data traffic. It also provides an external PDU session point (PDU session anchor) for interconnection to the data network, and performs packet routing and forwarding (e.g., support for uplink classifier (UL CL) to route traffic flows to instances of the data network, support for branching points to support multi-homed PDU sessions).

[0032] As described in TS 23.501 clause 5.13, edge computing enables operators and third-party services to be hosted close to the attachment access point of the user equipment (UE) to achieve efficient service delivery with reduced end-to-end latency and load on the transport network. The 5G core network selects a UPF close to the UE and performs traffic steering from the UPF to the local data network via the N6 interface.

[0033] Several enablers have been defined that, alone or in combination, support edge computing (Chapter 5.13 in TS 23.501), including the following.

[0034] User plane (re)selection: The 5G core network (re)selects the UPF that routes user traffic to the local data network, as described in clause 6.3.3.

[0035] Local routing and traffic steering: The 5G Core Network selects traffic to be routed to applications in the local data network, which includes the use of a single PDU Session with multiple PDU Session Anchors (UL CL / IP v6 multi-homing), as described in clause 5.6.4.

[0036] A PDU Session has multiple PDU Session Anchors (PSAs) when it has more than one access to the same data network (ie, N6 interface).

[0037] The Data Network (DN) Access Identifier (DNAI) identifies the location of the N6 access to the DN. It is mainly used in the process of directing a service to the local access of the DN in anticipation of affecting a service.

[0038] Uplink Classifier (UL CL)

[0039] One reason to have a single PDU Session with multiple PDU Session Anchors (UL CL / IP v6 multi-homing) is to do selective traffic routing to the DN and be able to direct traffic differently for different applications (i.e. different applications can access the data network at different locations).

[0040] TS 23.501 chapter 5.6.4.2 describes the use of the Uplink Classifier (UL CL) for PDU Sessions. The SMF may decide to insert the UL CL during or after the establishment of a PDU Session. The UL CL is intended to (locally) transfer certain services that match a service filter provided by the SMF. The insertion and removal of the UL CL is decided by the SMF and controlled by the SMF using the N4 reference point. When the ULCL functionality has been inserted into the data path of a PDU Session, multiple PDU Session Anchors exist for this PDU Session. These PDU Session Anchors provide different accesses to the same DN, such as Figure 2b as shown in .

[0041] The UL CL provides forwarding of UL traffic to different PDU Session Anchors and merging of downlink (DL) traffic to the UE, i.e., merging traffic from different PDU Session Anchors on the link to the UE. This is based on traffic detection and traffic forwarding rules provided by the SMF. The UL CL applies filtering rules (e.g. to check the destination IP address / prefix of the UL IP packet sent by the UE) and determines which PDU Session Anchor the packet should be routed to. Once the UL CL has been inserted, all traffic for the PDU session passes through that UL CL. Summary of the invention

[0042] A method performed in a domain name system (DNS) proxy for application server (AS) discovery and service steering for edge computing in a mobile network. The method includes receiving a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE). The method includes: when determining that a service level agreement (SLA) is in place for the application corresponding to the FQDN, obtaining the location of the UE that sent the DNS query from a control plane. The method includes adding at least one subnet or full IP address of one or more preferred locations for accessing a data network (DN) as one or more DNS extension mechanism (EDNS) client subnet (ECS) options in the DNS query. The method includes forwarding the DNS query to a mobile network operator (MNO) DNS. The method includes receiving a DNS response, the DNS response including an ECS option, the ECS option being customized for a corresponding ECS ​​option of the one or more ECS options in the DNS query. The method includes triggering an action to establish service steering in accordance with the ECS option received in the DNS response. The method includes removing the ECS option from the DNS response and sending the DNS response to the UE.

[0043] A method is provided for performing in a Domain Name System (DNS) proxy for identifying services suitable for edge breakout and suitable for service orientation in a mobile network, the method comprising: receiving a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE); upon determining that edge computing is applicable to the DNS query, adding one or more Internet Protocol (IP) addresses, IP address ranges, or IP subnets to the DNS query as one or more Extended DNS (EDNS) Client Subnet (ECS) options, corresponding to one or more preferred locations for access to a data network (DN); and forwarding the DNS query. In this context, an IP subnet is a subset of an IP address, i.e., some of the bits of an IP address, starting at the beginning of the address, at the most significant bit (MSB). When a DNS query is forwarded, it is forwarded to the next DNS in the architecture. For addresses outside the network, it can be forwarded to a dedicated forwarder.

[0044] A device or system is provided for identifying services suitable for edge grooming and suitable for service steering in a mobile network, the device or system comprising a processing circuit and a memory, the memory containing instructions executable by the processing circuit, whereby the device or system is operable to perform any of the steps described herein.

[0045] A Domain Name System (DNS) proxy is provided for identifying services suitable for edge grooming and suitable for service steering in a mobile network, operable to perform any of the steps described herein.

[0046] A device or system is provided for application server (AS) discovery for edge computing in a mobile network, the device or system comprising a processing circuit and a memory, the memory containing instructions executable by the processing circuit, whereby the device or system is operable to perform any of the steps described herein.

[0047] A Domain Name System (DNS) proxy is provided for application server (AS) discovery for edge computing in a mobile network, operable to perform any of the steps described herein.

[0048] A non-transitory computer readable medium having stored thereon instructions for performing any of the steps of the method described herein is provided.

[0049] The methods and DNS proxies, devices or systems provided herein present improvements to the way edge computing operates. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1is a schematic illustration of the structure of the EDNS0 [RFC6891] option that contains client address information in a DNS message.

[0051] Figure 2a is a schematic diagram of the fifth generation (5G) network architecture.

[0052] Figure 2b is a schematic diagram of the user plane architecture of the uplink classifier.

[0053] Figure 3 is a schematic diagram of a Mobile Network Operator (MNO) central Domain Name System (DNS) being selected by a customized application server.

[0054] Figure 4 is a schematic diagram of application server selection where the local site DNS is customized.

[0055] Figure 5 is a schematic diagram of edge AS discovery and dynamic UL CL insertion based on enhanced MNO / service provider collaboration.

[0056] Figure 6 is a diagram of configuring business orientation when the DNS proxy is deployed as part of the UPF.

[0057] Figure 7 is a flow chart illustrating DNS proxy functionality.

[0058] Figure 8a A flow chart of a method performed in a Domain Name System (DNS) proxy for identifying services suitable for edge grooming and suitable for service steering in a mobile network.

[0059] Figure 8b A flow chart of a method performed in a Domain Name System (DNS) proxy for application server (AS) discovery for edge computing in a mobile network.

[0060] Figure 8c Another flow chart of a method performed in a Domain Name System (DNS) proxy for application server (AS) discovery for edge computing in a mobile network.

[0061] Fig. 9 is a schematic diagram of a virtualization environment in which the different method(s) and device(s) described herein can be deployed. DETAILED DESCRIPTION

[0062] Various features will now be described with reference to the accompanying drawings to fully convey the scope of the present disclosure to those skilled in the art.

[0063] Sequences of actions or functions may be used within the present disclosure. It will be appreciated that in some contexts, some functions or actions may be performed by dedicated circuits, by program instructions executed by one or more processors, or by a combination of both.

[0064] Further, the computer readable carrier or carrier wave may embody a suitable set of computer instructions for causing a processor to perform the techniques described herein.

[0065] Function / action described herein may not occur in the order described in the action sequence or may occur simultaneously. In addition, in some diagrams, some blocks, functions or actions may be optional and may or may not be performed; These are generally shown with dotted lines.

[0066] A DNS core component called a DNS proxy (which may alternatively be called a DNS server, a DNS service, a DNS application function (AF) (DNS AF) or any other appropriate name) is used to identify what services may be the subject of edge grooming. When edge computing is applied to a DNS query, the DNS proxy uses some extensions defined by the DNS (EDNS client subnet) to add information to the DNS query, i.e., a list of possible locations for DN access. When this information is added to the DNS query, in resolving the DNS, the information can be used to customize the DNS response. The DNS response can also include ECS options that correspond to the ECS options from the query for which the customized response is intended. In this way, when a DNS response is received in the DNS proxy, the response corresponds to the ECS options, and the DNS proxy can tune the service orientation to meet the DNS response.

[0067] For example, when a user wants to connect to a service on the Internet, the user first enters or requests the location of the service (e.g., domain.com), and then retrieves the IP address. If some special handling is to be performed in response to some queries for domain.com, the DNS proxy investigates the domain name, fully qualified domain name (FQDN), domain.com (they can take different forms), and can determine whether there is a special handling for DNS queries for that particular business. Today, DNS can return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location. Not all DNS queries are sent to the edge, because the edge should not be called unless there is a running business therein; and one way to have a DNS response to the edge is to perform DNS business diversion from the edge. Since diversion consumes expensive resources at the edge and adds additional hops to all user PDU session data services, it should only be performed when necessary. DNS should not always be performed from the edge, and this is why a more centralized DNS proxy is recommended for handling DNS queries (also known as DNS requests).

[0068] In earlier technologies, when a user connects to a mobile network using a device, an IP address is assigned to the device, and even if the user changes location (even for long distances), the IP address remains the same, and this is generally the case until the device is disconnected for a period of time or until the device is rebooted. This is called having a central anchor point, and the IP addresses are provided by, for example, a national site. With the fourth and fifth generation mobile networks, the concept of distributed anchor points was introduced, where regional sites assign IP addresses to devices. Functionality was also introduced that allows the device to be forced to reconnect when the device is out of the area of ​​the anchor or the area of ​​the IP address assigned to it. This provides the device with the ability to access neighboring services. However, this reconnection means that the device is disconnected when the new IP address is assigned. All ongoing data services are lost, and all applications need to re-register, etc.

[0069] With 3GPP standardized session breakout, there is a centralized anchor and local site in the network that takes over or "steels" part of the traffic and sends it to local services. With this type of session breakout, one disadvantage is that all traffic must go through the local site in order to decide which traffic to breakout.

[0070] Provided herein is a version of session grooming where a DNS query is made to a DNS proxy in a centralized site, which detects domain names for which edge computing may be available, and looks at the response from the DNS server to see if something needs to be groomed on the edge. Going through edge sites is done to optimize the data path between the UE and the selected (as in the DNS response) edge application.

[0071] As mentioned previously, the UL CL provides forwarding of UL traffic to different PDU Session Anchors and merging of downlink (DL) traffic to the UE, i.e., merging traffic from different PDU Session Anchors on the link to the UE. Having an uplink classifier inserted into a PDU session consumes operator resources at the edge. For this reason, dynamic insertion of the UL Cl is preferred: by inserting the UL CL only when there is an actual need to (locally) transfer some user traffic, there is a more efficient use of operator resources.

[0072] As an alternative, different PDU sessions can be established to meet the access needs of different applications. However, that has implications in the UE, as well as involving multiple parties, and is not yet available.

[0073] Edge Application Server Discovery in Mobile Networks

[0074] A solution for edge application server (EAS) selection is described herein for situations where the UE is agnostic to edge computing services, i.e., no specific UE functionality is assumed for EAS selection. Therefore, the solution utilizes UEDNS messaging for application server resolution. It is assumed that a single UE PDU session has local session grooming for a given application service. It is also assumed that the MNO open API is not used by the edge service provider. The mobile core helps discover the most suitable application server by adding (one or more) potential local PSA network locations as (one or more) ECS options to the DNS request or forwarding the DNS request to the DNS serving the location of the UE. Based on this information, the service provider selects the EAS that matches that suggestion, and can feedback to the mobile network whether the selection has been customized for the provided information by using the ECS option described in RFC 7871. The mobile core then inserts the UL CL and establishes the service steering accordingly.

[0075] 3GPP mobile terminals have a DNS stub resolver in their operating system, which originates DNS queries as required by applications in the UE. At PDU session establishment, the mobile network can provide the UE with the address of a DNS server, typically the operator DNS, in a protocol configuration option (PCO). The UE DNS client then uses that PDU session to send the application's DNS query to the provided DNS server.

[0076] With edge computing, application servers can be distributed and deployed at the edge of a cellular network. In this case, an edge application server that is topologically closest to the UE should be selected. What is important is the topological distance, which is the time or number of hops it takes for a packet to propagate from one host to another, and it is not necessarily related to the geographical distance, but how to route the service between the UE and the application server. Therefore, for edge computing, both the edge application server and the appropriate local UPF need to be selected, which directs the application service to the best access to the data network via the N6 interface. This requires the following aspects: DNS returns the edge application server closest (topological distance) to the UE; local UPF, which provides: N6 interface access to the data network (i.e., PSA) with the best route to that edge application server, and UL CL as defined in Chapter 5.6.4.2 of TS23.501, which can selectively direct the UL service of this application to the selected PSA and aggregate the service of the PDU session in DL.

[0077] There may be different UPFs for each of these two roles.

[0078] The solution should allow dynamic UL CL insertion, as that is preferred from a resource efficiency point of view.

[0079] When the UL CL is inserted dynamically, initially no UL CL exists and thus no local transfer of queries by DNS is possible. The recursive resolver is then typically behind the central PDU Session Anchor and thus topologically far away from the query originator. Its IP address cannot be used to customize the response and provide an edge application server close to the UE. The response will in principle include the address of an application server close to the central PDU Session Anchor, even if another EAS is deployed closer to the UE 302, see Figure 3 .

[0080] To enable EAS selection and dynamic traffic routing, the solution involves a service level agreement between a mobile network operator (MNO) and a service provider. As part of the agreement, the service provider shares the following aspects with the MNO.

[0081] Application FQDN(s) to be used by application clients to discover application servers using DNS.

[0082] Place the location(s) of the edge site(s) of the edge AS(s) for each application (hereinafter referred to as "AS site").

[0083] The Internet Protocol (IP) address of the edge DNS server.

[0084] The range of IP addresses used by the AS at each "AS site".

[0085] This information is used by the MNO to generate a translation table that maps a given user location and application to the preferred PDU Session Anchor(s) (PSA(s)), including information of the corresponding subnet (or full IP address) of that N6 access to the DN after NAT. There is also the AS IP address range that can be used by the UE for communication with the AS(s) and is configured in the UL CL.

[0086] The solution of the previous work introduces a new DNS component in the mobile network, which uses the above information and the mobile network knowledge of the user's actual location to involve a local DNS as a recursive resolver. That local DNS is topologically close to the query originator (UE) and the edge site(s) where the edge AS(s) are placed. Its IP address can then be used to customize the response and select an AS that is topologically close to the UE 302, see Figure 4 .

[0087] However, the solution of previous work places the responsibility of adapting the PDU Session to match the DNS response on the MNO. It requires the mobile network to inspect the DNS response and act accordingly. The mobile core needs to calculate the most appropriate PDU Session Anchor for the selected application server: the DNS response needs to be evaluated.

[0088] The mobile core needs to calculate the IP distances between the possible anchors and the selected edge AS and select the most appropriate one, which may not correspond to the previously provided local DNS. For example, if no edge AS is expected. If that step is skipped, the insertion and configuration of the local UPF may not match the AS selection. In that case, resources are consumed at the mobile network local access site without achieving the desired optimal traffic routing.

[0089] The solution of previous work requires having a local DNS that can handle the application at each site. On the application side, the AS selection mechanism can only consider the location (and IP distance) from the local DNS server that receives the request, but no information about other potential PDU Session Anchors that the MNO could potentially select is available.

[0090] Described in this article is an alternative solution based on the DNS option that solves the problems listed previously.

[0091] Prior work (provided in U.S. Provisional Application 62 / 910767, filed on October 4, 2019, which is incorporated herein by reference in its entirety) introduced a new DNS component. An overview of this prior work is provided in the following four paragraphs. The DNS function obtains (e.g., is configured with) information of an edge application server (AS) site (e.g., information from a business routing service level agreement (SLA)). The DNS function receives a DNS query from a UE and determines whether the DNS query is applicable to any edge AS site or edge AS. More specifically, the DNS function determines whether the FQDN contained in the DNS query matches a domain name handled by any business routing SLA information set, which is defined in any business routing SLA of any edge AS site or edge AS for which the DNS function is configured. If this is not the case, normal DNS query processing is performed (e.g., the DNS function forwards the DNS query to the DNS infrastructure (e.g., via the MNO DNS or another DNS server) in a normal manner).

[0092] If the FQDN contained in the DNS query is part of one or more service routing SLA information sets, the DNS function checks the current location of the UE against the edge site / AS location in the (one or more) service routing SLA information sets that matches the FQDN contained in the DNS query. If there is no match, the normal DNS query process is performed.

[0093] However, if there are one or more service routing information sets that match the FQDN contained in the received DNS query and have an edge site / AS location that matches the UE location, the DNS query may be applicable to the corresponding one or more edge sites / AS. Therefore, the DNS function performs edge site / AS selection. In particular, if the UE location matches an edge site / AS location that matches the FQDN contained in the DNS query from more than one service routing SLA information sets, the DNS function selects the edge site / AS corresponding to one of those service routing SLA information sets (e.g., selects the edge site / AS corresponding to one of those service routing SLA information sets that most closely matches (e.g., is closest to) the edge site / AS location of its UE location). If there is only one service routing SLA information set whose UE location matches the edge site / AS location, the edge site / AS corresponding to that service routing SLA information set is selected. Note that in the above discussion, the DNS function first checks the FQDN and then checks the location. However, the DNS function may alternatively check the location first and then check the FQDN.

[0094] When an edge AS site / edge AS is selected, the DNS function sends a DNS query to the edge site DNS (e.g., using the IP address of the edge site DNS provided by the service routing SLA). The DNS function receives the DNS response and determines whether the IP address contained in the DNS response is an IP address served by the edge AS site or edge AS (e.g., within the IP address range defined in the service routing SLA of the edge AS site or edge AS). If so, the DNS function triggers the activation of local breakout (LBO) (e.g., triggers the activation of the UPF and UL CL at the corresponding breakout site) and sends the DNS response back to the UE. If the IP address in the DNS response is not an IP address served by the edge AS, the DNS function does not trigger the activation of the LBO and sends the DNS response to the UE.

[0095] The operation of the DNS function is described. The DNS function obtains (e.g., is configured with) information of edge AS sites (e.g., information from the above-mentioned service routing SLA). The DNS function receives a DNS query from a UE and determines whether the DNS query is applicable to any edge AS site or edge AS. More specifically, the DNS function determines whether the FQDN contained in the DNS query matches a domain name handled by any service routing SLA information set, which is defined in any service routing SLA of any edge AS site or edge AS for which the DNS function is configured. If this is not the case, normal DNS query processing is performed (e.g., the DNS function forwards the DNS query to the DNS infrastructure (e.g., via the MNO DNS or another DNS server) in a normal manner). If the FQDN contained in the DNS query is part of one or more service routing SLA information sets, the DNS function checks the current location of the UE against the edge site / AS location in the (one or more) service routing SLA information sets that matches the FQDN contained in the DNS query. If there is no match, the normal DNS query process is performed.

[0096] This article provides additional functionality related to the "new DNS" component (described in the previous four paragraphs and fully introduced in previous work), called DNS Proxy.

[0097] The DNS proxy receives a UE request for an FQDN associated with an edge AS and first determines at least one appropriate local PDU Session Anchor (PSA) point for that UE location and application. The mobile core then helps discover the most suitable application server for that (those) PSA by adding the (one or more) PSA network location as (one or more) ECS options to the DNS request. At that stage, the edge application server (EAS) that matches that suggestion is selected by the service provider. The service provider feeds back to the mobile network information about whether the selection has been customized for the information provided by using the ECS option. The mobile core then inserts the UL CL and establishes the service steering accordingly. If no ECS is returned, the central anchor is assumed to be the default option.

[0098] On the mobile core side, a "DNS Proxy" component (for previously working DNS functionality) that interfaces with other components is responsible for those actions.

[0099] Described below is a method for application server discovery for edge computing in mobile networks that allows applications to use DNS as a mechanism for AS discovery and allows operators to use dynamic UL CL insertion for efficient steering of application traffic to local data networks.

[0100] Constructing conversion tables from offline SLAs

[0101] It is assumed that an agreement is in place between a mobile network operator (MNO) and a service provider for application(s), and utilizes the ECS option defined in RFC 7871. As part of this agreement, the service provider shares the following elements with the MNO: application FQDS(s), which will be used by application clients to discover application servers using DNS; location(s) of edge site(s) (hereinafter referred to as "AS sites") for each application's AS(s); and IP address ranges used by the AS at each "AS site".

[0102] This information, along with the MNO network topology information, is used by the MNO to generate a translation table that maps a given user location and application to a preferred PDU Session Anchor(s) (PSA(s)), including information on the corresponding subnet (or full IP address) of that N6 access to the DN after an IP Address Network Translator (NAT). Note that this replaces the DNS proxy functionality provided in previous work, where the DNS proxy maps the UE location to a local DNS server address to forward DNS requests to it.

[0103] Additionally, the IP address range that should be configured in the UL CL traffic steering is derived from the AS address received in the DNS response.By default, the returned AS address may be used to identify the IP address range that may be used by the UE for communication with the AS(s) and configured in the UL CL.

[0104] The operator deploys a new DNS component. That component is hereafter referred to as a DNS proxy, and a deployment example would be to have it deployed as a standalone network entity or in a UPF or in an MNO DNS (as will be further detailed below).

[0105] The above-mentioned conversion table is deployed in a DNS component (hereinafter referred to as a DNS proxy).

[0106] This solution solves the problem of edge application server discovery in TR 23.748. The UE is agnostic of edge computing services.

[0107] The operator deploys a new DNS component. That component is henceforth called a DNS proxy, and it is deployed in the MNO network before NAT.

[0108] The DNS proxy deploys a translation table that maps a given user location and application to a preferred PDU Session Anchor(s) (PSA(s)), including information of the corresponding subnet (or full IP address) of that N6 access to the DN after NAT. It also includes the IP address ranges that can be used by the UE for communication with the AS(s) and configured in the UL CL. It may also include a list of FQDNs for services allowed for edge computing.

[0109] DNS proxy involves in DNS communications for UEs authorized for edge services, for example at session establishment, the SMF sends the DNS proxy address to be used (in the PCO field) to the UE. The DNS proxy receives the UE DNS request for the FQDN associated with the edge AS, authorizes the UE / service, and first determines at least one appropriate local PDU Session Anchor (PSA) point for that UE location and application. The mobile core then helps discover the most suitable application server for that (those) PSA by adding (one or more) PSA network locations as (one or more) ECS options to the DNS request. At that stage, the EAS that matches that suggestion is selected by the service provider. The service provider can feedback to the mobile network whether the selection has been customized to the information provided by using the ECS option. The mobile core then inserts the UL CL and establishes the service steering accordingly.

[0110] Figure 5 An example sequence of such a method is shown comprising the following steps.

[0111] When the UE 302 establishes a PDU session, the 5G core existing mechanisms are used to ensure that if for that user, PDU session edge computing can be applied, then the UE DNS query is sent to the DNS proxy 506. This can be done, for example, by including the DNS proxy address in the PCO field to the UE at session establishment. Otherwise, the MNO DNS address can be provided instead, and the DNS proxy can be bypassed.

[0112] Step 1, once the PDU session has been established, the application may want to establish a connection to the edge application server 504. Typically, the application server is known by domain name and therefore needs to be converted to an IP address. The UE 302 sends a DNS query with the application FQDN. If for that user, PDU session edge computing can be applied, then that query is sent to the DNS proxy 506.

[0113] Step 2, DNS proxy 506 checks whether there is an SLA in place for that application. To do this, it looks up the application FQDN received in the DNS query in the SLA-based translation table.

[0114] If there is no match, then there is no agreement, and the DNS proxy 506 forwards the DNS request to the MNO DNS 508, which resolves it as usual.

[0115] If there is a match, the DNS proxy 506 retrieves the user location from the control plane by using, for example, an open API.

[0116] As an alternative, if it is deployed in the UPF, it derives the location down to the access node level from the N3 session information. This case will be explained in more detail further below.

[0117] With the UE location and FQDN, the DNS proxy 506 uses the SLA-based translation table to get the preferred location for N6 access to the DN for that application and the corresponding subnet (or full IP address) after NAT. These subnets (or full IP addresses) are then added as one or more "ECS" options in the DNS query (as in RFC 7871). ECS stands for EDNS Client Subnet, where EDNS is an extension mechanism of DNS. The query is then forwarded to the MNO DNS. The original DNS request issued by the UE is temporarily buffered so that it is possible to be resent, for example, in the event of a failure.

[0118] Any ECS received from the stub resolver in the UE is not considered, since in this solution it is not the client address but the network address that is provided in the ECS.

[0119] Step 3, the DNS request is forwarded to the MNO DNS 508. The MNO DNS resolves the DNS query as usual, and the DNS query reaches the DNS hierarchy 510.

[0120] Step 4, the ECS option(s) in the DNS query can be used by the service provider DNS to customize the DNS response. When this is done, and if the application server chooses to have been customized for one of the ECS option(s) in the query (i.e., the AS is chosen to be topologically close to the ADDRESS in one of the ECS options), then an ECS option is sent in the response. It corresponds to the ECS option in the query to which the DNS response has been customized. The ECS options in the response are constructed according to RFC 7871: FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS are copies of the ECS options from the query; SCOPEPREFIX LENGTH can be set to, for example, 0 so that it is not cached.

[0121] Otherwise, even if the ECS option(s) were considered, the response is not tailored to any of them and no ECS options are sent back in the response.

[0122] Step 5, the DNS response is sent and arrives at the MNO DNS 508, which sends it back to the DNS proxy 506, which acts as a forwarder. Note that it is assumed that the DNS response already includes the EAS address. That is, if iterative DNS resolution is used, this always happens above the DNS proxy. This is required in order to convey the necessary information about the selected EAS address and possibly the ECS information to the DNS proxy.

[0123] Step 6, the DNS proxy 506 checks the response and whether it includes an ECS option. If so, it selects a PSA corresponding to the received ECS (e.g., a PSA that supports the N6 access to the DN), and uses the received AS address to determine the selected AS site and applicable AS IP range.

[0124] The DNS proxy uses the 3GPP open API to update the CP policy to request UL CL insertion and configure traffic steering for the selected ASIP range to the selected PSA anchor. The traffic steering itself can be done through existing mechanisms defined in 3GPP.

[0125] Alternatively the DNS proxy may determine the DNAI (ie, the identifier of that N6 access to the DN) corresponding to the received ECS, and use the received AS address to determine the selected AS site and applicable AS IP range.

[0126] The DNS proxy uses the 3GPP Policy Authorization Service (3GPP TS 23.514v 16.2.0.0.5G System; PolicyAuthorization Service; Stage 3; Release 16) to request an update of the content provider (CP) policy for a certain service directed to the local access of the DN. Therefore, the SMF inserts the UL CL and configures the selected AS IP range to the service direction of the selected N6 access to the DN (i.e., according to the DNAI).

[0127] Alternatively, if the DNS proxy is deployed in the UPF, service steering can be performed through a proprietary method involving N4 service forwarding of the SMF.

[0128] Step 7, once those actions have been completed, the DNS response is sent to the UE 302 (removing the ECS option previously).

[0129] Application traffic starts towards the received IP address, step 8. That traffic is transferred over the UL CL and sent via the selected PSA to the N6 access to the DN topologically close to the AS (assuming the service provider selection is correct).

[0130] The above process assumes that the establishment of the traffic steering based on the received DNS response is successful. The DNS proxy starts a timer after the initiation of the traffic steering in step 6, waiting for the SMF's notification of changes to the user plane for a given session. If no notification is received before the timer expires, it is considered that the dynamic UL CL insertion and configuration in step 6 above has failed due to reasons related to the selected specific N6 access location, and a new request with (one or more) ECSs but not including that specific N6 access location may be sent, for example. The above process is repeated from step 3. The DNS proxy may log the event.

[0131] As an alternative, if the dynamic UL CL insertion and configuration in step 6 fails, the above process is repeated, for example, from step 3, without sending the ECS option. The DNS proxy may log this event.

[0132] As a pair Figure 5 In an alternative to the process described in , in step 3, the DNS proxy may forward the request to the DNS serving the location of the UE based on the user location and SLA. In this case, the response does not include the ECS. The DNS proxy needs to determine the most suitable local PSA based on the DNS response and SLA, and then Figure 5 Continue with step 6 in .

[0133] DNS Proxy Deployment Options

[0134] There are different options for the deployment of DNS proxy. The solution as described can be used alone where the DNS proxy is deployed. As an example, it may be deployed alone in UPF or in DNS.

[0135] Some details can still be applied in some cases:

[0136] Standalone deployment. The solution has no impact on existing fifth generation core network (5GC) procedures. The DNS proxy acts as an MNO internal AF and communicates with the CN entity using available 5GC APIs to authenticate UE / service, infer UE location, and trigger traffic steering, as defined in, for example, 3GPP TS 23.502 clauses 4.3.6.4 and 4.3.6.3.

[0137] Deployed as part of MNO DNS. The advantage of this approach is that the DNS resolution steps (number of hops) are reduced, resulting in faster DNS processing with lower processing requirements.

[0138] Deployed as part of UPF. This scenario also has some advantages. For example, Figure 5 In step 2 of , the UE location required to select the preferred location for N6 access to the DN may be directly available (the access node ID may be derived from the GTP tunnel ID). The SLA-based translation table then needs to be based on that location granularity. Another property of this solution is that Figure 5 The request for SMF communication for UL CL / PSA insertion and service steering configuration in step 6 may be based on N4 data forwarding to SMF, such as Figure 6 as shown in .

[0139] Send multiple candidate IP address ranges (accessed by N6)

[0140] In some cases, sending only one IP address range in the ECS options may not convey enough information about the N6 access that can be selected by the service provider. For example: when the AS deployment information is missing or outdated, a non-uniform AS deployment may result in an AS that is co-sited with an N6 access that is not currently closest to the UE; the AS(s) 'close' to the proposed N6 location are overloaded / failed (or do not provide the required KPI for their transmission), but another(other) AS is still available at another N6 access with the required characteristics; there may be a better non-closest AS to use, which still meets the latency requirements, but it has more processing resources or has a lower cost (as long as it uses another N6 access).

[0141] The solution to the above problem is that the DNS proxy provides a list of ECS options (with option code 8), for example, listing them in order of preference of the MNO (for example, based on how far a certain N6 access is topologically from the UE). The response from the service provider then includes the ECS address and the range prefix length of the ECS address that is the basis for the EAS selection.

[0142] The MNO preference order only allows a qualitative differentiation of available N6 accesses by the service provider. Further enhancements enabling qualitative differentiation are also possible, for example by defining new DNS options carrying additional information, such as the topological distance from the UE to the candidate N6 accesses.

[0143] DNS proxy functionality

[0144] The proposed DNS proxy functionality is Figure 7 The same description applies to steps that differ from those in the previous description.

[0145] This is a solution for application server discovery for edge computing in mobile networks that allows applications to continue to use DNS as a mechanism for EAS discovery and allows operators to use dynamic UL CL insertion for efficient steering of application traffic to local data networks.

[0146] This solution is simpler than previous work and instead places the responsibility on the service provider whether to accept the proposed location of the N6 access to the data network, and if so, to select the most suitable EAS for this. It simplifies the logic in the mobile core, which does not need to check the response and calculate the closest PDU session anchor point. Coordination between EAS selection and anchor is still guaranteed. It simplifies deployment. There is no need for a local DNS that can handle DNS queries at each site. It enables the provision of additional topology information by sending multiple of these N6 access locations for application selection, which can result in the selection of a more suitable EAS and UL CL / PSA pair for UE services. It is more robust because it has a fallback mechanism if for some reason the service steering and routing cannot be set to match the ECS-based EAS selection.

[0147] Figure 8a A method 800 performed in a Domain Name System (DNS) proxy 506 is shown for identifying services suitable for edge grooming and suitable for service orientation in a mobile network, the method comprising: receiving (step 801) a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE); upon determining (step 802) that edge computing is applicable to the DNS query, adding one or more Internet Protocol (IP) addresses, IP address ranges, or IP subnets to the DNS query as one or more Extended Mechanism for DNS (EDNS) Client Subnet (ECS) options, corresponding to one or more preferred locations for access to a data network (DN); and forwarding (step 803) the DNS query. In this context, an IP subnet is a subset of an IP address, i.e., some of the bits of an IP address, starting at the beginning of the address, at the most significant bit (MSB). When the DNS query is forwarded, it is forwarded to the next DNS in the architecture. For addresses outside the network, it can be forwarded to a dedicated forwarder.

[0148] The method may further include: receiving (step 804) a DNS response; and upon determining (step 805) that the DNS response includes an ECS option corresponding to one of the one or more ECS options of the DNS query for which the DNS response has been customized, triggering an action to establish a business orientation in accordance with the ECS option.

[0149] Customization in this context can mean adaptation according to policy. The DNS server looks at the ECS option and if it has the functionality to respond differently depending on the value of the ECS option, the response is customized / adapted according to the policy for how to handle the address in the ECS option. Different responses can be obtained depending on the content.

[0150] The method may further include, upon successful completion of the action triggered to establish the traffic steering, removing the ECS option from the DNS response and sending the DNS response to the UE.

[0151] The method may further include: upon unsuccessful completion or failure of the action triggered to establish the service orientation, forwarding the DNS query again, and excluding the ECS option that has generated the unsuccessful completion or failure.

[0152] The method may further include: upon unsuccessful completion or failure of the action triggered to establish the service orientation, forwarding the DNS query without the ECS option again.

[0153] The different branches of the method may be performed according to preferences set in a translation table based on a service level agreement (SLA) or based on a predefined configuration.

[0154] Determining that edge computing is applicable to the DNS query may further include determining whether the DNS query FQDN is under a service level agreement (SLA).

[0155] Determining whether the DNS query FQDN is under the SLA may further include determining whether the DNS query FQDN is contained in a SLA-based translation table.

[0156] The one or more preferred locations for accessing the DN may be extracted from the SLA-based translation table using at least the DNS query FQDN and the user location as input for reading the SLA-based translation table.

[0157] The preferred location is the location of access to the data network. The IP network topology can be used to determine this location of the application server, i.e., its proximity to the IP routing. Extracting data from the SLA-based conversion table can be done using a key. For example, the user (geographic) location and application defined by the FQDN can be used as a key to get the preferred location. For a given application, it converts the user location into a list of preferred locations for accessing the DN.

[0158] The method may further include obtaining the user location from a policy control function (PCF) through an existing open application programming interface (API).

[0159] The one or more IP addresses, IP address ranges, or IP subnets included in the ECS of the DNS query may correspond to the one or more preferred locations for accessing the DN. This may be the output of a translation table based on the SLA, or it may be based on a predefined configuration.

[0160] Forwarding a DNS query may include forwarding the DNS query to the next DNS in the DNS hierarchy, or to a dedicated forwarder. The DNS proxy may redirect traffic to different DNS servers depending on location; it then gets different responses, and looks at the responses to be able to understand if / what edge grooming can be done. When a DNS query is forwarded to a DNS forwarder, the system uses a recursive mode of operation.

[0161] The method may further include determining a DN Access Identifier (DNAI), the DNAI corresponding to the ECS option in the DNS response.

[0162] A translation table or predefined configuration based on a service level agreement (SLA) may be used to determine the DNAI.

[0163] The method may further include determining an application server (AS) IP address range based on the AS address contained in the DNS response. The "AS site" concept does not necessarily need to be handled this way, as long as all AS IP ranges associated with a given AS selection (one in the DNS response) are known. The AS site is a way of grouping them: all IP addresses associated with an application business-oriented purpose. These IP addresses may be used as destination IPs by application clients at some point, which are still within the same AS site.

[0164] This information is part of what the application / service provider gives to the MNO as part of the SLA.

[0165] The method may further include requesting establishment of the traffic steering from a policy control function (PCF) by sending a request including the DNAI and the AS IP address range.

[0166] The actions may include any one or more of the following: using the 3GPP policy authorization service to send (step 806) a request for a content provider (CP) policy for directing a certain service for local access to the DN; using the CP policy to initiate (step 807) service steering; starting (step 808) a timer after initiating the service steering; waiting (step 809) for a notification from a session management function (SMF) regarding changes to the user plane for a given session; and when the timer expires, if no notification is received from the SMF, or if an error indication is received from the SMF, sending (step 810) a new request with one or more ECSs and executing the method again starting at the step of forwarding the DNS query.

[0167] DNS queries from UEs of users authorized to use edge computing may be sent to the DNS proxy via user subscription information when enabled.

[0168] A service level agreement (SLA) based translation table may be deployed in the DNS proxy and may include: operator locations for accessing the DN, at least one SLA agreement including application FQDNs, and AS deployment and application server (AS) IP ranges at each AS site.

[0169] Forwarding the DNS query may include forwarding the DNS query to a mobile network operator (MNO) DNS, with the DNS request received from the UE being temporarily cached to be forwarded again in case of failure.

[0170] The ECS option in the DNS response may be constructed according to RFC 7871 and includes FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS, which are copies of the ECS option from the DNS query; if SCOPE PREFIXLENGTH is set to 0, no caching is performed.

[0171] Figure 8bA method 850 performed in a domain name system (DNS) proxy 506 for application server (AS) discovery and business steering for edge computing in a mobile network is shown. The method includes receiving (step 852) a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE). The method includes: when determining (step 853) that a service level agreement (SLA) is in place for the application corresponding to the FQDN, retrieving or obtaining the location of the UE that sent the DNS query from the control plane. The method includes adding (step 855) one or more subnets or full IP addresses of one or more preferred locations for accessing a data network (DN) in the DNS query as one or more DNS extension mechanism (EDNS) client subnet (ECS) options. The method includes forwarding (step 856) the DNS query to a mobile network operator (MNO) DNS. The method includes receiving a DNS response including zero or one ECS options, wherein when the ECS options are present, the ECS options may correspond to the ECS options in the DNS query for which the DNS response has been customized, and when the ECS options are not present, the DNS response is not customized for any ECS options. The method includes triggering an action to establish or request traffic steering in accordance with the ECS options (step 858). The method includes removing (860) the ECS options and sending the DNS response to the UE.

[0172] The method may further include: deploying (step 851) a translation table in the DNS proxy; and using the translation table to obtain (step 854) the one or more preferred locations for accessing the DN for the application, and using the translation table or obtaining (one or more) corresponding subnets or complete IP addresses from a predefined configuration; and determining a DN access identifier (DNAI) corresponding to the received ECS option, and determining an application server (AS) IP address range based on the AS address contained in the DNS response.

[0173] The translation table may be an SLA-based translation table that maps a given user location and the application to the one or more preferred locations for accessing the DN.

[0174] Obtaining may include looking up the application FQDN received in the DNS query in a translation table.

[0175] When there is an SLA in place, the user location can be retrieved from the control plane by using an open application programming interface (API).

[0176] When forwarding DNS queries to the MNO DNS, the DNS request received from the UE may be temporarily cached to be forwarded again in case of failure.

[0177] The ECS option in the DNS response may be constructed according to RFC 7871, comprising FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS fields, which are copies of the ECS option from the DNS query; and if SCOPEPREFIX-LENGTH is set to 0, no caching is performed.

[0178] The method may further include: starting (step 859) a timer after initiating service steering; waiting for notification from a session management function (SMF) about changes to the user plane for a given session; and if no notification is received before the timer expires, assuming that the dynamic UL CL insertion and configuration has failed, sending a new request with (one or more) ECSs and executing the method again starting with the step of forwarding the DNS query to the MNO DNS.

[0179] The DNS proxy can be deployed as a standalone entity in the UPF or in the MNO DNS.

[0180] Figure 8c Show Figure 8b A slightly simplified version of the method of . Method 875 is performed in a domain name system (DNS) proxy 506 for application server (AS) discovery and business steering for edge computing in a mobile network. The method includes receiving (step 877) a DNS query with an application fully qualified domain name (FQDN) from a user equipment (UE). The method includes: when determining (step 878) that a service level agreement (SLA) is in place for the application corresponding to the FQDN, obtaining the location of the UE that sent the DNS query from the control plane. The method includes adding (step 879) at least one subnet or full IP address of one or more preferred locations for access to a data network (DN) as one or more extension mechanism for DNS (EDNS) client subnet (ECS) options in the DNS query. The method includes forwarding (step 881) the DNS query to a mobile network operator (MNO) DNS. The method includes receiving (step 882) a DNS response, the DNS response including an ECS option, the ECS option being customized for the corresponding ECS ​​option of the one or more ECS options in the DNS query. The method includes triggering an action to establish a traffic steering according to the ECS option received in the DNS response (step 884). The method includes removing (step 886) the ECS option from the DNS response and sending the DNS response to the UE.

[0181] The method may further include: deploying (step 876) a translation table in the DNS proxy; and using the translation table to obtain (step 880) the one or more preferred locations for accessing the DN for the application, and obtaining the at least one subnet or full IP address using the translation table or from a predefined configuration. The method may further include determining (step 883) a DN access identifier (DNAI) corresponding to the received ECS option, and determining at least one application server (AS) site and at least one IP address range based on the AS address contained in the DNS response.

[0182] The translation table may be an SLA-based translation table that maps a given user location and the application to the one or more preferred locations for accessing the DN.

[0183] Obtaining may include looking up the application FQDN received in the DNS query in a translation table.

[0184] When there is an SLA in place, the user location can be retrieved from the control plane by using an open application programming interface (API).

[0185] When forwarding DNS queries to the MNO DNS, the DNS request received from the UE may be temporarily cached to be forwarded again in case of failure.

[0186] The ECS option in the DNS response may be constructed according to RFC 7871, comprising FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS fields, which are copies of the ECS option from the DNS query; and if SCOPEPREFIX-LENGTH is set to 0, no caching is performed.

[0187] The method may further include: starting (step 885) a timer after initiating service steering; waiting for notification from a session management function (SMF) about changes to the user plane for a given session; and if no notification is received before the timer expires, assuming that the dynamic uplink classifier (UL CL) insertion and configuration has failed, sending a new request with (one or more) ECSs and executing the method again starting with the step of forwarding the DNS query to the MNO DNS.

[0188] The DNS proxy can be deployed as a standalone entity in the UPF or in the MNO DNS.

[0189] Reference Fig. 9 , providing a virtualized environment in which the functions and steps described in this article can be implemented.

[0190] Virtualized environment (can exceed Fig. 9The contents shown in the figure may include systems, networks, servers, nodes, devices, etc. that can communicate with each other by wire or wirelessly. Part or all of the functions and steps described herein may be implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines or containers, etc.) executed on one or more physical devices in one or more networks, systems, environments, etc.

[0191] The virtualized environment provides hardware including processing circuitry 901 and memory 903. The memory can contain instructions executable by the processing circuitry, whereby the functions and steps described herein can be performed to provide any of the related features and benefits disclosed herein.

[0192] The hardware may also include a non-transitory, non-transitory machine-readable storage medium 905 storing software and / or instructions 907 executable by the processing circuitry to perform the functions and steps described herein.

[0193] Equipment (e.g. Fig. 9 HW in) or system (e.g. Fig. 9 The system comprises a processing circuit 901 and memories 903, 905, wherein the memories contain instructions executable by the processing circuit, whereby the device is operable to perform any of the steps described herein.

[0194] A device or system is provided for identifying services suitable for edge grooming and suitable for service steering in a mobile network, the device or system comprising a processing circuit 901 and memories 903, 905, wherein the memories contain instructions executable by the processing circuit, whereby the device or system is operable to perform any of the steps described herein.

[0195] Provides a Domain Name System (DNS) proxy (which can be executed as an application, virtual node, or instance, such as Fig. 9 ), used to identify services suitable for edge grooming and suitable for service steering in a mobile network, and can be operated to perform any of the steps described in this document.

[0196] A device or system is provided for application server (AS) discovery for edge computing in a mobile network, the device or system comprising a processing circuit 901 and memories 903, 905, wherein the memories contain instructions executable by the processing circuit, whereby the device or system is operable to perform any of the steps described herein.

[0197] Provides a Domain Name System (DNS) proxy (which can be executed as an application, virtual node, or instance, such as Fig. 9 ), for application server (AS) discovery for edge computing in a mobile network, operable to perform any of the steps described herein.

[0198] The non-transitory computer readable medium 905 has stored thereon instructions 907 for performing any of the steps of the methods described herein.

[0199] Those skilled in the art who have benefited from the above description and the theories presented in the associated drawings will appreciate modifications. It is therefore to be understood that specific forms, such as those other than those described above, are intended to be included within the scope of this disclosure. The foregoing description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than by the above description, and all changes and equivalents falling within the scope of the claims are intended to be included therein. Although specific terms may be employed herein, they are used only in a general and descriptive sense, and not for the purpose of limitation.

Claims

1. A method implemented in a Domain Name System (DNS) proxy for application server (AS) discovery and service steering for edge computing in a mobile network, the method comprising: - receiving a DNS query with an application fully qualified domain name FQDN from a user equipment UE; - upon determining that a service level agreement (SLA) is in place for an application corresponding to the FQDN, obtaining from a control plane a location of the UE that sent the DNS query; - adding in said DNS query at least one subnet or full IP address of one or more preferred locations for accessing the data network DN as one or more DNS extension mechanism EDNS Client Subnet ECS options; - forwarding the DNS query to the mobile network operator MNO DNS; - receiving a DNS response including an ECS option, the ECS option being customized for a corresponding ECS ​​option of the one or more ECS options in the DNS query; - triggering an action to establish a service orientation according to the ECS option received in the DNS response; as well as - removing the ECS option from the DNS response, and sending the DNS response to the UE.

2. The method of claim 1, further comprising: - deploying a translation table in the DNS proxy; - using the translation table to obtain the one or more preferred locations for accessing the DN for the application, and obtaining the at least one subnet or full IP address using the translation table or from a predefined configuration; as well as - Determine a DNS access identifier DNAI corresponding to the received ECS option, and determine at least one AS site and at least one IP address range based on the AS address contained in the DNS response.

3. The method of claim 2, wherein: The translation table is an SLA-based translation table that maps a given user location and the application to the one or more preferred locations for accessing the DN.

4. The method of claim 2, wherein: Obtaining includes looking up the application FQDN received in the DNS query in the translation table.

5. The method of claim 1, wherein: When there is an SLA in place, the user location is retrieved from the control plane using an open application programming interface, API.

6. The method of claim 1, wherein: When forwarding the DNS query to the MNO DNS, the DNS request received from the UE is temporarily cached to be forwarded again in case of failure.

7. The method of claim 1, wherein: The ECS option in the DNS response includes FAMILY, SOURCEPREFIX-LENGTH, and ADDRESS fields, which are copies of the ECS option from the DNS query; and wherein if SCOPE PREFIX LENGTH is set to 0, no caching is performed.

8. The method of claim 1, further comprising: After initiating service steering, start the timer; wait for notification of changes in the user plane for a given session by the session management function SMF; And if no notification is received before the timer expires, dynamic uplink classifier UL CL insertion and configuration is deemed to have failed, a new request with one or more ECSs is sent and the method is performed again starting at the step of forwarding the DNS query to the MNO DNS.

9. The method of claim 1, wherein: The DNS proxy is deployed as a standalone entity.

10. The method of claim 1, wherein: The DNS proxy is deployed in the user plane function UPF.

11. The method of claim 1, wherein: The DNS proxy is deployed in the MNO DNS.

12. A method executed in a Domain Name System (DNS) proxy for identifying services suitable for edge grooming and suitable for service steering in a mobile network, the method comprising: - receiving a DNS query with an application fully qualified domain name FQDN from a user equipment UE; - upon determining that edge computing is applicable to the DNS query, adding one or more Internet Protocol IP addresses, IP address ranges or IP subnets to the DNS query as one or more DNS extension mechanisms EDNS Client Subnet ECS options corresponding to one or more preferred locations for accessing the data network DN; and - Forward said DNS queries.

13. The method of claim 12, further comprising: - Receive DNS response; as well as - upon determining that the DNS response includes an ECS option corresponding to one of the one or more ECS options of the DNS query to which the DNS response has been customized, triggering an action of establishing a traffic steering in accordance with the ECS option.

14. The method of claim 13, further comprising: Upon successful completion of the action triggered to establish the traffic steering, removing the ECS option from the DNS response and sending the DNS response to the UE.

15. The method of claim 13, further comprising: Upon unsuccessful completion or failure of the action triggered to establish the business orientation, the DNS query is forwarded again, and the ECS option that has generated the unsuccessful completion or failure is excluded.

16. The method of claim 13, further comprising: Upon unsuccessful completion or failure of the action triggered to establish the service orientation, the DNS query without the ECS option is forwarded again.

17. The method according to any one of claims 12 to 16, wherein: The preferences for executing the method are set in a conversion table based on a service level agreement SLA or based on a predefined configuration.

18. The method of claim 17, wherein: Determining that the edge computing is applicable to the DNS query further includes determining whether the DNS query FQDN is under a service level agreement (SLA).

19. The method of claim 18, wherein: Determining whether the DNS query FQDN is under the SLA includes determining whether the DNS query FQDN is contained in a SLA-based translation table.

20. The method of claim 19, wherein: The one or more preferred locations for accessing the DN are extracted from the SLA-based translation table, and further comprising using at least the DNS query FQDN and user location as input for reading the SLA-based translation table.

21. The method of claim 20, further comprising obtaining the user location from a policy control function (PCF) through an existing open application programming interface (API).

22. The method of claim 20, wherein: The one or more IP addresses, IP address ranges, or IP subnets contained in the ECS of the DNS query correspond to the one or more preferred locations for accessing the DN.

23. The method of any one of claims 12 to 16, wherein: Forwarding the DNS query includes forwarding the DNS query to the next DNS in the DNS hierarchy, or to a dedicated forwarder.

24. The method of claim 17, further comprising determining a DN access identifier DNAI, the DN access identifier DNAI corresponding to the ECS option in the DNS response.

25. The method of claim 24, wherein: A conversion table or a predefined configuration based on a service level agreement SLA is used to determine the DNAI.

26. The method of claim 24, further comprising determining an application server AS IP address range based on the AS address contained in the DNS response.

27. The method of claim 26, further comprising requesting establishment of traffic steering from a policy control function (PCF) by sending a request including the DNAI and the AS IP address range.

28. The method of any one of claims 13 to 16, wherein: The actions include any one or more of the following: - using the 3GPP Policy Authorization Service to send a request for a content provider CP policy to direct a certain service for local access to the DN; - Use the CP strategy to initiate business orientation; - starting a timer after initiating said traffic steering; - Waiting for notifications from the Session Management Function SMF regarding changes in the user plane for a given session; as well as - Upon expiration of the timer, if no notification is received from the SMF, or if an erroneous indication is received from the SMF, a new request with one or more ECSs is sent and the method is executed again starting at the step of forwarding the DNS query.

29. The method of any one of claims 12 to 16, wherein: DNS queries from UEs of users authorized to use edge computing are sent to the DNS proxy via user subscription information when enabled.

30. The method of claim 12, wherein: A translation table based on a service level agreement (SLA) is deployed in the DNS proxy and includes: operator locations for accessing the DN, at least one SLA agreement including application FQDN, and AS deployment at each AS site and application server AS IP range.

31. The method of claim 12, wherein: Forwarding the DNS query includes forwarding the DNS query to a mobile network operator (MNO) DNS, and the DNS query received from the UE is temporarily cached so as to be forwarded again in case of failure.

32. The method of claim 13, wherein: The ECS option in the DNS response includes FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS fields, which are copies of the ECS option from the DNS query; and wherein if SCOPE PREFIX LENGTH is set to 0, no caching is performed.

33. A device or system for application server AS discovery for edge computing in a mobile network, the device or system comprising a processing circuit and a memory, the memory containing instructions executable by the processing circuit, whereby the device or system is operable to perform any of the steps described in any one of claims 1 to 11.

34. A Domain Name System (DNS) proxy for application server (AS) discovery for edge computing in a mobile network, operable to perform any of the steps as claimed in any one of claims 1 to 11.

35. A device or system for identifying services suitable for edge grooming and suitable for service steering in a mobile network, the device or system comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry, whereby the device or system is operable to perform any of the steps described in any of claims 12 to 32.

36. A Domain Name System (DNS) proxy for identifying services suitable for edge grooming and suitable for service steering in a mobile network, operable to perform any of the steps as claimed in any one of claims 12 to 32.

37. A non-transitory computer readable medium comprising instructions for performing any of the steps of any of claims 1 to 32.

Images