Patent Description:
Computer systems in a communications network may comprise one or more nodes, which may also be referred to simply as nodes. A node may comprise one or more processors which, together with computer program code may perform different functions and actions, a memory, a receiving port and a sending port. A node may be, for example, a server. Nodes may perform their functions entirely on the cloud.

The standardization organization 3GPP is currently in the process of specifying a New Radio Interface called NR or <NUM>-UTRA, as well as a Fifth Generation (<NUM>) Packet Core Network, which may be referred to as <NUM> Core Network, abbreviated as 5GC.

A 3GPP system comprising a <NUM> Access Network (AN), a <NUM> Core Network and a UE may be referred to as a <NUM> system.

<FIG> is a schematic diagram depicting a particular example of a 5GC architecture as defined by 3GPP, which may be used as a reference for the present disclosure. The depicted architecture shows different types of nodes that may be comprised in a communications network. A Policy Control Function (PCF) <NUM> may be understood to support a unified policy framework to govern the behavior of the network. The PCF <NUM> may provide Policy and Charging Control (PCC) rules to the Policy and Charging Enforcement Function (PCEF). That is, the Session Management Function (SMF) <NUM> / User Plane Function (UPF) <NUM> that may enforce policy and charging decisions according to provisioned PCC rules. The PCF <NUM> may provide policy rules to a user equipment (UE) <NUM> through the Access and Mobility Management Function (AMF) <NUM>. The AMF <NUM> may manage access of the UE <NUM>. For example, when the UE <NUM> may be connected through different access networks, and mobility aspects of the UE <NUM>. Specifically, the AMF <NUM> may be used to forward UE rules from the PCF <NUM> to the UE <NUM>. The SMF <NUM> may support different functionality, e.g. Session Establishment, modify and release, and policy related functionalities such as termination of interfaces towards Policy control functions, Charging data collection, support of charging interfaces and control and coordination of charging data collection at the UPF <NUM>. The SMF <NUM> may receive PCC rules from PCF <NUM> and configure the UPF <NUM> accordingly through an N4 reference point <NUM> according to the Packet Flow Control Protocol (PFCP) protocol as follows. The SMF may control the packet processing in the UPF <NUM> by establishing, modifying or deleting PFCP Sessions and by provisioning, e.g., adding, modifying or deleting, Packet Detection Rules (PDRs), Forwarding Action Rules (FARs), Quality of Service Enforcement Rules (QERs) and/or Usage Reporting Rules (URRs) per PFCP session, whereby a PFCP session may correspond to an individual Packet Data Unit (PDU) session or a standalone PFCP session not tied to any PDU session. Each PDR may contain a Packet Detection Information (PDI) specifying the traffic filters or signatures against which incoming packets may be matched. Each PDR may be associated to the following rules providing the set of instructions to apply to packets matching the PDI. According to a first rule, one FAR, which may contain instructions related to the processing of the packets, may specifically forward, duplicate, drop or buffer the packet with or without notifying the Control Plane (CP) function about the arrival of a Downlink (DL) packet. According to a second rule, zero, one or more QERs, which contains instructions related to the Quality of Service (QoS) enforcement of the traffic. According to a third rule, zero, one or more URRs, which may contain instructions related to traffic measurement and reporting. The UPF <NUM> may support handling of user plane traffic based on the rules received from the SMF <NUM>, packet inspection, e.g., through PDRs, and different enforcement actions, such as traffic steering, QoS, Charging/Reporting, e.g., through FARs, QERs and URRs. The UE <NUM> is a type of device. Devices within a communications network may be user equipments (UEs), e.g., stations (STAs), wireless devices, mobile terminals, wireless terminals, terminals, and/or Mobile Stations (MS). User equipments are enabled to communicate wirelessly in a cellular communications network or wireless communication network, sometimes also referred to as a cellular radio system, cellular system, or cellular network. The communication may be performed e.g., between two user equipments, between a user equipment and a regular telephone, and/or between a user equipment and a server via a Radio Access Network (RAN) <NUM>, and possibly one or more core networks, comprised within the communications network. Devices may further be referred to as mobile telephones, cellular telephones, laptops, or tablets with wireless capability, just to mention some further examples. The devices in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and/or data, via the RAN <NUM>, with another entity, such as another terminal or a server.

The communications network may cover a geographical area which may be divided into cell areas, each cell area being served by another type of node, a network node in the RAN <NUM>, radio network node or Transmission Point (TP), for example, an access node such as a Base Station (BS), e.g. a Radio Base Station (RBS), which sometimes may be referred to as e.g., evolved Node B ("eNB"), "eNodeB", "NodeB", "B node", or Base Transceiver Station (BTS), depending on the technology and terminology used. The base stations may be of different classes such as e.g. Wide Area Base Stations, Medium Range Base Stations, Local Area Base Stations and Home Base Stations, based on transmission power and thereby also cell size. A cell is the geographical area where radio coverage is provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies. The telecommunications network may also be a non-cellular system, comprising network nodes which may serve receiving nodes, such as user equipments, with serving beams. Also depicted in <FIG> are a Network Slice Selection Function (NSSF) <NUM>, a Network Exposure Function (NEF) <NUM>, a Network Repository Function (NRF) <NUM>, a Unified Data Management (UDM) <NUM>, an Application Function (AF) <NUM>, an Authentication Server Function (AUSF) <NUM> and a Data Network (DN) <NUM>. Each of the NSSF <NUM>, the NEF <NUM>, the NRF <NUM>, the PCF <NUM>, the UDM <NUM>, the AF <NUM>, the AUSF <NUM>, the AMF <NUM> and the SMF <NUM> may have an interface through which they may be accessed, which as depicted in the Figure, may be, respectively: Nnssf <NUM>, Nnef <NUM>, Nnrf <NUM>, Npcf <NUM>, Nudm <NUM>, Naf <NUM>, Nausf <NUM>, Namf <NUM>, Nsmf <NUM>. Each of the UE <NUM>, the RAN <NUM> and the UPF <NUM> may have an interface through which they may be accessed, which as depicted in the Figure, may be, respectively: N1 <NUM>, N2 <NUM> and N4 <NUM>. The RAN <NUM> may have an interface N3 <NUM> with the UPF <NUM>. The UPF <NUM> may have an interface N6 <NUM> with the DN<NUM>.

DNS may be considered as one of the fundamental building blocks of the Internet. DNS may be understood to be used any time a website is visited, an email is sent, an IM conversation is maintained, or any other task is performed online. When a user opens an application, DNS protocol may be used to retrieve the server Internet Protocol (IP) address/es for the target application domain. DNS protocol today may be usually unencrypted, that is, it may be used as DNS over User Datagram Protocol (UDP)/Transmission Control Protocol (TCP), but there may be different Internet Engineering Task Force (IETF) drafts proposing DNS encryption to prevent middle boxes to detect DNS traffic. There may be different proposals at IETF such as DNS Security Extensions (DNSSEC), DNS over HTTP/<NUM> (DOH), DNSCrypt, Quad9, etc. It is foreseen that in the <NUM> timeframe, that is in the <NUM>-<NUM> decade, most DNS traffic may be encrypted.

User devices may include DNS caches that may store recently visited IP addresses before a request may be sent out to the internet. This DNS cache may suffer some security attacks such as DNS poisoning, where IP address for some domains in the cache may have an incorrect entry.

Domain Names may be hierarchical, and each part of a domain name may be referred to as either the root, Top Level Domain (TLD), second level domain, sub-domains or host name, that is, a resource record. To allow computers to properly recognize a fully qualified domain name, dots may be placed between each part of the name. The fully qualified domain name may be split into pieces at the dots, and the tree may be searched starting from the root of the hierarchical tree structure. All resolvers may start their lookups at the root; therefore, the root may be represented by a dot and may be often assumed to be there, even when not shown. The resolver may navigate its way down the tree until it may get to the last, left-most part of the domain name, and then may look within that location for the information may need. Information about a host such as its name, its IP address and occasionally even its function may be stored in one or more zone files which together may compose a larger zone often referred to as a domain.

Within the hierarchy, resolution may start at the top level domain, and work its way down to the second-level domain, then through zero, one or more sub-domains until the resolver may get to the actual host name that may be desired to resolve into an IP address.

Edge computing may be understood as a distributed computing paradigm which may bring computation and data storage closer to the location where it may be needed, to improve response times and save bandwidth. 3GPP TS <NUM>, v16. <NUM>, describes how <NUM> enables EC scenarios.

3GPP TR <NUM>, v1. <NUM> describes how DNS may be used for EC in 3GPP networks. Solutions are being studied to allocate DNS servers in Edge Clouds or Local Data Networks and resolve the addresses of the applications deployed in those Edge Clouds. The existing solutions may describe the UE receiving the address of a DNS server, e.g., a local DNS server, in the PDU session establishment response message. Then, the UE may use that DNS server to resolve the addresses of the applications, e.g., using their Full Qualified Domain Name (FQDN).

3GPP TS <NUM>, v16. <NUM> describes the UE policies for <NUM> system, which may be delivered from the PCF to the UE, including UE route selection policy (URSP) and Access network discovery and selection policy (ANDSP).

The network, e.g., via the PCF, may install URSP rules in a UE. A URSP rule may include a traffic descriptor and a list of route selection descriptors. The traffic descriptor may include an application descriptor in the form of an application identifier. Table <NUM> below shows the format a URSP rule may have according to existing methods, particularly, as described in Table <NUM>. <NUM>-<NUM> "<NPL>.

According to existing methods, DNS procedures may result in high latencies, thus impacting the quality of experience of the user, and wasted resources, such as energy resources of a device. Furthermore, Application Servers (AS) may not be reachable, and/or a DNS server may not always be able to resolve a DNS query with the performance of existing methods.

<NPL>, describes a study on enhancement of support for Edge Computing in <NUM> Core network (5GC).

<CIT> describes systems and methods for extending Inter System Routing Policies (ISRPs) of an Access Network Discovery and Selection Function (ANDSF) to enable domain name system (DNS) flows to be identified by a queried domain. Such systems and methods may include providing an Intersystem routing policy (ISRP) with a routing rule that may be used to select a DNS server or interface thereof and resolve DNS for a target domain name and/or corresponding target URL for a website.

<NPL>, describes a multi-interfaced node connected to multiple networks, some of which may be utilizing private DNS namespaces. A node may commonly receive recursive DNS sever configuration information from all connected networks. Some of the recursive DNS servers may have information about namespaces other servers may not have. When a multi-interfaced node may need to utilize DNS, the node may have to choose which of the recursive DNS servers to use. The authors describe DHCPv4 and DHCPv6 options that may be used to configure nodes with information required to perform informed recursive DNS server selection decisions.

In EC scenarios, different instances of Application Servers (AS) may be deployed in the different Edge Clouds and/or local networks and central networks for a certain application. An instance may be understood herein as a single realization of an application server that may be running. Therefore, a UE may be understood to need to properly resolve the IP address of the AS in the Edge Cloud in order to trigger a connection towards that AS. The DNS solutions proposed in 3GPP comprise deploying a local DNS server in each Edge Cloud, since each Edge Cloud may handle a different range of IP addresses and prefixes, and then providing the IP address of the.

DNS server to the UE in a PDU session establishment response. Then, the UE may use the local DNS server to resolve the addresses of the applications. However, this solution presents the following problems. One problem is that the network operator may only assign a single local DNS server in EC scenarios. This may be understood to mean that all DNS queries may need to be directed to that server, whether the DNS queries may be related to EC applications or not. The local DNS server may resolve the addresses of the applications deployed in the same Edge Cloud the DNS server may be deployed at. For the applications that may not be not deployed in the same Edge Cloud however, e.g. in other Edge Clouds or the central network or the internet, the local DNS server may be required to query other DNS servers which may respond with the IP address of an AS in an unforeseeable location. In case the local DNS server does not have access to other DNS servers, the local DNS server may not be able to resolve the DNS query. These issues may be understood be difficult to detect and solve by the operator, since the Edge Cloud may be managed by a third party.

Another problem may be that there is no existing mechanism to change dynamically the DNS server allocated to a UE. This may be problematic e.g., when the UE moves and attaches to different radio network nodes, e.g., gNBs. The Edge Cloud may not be valid any longer to fulfill the service requirements. However, as the local DNS server cannot be updated, the ASs in a different Edge Cloud cannot be reached. This may then result in not meeting the latency requirements for edge cloud applications, as the application server serving the user session is not changed when the UE moves.

Yet another problem may be that, there may be Edge Clouds without a local DNS server, or with several DNS servers. In this case, it may be more problematic if a single DNS server is allocated to the UE as per the current methods. Then, this may then result in a non-optimal DNS server allocation which may impact the user quality of experience for edge cloud applications.

It is an object of embodiments herein to improve the handling of usage of a DNS server in a communications network.

Examples of embodiments herein are described in more detail with reference to the accompanying drawings, according to the following description.

Certain aspects of the present disclosure and their embodiments address one or more of the issues with the existing methods discussed in the background section and provide solutions to the challenges discussed.

Embodiments herein may be understood to relate in general to traffic management in <NUM> networks. Further particularly, embodiments herein may be understood to be related to a mechanism for allocation a DNS server or servers for EC applications using UE policies. Even further particularly, embodiments herein may be understood to relate to a mechanism which may be based on an extension of the UE policies, such as those that may be generated by a PCF and sent towards a UE through an AMF, which mechanism may allow a network operator to dynamically instruct a UE on a particular DNS server instance or instances to use, on a per (EC) application basis, and according to different criteria, such as location of the user, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc..

The embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which examples are shown. In this section, embodiments herein are illustrated by exemplary embodiments. It should be noted that these embodiments are not mutually exclusive. Components from one embodiment or example may be tacitly assumed to be present in another embodiment or example and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. All possible combinations are not described to simplify the description.

<FIG> depicts two non-limiting examples, in panels "a" and "b", respectively, of a communications network <NUM>, in which embodiments herein may be implemented. In some example implementations, such as that depicted in the non-limiting example of <FIG>, the communications network <NUM> may be a computer network. In other example implementations, such as that depicted in the non-limiting example of <FIG>, the communications network <NUM> may be implemented in a telecommunications network, sometimes also referred to as a cellular radio system, cellular network or wireless communications system. In some examples, the telecommunications network may comprise network nodes which may serve receiving nodes, such as wireless devices, with serving beams.

In some examples, the telecommunications network may for example be a network such as <NUM> system, or a newer system supporting similar functionality. The telecommunications network may also support other technologies, such as a Long-Term Evolution (LTE) network, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band, Wideband Code Division Multiple Access (WCDMA), Universal Terrestrial Radio Access (UTRA) TDD, Global System for Mobile communications (GSM) network, GSM/Enhanced Data Rate for GSM Evolution (EDGE) Radio Access Network (GERAN) network, Ultra-Mobile Broadband (UMB), EDGE network, network comprising of any combination of Radio Access Technologies (RATs) such as e.g. Multi-Standard Radio (MSR) base stations, multi-RAT base stations etc., any 3rd Generation Partnership Project (3GPP) cellular network, Wireless Local Area Network/s (WLAN) or WiFi network/s, Worldwide Interoperability for Microwave Access (WiMax), IEEE <NUM>. <NUM>-based low-power short-range networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LowPAN), Zigbee, Z-Wave, Bluetooth Low Energy (BLE), or any cellular network or system. The telecommunications network may for example support a Low Power Wide Area Network (LPWAN). LPWAN technologies may comprise Long Range physical layer protocol (LoRa), Haystack, SigFox, LTE-M, and Narrow-Band loT (NB-loT).

Although terminology from Long Term Evolution (LTE)/<NUM> has been used in this disclosure to exemplify the embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned system. Other wireless systems support similar or equivalent functionality may also benefit from exploiting the ideas covered within this disclosure. In future telecommunication networks, e.g., in the sixth generation (<NUM>), the terms used herein may need to be reinterpreted in view of possible terminology changes in future technologies.

The communications network <NUM> may comprise a plurality of nodes, whereof a first node <NUM>, a second node <NUM>, and another node <NUM>, which may be understood to be a third node <NUM>, are depicted in <FIG>. Any of the first node <NUM>, the second node <NUM> and the another node <NUM> may be understood, respectively, as a first computer system, a second computer system, and a third computer system. In some examples, any of the first node <NUM>, the second node <NUM>, and the another node <NUM> may be implemented as a standalone server in e.g., a host computer in the cloud <NUM>. Any of the first node <NUM>, the second node <NUM>, and the another node <NUM> may in some examples be a distributed node or distributed server, with some of their respective functions being implemented locally, e.g., by a client manager, and some of its functions implemented in the cloud <NUM>, by e.g., a server manager. Yet in other examples, any of the first node <NUM>, the second node <NUM>, and the another node <NUM> may also be implemented as processing resources in a server farm.

In some embodiments, any of the first node <NUM>, the second node <NUM>, and the another node <NUM> may be independent and separated nodes. In other embodiments, any of the first node <NUM>, the second node <NUM> and the another node <NUM> may be co-located or be the same node. All the possible combinations are not depicted in <FIG> to simplify the Figure.

In some examples of embodiments herein, the first node <NUM> is a node having a capability to manage or control policies, being a PCF in <NUM>, or a node capable of performing a similar function in the communications network <NUM>. The second node <NUM> is a node or database having a capability to store information about subscriptions of users of the communications network <NUM>, being a Unified Data Repository (UDR) in <NUM>, or a node or database capable of performing a similar function in the communications network <NUM>. The another node <NUM> may be a node having a capability to manage access and mobility functions in the communications network <NUM>, such as an AMF in <NUM>, or a node capable of performing a similar function in the communications network <NUM>.

The communications <NUM> also comprises one or more DNS servers <NUM>. The one or more DNS servers <NUM> comprise a DNS server <NUM>, that is, a first DNS server <NUM>. Any of the DNS servers <NUM> may be understood to be able to translate domain names into IP addresses, making it possible for DNS clients to reach an origin server.

The communications network <NUM> may comprise one or more radio network nodes, whereof a radio network node <NUM> is depicted in <FIG>. The radio network node <NUM> may typically be a base station or Transmission Point (TP), or any other network unit capable to serve a wireless device or a machine type node in the communications network <NUM>. The radio network node <NUM> may be e.g., a <NUM> gNB, a <NUM> eNB, or a radio network node in an alternative <NUM> radio access technology, e.g., fixed or WiFi. The radio network node <NUM> may be e.g., a Wide Area Base Station, Medium Range Base Station, Local Area Base Station and Home Base Station, based on transmission power and thereby also coverage size. The radio network node <NUM> may be a stationary relay node or a mobile relay node. The radio network node <NUM> may support one or several communication technologies, and its name may depend on the technology and terminology used. The radio network node <NUM> may be directly connected to one or more networks and/or one or more core networks.

The communications network <NUM> covers a geographical area which may be divided into cell areas, wherein each cell area may be served by a radio network node, although, one radio network node may serve one or several cells.

The communications network <NUM> comprises a device <NUM>. The device <NUM> is a user equipment (UE). The device <NUM> in the present context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or a vehicle-mounted mobile device, enabled to communicate voice and/or data, via a RAN, with another entity, such as a server, a laptop, a Personal Digital Assistant (PDA), or a tablet computer, sometimes referred to as a tablet with wireless capability, or simply tablet, a Machine-to-Machine (M2M) device, a device equipped with a wireless interface, such as a printer or a file storage device, modem, Laptop Embedded Equipped (LEE), Laptop Mounted Equipment (LME), USB dongles, CPE or any other radio network unit capable of communicating over a radio link in the communications network <NUM>. The device <NUM> may be wireless, i.e., it may be enabled to communicate wirelessly in the communications network <NUM> and, in some particular examples, may be able support beamforming transmission. The communication may be performed e.g., between two devices, between a device and a radio network node, and/or between a device and a server. The communication may be performed e.g., via a RAN and possibly one or more core networks, comprised, respectively, within the communications network <NUM>. In some particular embodiments, the device <NUM> may be an loT device, e.g., a NB loT device.

The first node <NUM> may communicate with the second node <NUM> over a first link <NUM>, e.g., a radio link or a wired link. The first node <NUM> may communicate with the another node <NUM> over a second link <NUM>, e.g., a radio link or a wired link. The another node <NUM> may communicate with the second node <NUM> over a third link <NUM>, e.g., a radio link or a wired link. The another node <NUM> may communicate with the radio network node <NUM> over a fourth link <NUM>, e.g., a radio link or a wired link. The DNS server <NUM> may communicate with the first node <NUM> over a fifth link <NUM>, e.g., a radio link. Each of the DNS servers <NUM> may communicate with the first node <NUM> over a respective fifth link <NUM>. The DNS server <NUM> may communicate with the device <NUM> over a sixth link <NUM>, e.g., a wired link or a radio link. Each of the DNS servers <NUM> may communicate with the device <NUM> over a respective sixth link <NUM>. The another node <NUM> may communicate with the radio network node <NUM> over a seventh link <NUM>, e.g., a radio link or a wired link. The device <NUM> may communicate with the radio network node <NUM> over an eighth link <NUM>, e.g., a radio link. The DNS server <NUM> may communicate with the radio network node <NUM> over a ninth link <NUM>, e.g., a wired link or a radio link. The eighth link <NUM> may be a direct link or comprise one or more links, e.g., via one or more other nodes, network nodes or radio network nodes. Any of the first link <NUM>, the second link <NUM>, the third link <NUM>, the fourth link <NUM>, the fifth link <NUM>, the sixth link <NUM>, the seventh link <NUM>, and the ninth link <NUM> may be a direct link or it may go via one or more computer systems or one or more core networks in the communications network <NUM>, or it may go via an optional intermediate network. The intermediate network may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network, if any, may be a backbone network or the Internet, which is not shown in <FIG>.

In general, the usage of "first", "second", "third", "fourth", "fifth", "sixth", "seventh", "eighth" and/or "ninth" herein may be understood to be an arbitrary way to denote different elements or entities, and may be understood to not confer a cumulative or chronological character to the nouns they modify.

Embodiments of a method, performed by the first node <NUM>, will now be described with reference to the flowchart depicted in <FIG>. The method may be understood to be or handling usage of a Domain Name Service (DNS) server <NUM> in a communications network <NUM>. The first node <NUM> operates in the communications network <NUM>.

The method may comprise the actions described below. In some embodiments all the actions may be performed. In some embodiments some of the actions may be performed. In <FIG>, optional actions are indicated with a dashed box. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example or embodiment may be tacitly assumed to be present in another example or embodiment and it will be obvious to a person skilled in the art how those components may be used in the other examples or embodiments.

During the course of operations of the communications network <NUM>, the device <NUM> may initiate usage an application, such as e.g., example. By doing that, the device <NUM> may contact the another node <NUM>, and trigger the establishment of a data session, e.g., a Protocol Data Unit, PDU, session. To be able to use the application in the communications network <NUM>, the device <NUM> may need to use a DNS server to translate domain names, e.g., example. com, into IP addresses, making it possible for a DNS client to reach an origin server, e.g., an application server instance. Since the communications network <NUM> comprises the one or more servers <NUM>, at least one of the one or more DNS servers <NUM> may need to be selected for the device <NUM> to use for the application. How the device <NUM> may need to select the DNS server to use may be determined based on one or more rules that may apply to the device <NUM>. The DNS server may be understood to be for use by the device <NUM> to resolve one or more, or any, DNS query or queries from the application.

As part of the establishment of the data session, the another node <NUM>, e.g., an AMF, may therefor need to find out what rules may apply to the device <NUM> to manage its data session in the communications network <NUM>, including how to select the DNS server. The another node <NUM> may then contact the first node <NUM>, either directly or indirectly, to obtain the information on which rules may apply to the first node <NUM>. The first node <NUM> may then also try to find out which rules may apply to the device <NUM>.

In order to find out which rules may apply to the device <NUM> for the data session for the application, e.g., example. com, in this Action <NUM>, the first node <NUM> obtains one or more first indications. The one or more first indications indicate one or more rules on how the device <NUM> operating in the communications network <NUM> is to select, based on one or more criteria, a DNS server, such as the DNS server <NUM>, out of one or more DNS servers <NUM>, for use by the device <NUM> for an application. The one or more first indications comprise an explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

In some embodiments, obtaining, may comprise retrieving from a memory, e.g., of the first node <NUM>. In some embodiments, obtaining may comprise receiving. In such embodiments, the one or more first indications may be obtained from the second node <NUM> operating in the communications network <NUM>, e.g., via the first link <NUM>.

The one or more first indications may be understood to indicate a policy, e.g., a UE DNS Policy (UDNSP). The one or more rules may be those that may need to be enforced in the device <NUM>.

In some embodiments, the first node <NUM> may be a PCF and the second node <NUM> may be a UDR. In some examples of such embodiments, the first node <NUM> may obtain the one or more first indications in a UDR Policy Profile Response, in reply to a UDR Policy Profile Request the first node <NUM> may have sent to the second node <NUM>, e.g., triggered by the establishment of the data session with the device <NUM>. The one or more first indications in some examples, such as this one, may be a subscriber policy profile.

The explicit indication may be understood as an indication of the type of traffic the policy may apply to. In some examples, the type of traffic the policy may apply to may be indicated in the one or more first indications with a list of identifiers of the applications it may apply to. As an example, the policy may apply only to traffic for a certain edge computing application, e.g. example. Otherwise, the policy may apply to may be indicated in the one or more first indications with an "Any" notation. This may be understood to indicate that this policy may need to always be applied. It may be used as the default UDNSP when no other UDNSPs with higher precedence may have been applied.

The one or more criteria may comprise one or more of the following options. According to a first option, the one or more criteria may comprise the application for which the device <NUM> is to instantiate the DNS server <NUM>. That is, for example, the choice of DNS server may be performed on an application basis, some rules may apply to one application, and other rules may apply to another application. According to a second option, the one or more criteria may comprise whether or not the application is for edge computing (EC). According to a third option, the one or more criteria may comprise a first location, that is, a location, of the device <NUM>. That is, for example, the choice of DNS server may be performed based on the location of the device <NUM>. According to a fourth option, the one or more criteria may comprise a second location, that is, a location, of the DNS server <NUM>. That is, for example, the choice of DNS server may be performed based on the location of the DNS server <NUM>. According to a fifth option, the one or more criteria may comprise a type of slice instantiated for the use of the DNS server <NUM> by the device <NUM>. According to a sixth option, the one or more criteria may comprise, a Radio Access Technology to be used by the device <NUM> to run the application.

According to the foregoing, the one or more first indications may be understood to be, in some examples, a subscriber policy profile, which may be understood to be extended with an indication that a certain application, identified by its app-ID or Fully Qualified Domain Name (FQDN), may be an Edge Computing application and the DNS information to be applied for the EC application.

The location of the device <NUM> may be understood to be relevant, since in Edge Computing scenarios, the device <NUM> may be required to leverage the edge applications hosted in the nearest Edge Cloud. In this case, the device <NUM> may be enabled to connect to the DNS server <NUM> resolving the IP addresses of the closest Edge Cloud.

The slice type may be relevant since there may be specific DNS servers on a per slice type. For example, for a mission critical slice, a DNS server may be used to resolve the IP addresses of the mission critical applications towards the closest Edge Cloud.

The one or more first indications may be understood to comprise a DNS description. Particularly, the one or more first indications may indicate one or more of the following. First, an address of the DNS server <NUM>. The address of the DNS server <NUM> may be a DNS Server IP address, which may be understood to identify the DNS Server instance. Second, whether or not the DNS server <NUM> supports encryption. The one or more first indications may indicate if the DNS Server <NUM> instance supports encryption or not, and which type of encryption it may be e.g., DoH, DoT, etc.. Third, whether or not the DNS server <NUM> supports filtering. Filtering may be understood as, e.g., a capability to block malicious websites and filter out harmful or inappropriate content. Fourth, a type of filtering supported by the DNS server <NUM>. The type of filtering may be for example, security to e.g., block malicious websites, or parental control, to block traffic certain websites. Fifth, the second location of the DNS server <NUM>. The second location of the DNS server <NUM>, or DNS server location may be understood to indicate if the DNS Server <NUM> may be located on the public Internet or on private or local networks.

By obtaining the one or more first indications in this Action <NUM>, the first node <NUM> may be enabled to select a DNS server for the device <NUM> in the next Action <NUM>. This may in turn enable an operator of the communications network <NUM> to manage an optimal allocation of different DNS servers based on different criteria, e.g. application, location of the device <NUM>, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc, this on a per application basis and specifically for Edge Computing scenarios. The operator of the communications network <NUM> may therefore be enabled to change or update, the allocation of DNS servers for the device <NUM> at any moment.

Optionally, in this Action <NUM>, the first node <NUM> may select the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The selecting in this Action <NUM> may be based on the obtained one or more first indications, that is, based on the one or more rules and the fulfilment or not of the one or more criteria.

The first node <NUM> may have obtained information pertaining to the fulfilment of one or more criteria for the device <NUM>, such as e.g., the application for which the device <NUM> is the first location of the device <NUM>, the second location of the DNS server <NUM> the type of slice instantiated for the use of the DNS server <NUM> by the device <NUM>, the RAT used by the device <NUM> to run the application, etc.. The first node <NUM> may have obtained this information by subscribing to one or more nodes, to be able to receive this information. For example, in embodiments wherein the first node <NUM> may be a PCF, the first node <NUM> may have received this information in responses to a subscription to the another node <NUM>, e.g., an AMF. Then, in this Action <NUM>, the first node <NUM> may apply the information obtained with regards to the device <NUM>, to the criteria and the one or more rules indicated by the one or more first indications and select the DNS server <NUM> accordingly.

There may be a mapping between DNS Servers and locations, on a per application basis, e.g., on a per edge computing application basis. This mapping may be stored in a the another node <NUM>, for example, a database, e.g., UDR, so that the first node <NUM> may be able to retrieve this data and select the DNS server <NUM>, or any other DNS server from the one or more DNS servers <NUM>, e.g., DNS Server instance/s. Additionally, as an alternative, the first node <NUM> may dynamically obtain this mapping between DNS Servers and locations through a new Nnef northbound Application Program Interface (API) from the content provider for the application, e.g., an online gaming company which may deploy their own application servers and DNS servers on multiple locations.

In some examples, the first node <NUM> may subscribe to location, and location change, events. In order to do that, the first node <NUM> may subscribes to another node <NUM> events for the UE related to location, and location change. The subscription may be performed by the first node <NUM> triggering towards the another node <NUM> a Namf_Event Exposure Subscribe Request message, which may include the following parameters EventlD=Location and Input=UEID. In some examples, the first node <NUM> may perform this Action <NUM> after receiving a notification, e.g., from the another node <NUM>, that the device <NUM> has changed location. This notification may be, for.

In other examples, the first node <NUM> may perform this Action <NUM> after the device <NUM> may have triggered a.

By selecting the DNS server <NUM> in this Action <NUM>, the first node <NUM> may dynamically choose a particular DNS server instance or instances for the device <NUM> to use, on a per application basis, and even more particularly, an EC application basis, and according to different criteria, such as location of the device <NUM>, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc.. For example, the first node <NUM> may select DNS server <NUM>, a local DNS server, for App <NUM> in location A, DNS server <NUM>, another local DNS server, for App <NUM> in location B, DNS server <NUM>, a central DNS server, for App <NUM> in any location. In other words, the first node <NUM> may select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations.

By selecting the DNS server <NUM> in this Action <NUM>, the first node <NUM> may therefore be enabled to change or update, the allocation of DNS servers in the device <NUM>, as may be instructed by the operator of the communications network <NUM>, at any moment.

Moreover, the first node <NUM> may enable the application to receive the most suitable application server according to the area in which a subscriber, e.g., a user of the device <NUM>, may be connected to.

Furthermore, by selecting the DNS server <NUM> in this Action <NUM>, the first node <NUM> may enable that security issues related to DNS cache poisoning may be improved, since such queries may be handled based on information provided via UDNSP instead of DNS cache. In other words, the first node <NUM> may choose a DNS server for which security checks have already been pre-arranged for the particular application being used, and thereby avoid choosing a non-safe DNS server for this particular application, due to a rigid rule, e.g., based solely on location of the device <NUM>, and disregarding the particular security requirements that the application for which the DNS server is going to be used for may have.

Prior to indicating the selected DNS server <NUM> to the device <NUM>, the first node <NUM> may device to first run a check to verify that the DNS server <NUM> may be able to resolve the address of the application. With this purpose, in this Action <NUM>, the first node <NUM> may send a query to the selected DNS server <NUM> based on an address of the application.

In this Action <NUM>, the sending may be implemented, e.g., via the fifth link <NUM>.

By sending the query in this Action <NUM>, the first node <NUM> may then be enabled to determine, in the next Action <NUM>, if the selected DNS server <NUM> may be eligible.

In this Action <NUM>, the first node <NUM> may determine whether or not to select another DNS server, based on whether or not a response to the query is received from the selected DNS server <NUM>.

Determining may be understood as e.g., calculating, deciding. The first node <NUM> may check if, in response to Action <NUM>, it receives a response with the application's IP address(es) from the DNS server <NUM>. If the query is successful, and the first node <NUM> receives a response, the first node <NUM> may then perform Action <NUM>.

In case the query is not successful, and the first node <NUM> fails to receive a response from the DNS server <NUM>, the first node <NUM> may perform Action <NUM> again, select another DNS server, and performs the verification again of Action <NUM> and Action <NUM>.

By the first node <NUM> determine whether or not to select another DNS server, based on whether or not a response to the query is received from the selected DNS server <NUM>, the first node <NUM> may then be enabled to include the DNS server <NUM> in another indication in the Action <NUM>.

In this Action <NUM>, the first node <NUM>, sends a second indication to one of: the another node <NUM> operating in the communications network <NUM> and the device <NUM>. The second indication indicates the obtained one or more first indications.

The second indication may for example, indicate a new UE DNS Policy (UDNSP). For example, the second indication may be: "{UE policy for DNS(appID=example. com, List of DNS Server instances(DNS Server IP, DNS Server encryption, DNS Server filtering, DNS Server location}".

The second indication may be, for example, comprised in a Npcf_AMPolicyControl_Create Response message, which may be sent from a PCF to an AMF, as will be illustrated later with a non-limiting example.

In some embodiments wherein Action <NUM> may have been performed, the second indication may indicate the selected DNS server <NUM>.

The second indication may further indicate one or more of: a) an order of enforcement of the policy, and b) a type of traffic the policy applies to. The order of enforcement of the policy may be, for example a rule precedence, which may determine the order the policy, e.g., a UE DNS Policy (UDNSP) rule may need to be enforced in the device <NUM>.

The type of traffic the policy applies to may be understood as a traffic descriptor, which may determine the traffic to which the UDNSP rule may apply to, as follows. In some examples, the type of traffic the policy may apply to may be indicated in the second indication with a list of identifiers of the applications it may apply to, e.g., a list of appld. As an example, the policy may apply only to traffic for a certain edge computing application, e.g. example. Otherwise, the type of traffic the policy may apply to may be indicated in the second indication with an "Any" notation. This may be understood to indicate that this policy may need to always be applied. It may be used as the default UDNSP when no other UDNSPs with higher precedence may have been applied.

As described earlier, the one or more first indications may be understood to comprise a DNS descriptor determining the DNS policies. The one or more first indications may indicate the DNS Server instance, that may have been selected by the operator of the communications network <NUM> based on different criteria, e.g., the current first location of the device <NUM>, the slice type, etc.. , in order of precedence, where each instance may include the following information: the address of the DNS server <NUM>, whether or not the DNS server <NUM> supports encryption, e.g., and which type of encryption, e.g., DoH, DoT, whether or not the DNS server <NUM> supports filtering, e.g., and which type of filtering, and the second location of the DNS server <NUM>.

In this Action <NUM>, the sending may be implemented, e.g., via the second link <NUM> when sending to the another node <NUM>, and via the second link <NUM> and the fourth link <NUM>, or the via the second link <NUM>, the seventh link <NUM> and the eighth link <NUM> when sending to the device <NUM>.

The second indication may be, or may be comprise in, a Npcf_AMPolicyControl_Create Response message.

In case there are several DNS servers suitable for the application, the first node <NUM> may send different second indications, e.g., indicating different UDNSP policies for each DNS server, including a different precedence, or the first node <NUM> may include several DNS servers in the same UDNSP with the same precedence, so the device <NUM> may be enabled to select one of them randomly.

In any of the foregoing embodiments, the first node <NUM> may be a PCF, the another node <NUM> may be an AMF, and the second node <NUM> may be a UDR or a further node operating in the communications network <NUM>. The device <NUM> may be a UE.

By sending the second indication in this Action <NUM>, the first node <NUM> may be enabled to dynamically configure the device <NUM> to use a particular DNS server instance or instances, on a per application basis, and even more particularly, an EC application basis, and according to different criteria, such as location of the device <NUM>, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc.. For example, the first node <NUM> may enable the device <NUM> to select DNS server <NUM>, a local DNS server, for App <NUM> in location A, DNS server <NUM>, another local DNS server, for App <NUM> in location B, DNS server <NUM>, a central DNS server, for App <NUM> in any location. In other words, the first node <NUM> may enable the device <NUM> to select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations.

By sending the second indication in this Action <NUM>, the first node <NUM> may be therefore enabled to change or update, the allocation of DNS servers in the device <NUM>, as may be instructed by the operator of the communications network <NUM>, at any moment.

Furthermore, by sending the second indication in this Action <NUM>, the first node <NUM> may enable that security issues related to DNS cache poisoning may be improved, since such queries may be handled based on information provided via UDNSP instead of DNS cache. In other words, the first node <NUM> may choose a DNS server for which security checks have already been pre-arranged for the particular application being used, and thereby avoid choosing a non-safe DNS server for this particular application, due to a rigid rule, e.g., based solely on location of the device <NUM>, and disregarding the particular security requirements that the application for which the DNS server is going to be used for may have.

As stated earlier, in some embodiments, the one or more first indications may indicate the address of the DNS server <NUM>. Therefore, an additional advantage provided by sending the second indication in this Action <NUM> may be that a time to solve DNS queries may be understood to be reduced due to the fact that host names addresses, e.g., as described earlier under the heading Domain Names Hierarchy, may be provisioned, so it may not be needed to check from top to down in the DNS hierarchy.

Embodiments of a method performed by the second node <NUM> will now be described with reference to the flowchart depicted in <FIG>. The method may be understood to be for handling usage of a DNS server, such as the DNS server <NUM>, in the communications network <NUM>. The second node <NUM> operates in the communications network <NUM>.

The method comprises the following actions. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example or embodiment may be tacitly assumed to be present in another example or embodiment, and it will be obvious to a person skilled in the art how those components may be used in the other examples.

The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node <NUM> and will thus not be repeated here to simplify the description. For example, the first node <NUM> may be a PCF, the another node <NUM> may be an AMF, and the second node <NUM> may be a UDR or a further node operating in the communications network <NUM>. The device <NUM> may be a UE.

In this Action <NUM>, the second node <NUM> may send, to the first node <NUM> operating in the communications network <NUM>, the one or more first indications. The one or more first indications indicate the one or more rules on how the device <NUM> operating in the communications network <NUM> is to select, based on the one or more criteria, the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The one or more first indications comprise the explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

The sending in this Action <NUM>, may be understood as transmitting, providing or sharing, in and may be implemented, for example, via the first link <NUM>.

By sending the one or more first indications in this Action <NUM>, the second node <NUM> may enable the first node <NUM> to then select the DNS server <NUM> for the device <NUM> for use for the application, as described in next Action <NUM>. This may in turn enable the operator of the communications network <NUM> to manage an optimal allocation of different DNS servers based on different criteria, e.g. application, location of the device <NUM>, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc, this on a per application basis and specifically for Edge Computing scenarios. The operator of the communications network <NUM> may therefore be enabled to change or update, the allocation of DNS servers for the device <NUM> at any moment.

Embodiments of a method performed by the device <NUM>, will now be described with reference to the flowchart depicted in <FIG>. The method may be understood to be for handling usage of a DNS server, such as the DNS server <NUM>, in the communications network <NUM>. The device <NUM> operates in the communications network <NUM>.

The method comprises the following actions. Several embodiments are comprised herein. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. It should be noted that the examples herein are not mutually exclusive. Components from one example may be tacitly assumed to be present in another example and it will be obvious to a person skilled in the art how those components may be used in the other examples.

In this Action <NUM>, the device <NUM> receives, from the first node <NUM> operating in the communications network <NUM>, the second indication. The second indication indicates the one or more first indications indicating the one or more rules on how the device <NUM> is to select, based on the one or more criteria, the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The second indication comprises the explicit indication of the one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

The receiving may be understood to be directly from the first node <NUM>, or via another node, such as the another node <NUM>, which may transparently forward the second indication to the device <NUM>. The receiving in this Action <NUM>, may be performed, for example, via the second link <NUM>, and the fourth link <NUM>, or via the second link <NUM>, the seventh link <NUM> and the eight link <NUM>.

The one or more first indications may be understood to indicate a policy, e.g., a UE DNS Policy (UDNSP). For example, the second indication may be: "{UE policy for DNS(appID=example. com, List of DNS Server instances(DNS Server IP, DNS Server encryption, DNS Server filtering, DNS Server location}".

If received indirectly, e.g., via the another node <NUM>, the second indication may be comprised in, or received as, a third indication. For example, the third indication may be a PDU Session Establishment Response.

In some embodiments wherein Action <NUM> may have been performed, the second indication may indicate the selected DNS server <NUM> by the first node <NUM>.

The second indication may further indicate one or more of: a) the order of enforcement of the policy, and b) the type of traffic the policy may apply to.

By receiving the second indication in this Action <NUM>, the device <NUM> may be enabled to select the DNS server <NUM> to use for the application in the next Action <NUM>. The specific benefits of this Action <NUM> may be understood to correspond to those already described for Action <NUM>.

After receiving the second indication, the device <NUM> may store it.

In this Action <NUM>, the device <NUM> selects the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The selecting <NUM> is based on the received second indication. This Action <NUM> may be understood to be performed similarly to how it was described in Action <NUM>, but with the information collected by the device <NUM>.

The selected DNS server <NUM> may then be understood to be used by the device <NUM> to resolve one or more, or any, DNS query or queries from the application.

The device <NUM> may select the DNS server <NUM> autonomously, or if the DNS server <NUM> has already been selected by the first node <NUM>, implement the selection performed by the first node <NUM>.

The device <NUM> may start an edge computing application, such as example. When the device <NUM> may detect that the application, e.g., example. com, tries to send application traffic which matches the Traffic Descriptor described earlier, e.g., appld=example. com, in the one or more first indications, e.g., in the UDNSP policy, the device <NUM> may select the DNS server instance in the DNS Descriptor in order to resolve all DNS queries from that application, and e.g., with higher precedence than the default DNS server for the PDU session of the device <NUM>. If the device <NUM> received several UDNSP policies for the appID, the device <NUM> may select one of the DNS server instances according to the UDNSP policies received for that appID, and their precedence.

The device <NUM> may perform the selecting in this Action <NUM> for each application. Therefore, the device <NUM> may select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations.

Based on the received second indication, e.g., a UDNSP policy, the device <NUM> may then be enabled to perform the following. When the device <NUM> may detect a certain UE application, e.g. example. com, the device <NUM> may try to send application traffic which matches the Traffic Descriptor, e.g. appld=example. com, in the second indication, that is, the UDNSP policy. The device <NUM> may select one of the DNS server instances provided in the second indication, e.g., in the DNS Descriptor, in order to resolve all DNS queries from that application, and with higher precedence than the default DNS server for the PDU session of the device <NUM>.

By selecting the DNS server <NUM> in this Action <NUM>, the device <NUM> may be enabled to dynamically use a particular DNS server instance or instances, on a per application basis, and even more particularly, an EC application basis, and according to different criteria, such as location of the device <NUM>, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc.. For example, the device <NUM> may be enabled to select DNS server <NUM>, a local DNS server, for App <NUM> in location A, DNS server <NUM>, another local DNS server, for App <NUM> in location B, DNS server <NUM>, a central DNS server, for App <NUM> in any location. In other words, the device <NUM> may be enabled to select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations.

The device <NUM> may be therefore be enabled to change or update, the allocation of DNS servers, as may be managed by the operator of the communications network <NUM>, at any moment.

Moreover, the device <NUM> may enable the application to receive the most suitable application server according to the area in which a subscriber, e.g., a user of the device <NUM>, may be connected to.

Furthermore, as stated earlier, security issues related to DNS cache poisoning may be improved, since such queries may be handled based on information provided via UDNSP instead of DNS cache. As stated earlier, in some embodiments, the one or more first indications may indicate the address of the DNS server <NUM>. Therefore, an additional advantage may be that the time to solve DNS queries may be understood to be reduced due to the fact that host names addresses, e.g., as described earlier under the heading Domain Names Hierarchy, may be provisioned, so it may not be needed to check from top to down in the DNS hierarchy.

The methods just described as being implemented by the first node <NUM>, the second node <NUM> and the device <NUM> will now be described in further detail with a specific non-limiting example in the next figure.

<FIG> is a signalling diagram depicting a non-limiting example of embodiments herein. In this non-limiting example, the first node <NUM> is a PCF, the second node <NUM> is a UDR, the another node <NUM> is an AMF, and the device <NUM> is a UE. According to this example, the one or more first indications are based on an extension of the UE policies generated by the PCF and sent towards UE through the AMF, which may allow the network operator to dynamically instruct the UE on the DNS server instance/s to use on a per application basis and according to different criteria, e.g., user's location, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc. The sequence diagram shown in <FIG>, as well as its continuation on <FIG> and <FIG>, shows an example for optimal DNS server instance allocation for an edge computing application, here, example. com, based on current user's location and RAT Type. In steps <NUM>-<NUM>, the device <NUM> triggers a PDU Session Establishment procedure by sending a PDU Session Establishment Request to the another node <NUM>. The another node <NUM> sends a Nsmf PDUSession_CreateSMContext Request to a fourth node <NUM>, here an SMF, at Step <NUM>. As part of the PDU Session Establishment procedure, the another node <NUM> creates the policy association with the PCF in Step <NUM>, by sending an Npcf_SMPolicyControl_Create Request including the identifier of the device <NUM>, the UEID, the UE location, as Locationlnfo, and slice type information. The fourth node <NUM> creates the policy association with the PCF at Step <NUM> by sending a Npcf_SMPolicyControl_Create Request. At steps <NUM>, the first node <NUM> sends a UDR Policy Profile Request to the second node <NUM>, indicating the identifier of the device <NUM>. At step <NUM>, in accordance with Action <NUM>, the first node <NUM> retrieves from the second node <NUM> the one or more first indications as a subscriber policy profile, which is extended, according to embodiments herein, with an indication that a certain Application, identified by its app-ID or FQDN, is an Edge Computing application (EC App indication) and the DNS information to be applied for the EC application. As described earlier, the DNS information may comprise: the DNS Server IP address, the DNS server encryption, the DNS server filtering, and the DNS server location. At steps <NUM>, the first node <NUM> generates PCC rules, including a PCC rule for appld=example. At step <NUM>, the first node <NUM> sends a Npcf_SMPolicyControl_Create Response to the fourth node <NUM> to e.g., detect traffic and to apply corresponding traffic management actions. At step <NUM>, the fourth node <NUM> triggers a PFCP Session Establishment procedure towards a fifth node <NUM>, here a UPF, to indicate the PDRs and the corresponding enforcement actions, e.g., FARs, QERs, URRs, etc, for the PDU session. The fourth node <NUM> may include an UL/DL PDR with PDI type appld, e.g., example. com, which may be associated to the corresponding enforcement actions, e.g., FAR, QER, URR. At step <NUM>, the fifth node <NUM> sends a PFCP Session Establishment response to the fourth node <NUM>. At step <NUM>, the first node <NUM> subscribes to location, and location change, events. In order to do that, the first node <NUM> subscribes with the another node <NUM> to events related to Location and Location change for the UE, by the first node <NUM> triggering towards the another node <NUM> an Namf_Event Exposure Subscribe Request message including the following parameters: EventID=Location, and Input=UEID. At step <NUM>, the another node <NUM> answers the first node <NUM> by triggering a Namf_EventExposure Subscribe Response message including the following parameters:EventID=Location, and Output=Locationlnfo, which indicates the current location of the device <NUM>, e.g., a cell identifier (Cell ID). Although it is not shown in the sequence diagram of <FIG>, when the location of the device <NUM> changes, e.g. from CelllD #<NUM> to CelllD #<NUM>, the another node <NUM> may notify the first node <NUM> on the new location of the device <NUM>. Also depicted in <FIG> are the DNS server <NUM>, and an application server <NUM>.

<FIG> is a continuation of the procedure depicted in <FIG>. At step <NUM>, in accordance with Action <NUM>, the first node <NUM> generates a UE policy for DNS and selects the DNS Server <NUM> instance for the application, example. com, based on different criteria, e.g. user's location, RAT Type. To verify that the DNS server <NUM> can resolve the application's address, at step <NUM>, in accordance with Action <NUM>, the first node <NUM> sends a DNS query to the selected DNS server <NUM> and checks if it receives, at step <NUM>, in accordance with Action <NUM>, a response with the application's IP address(es). In case the DNS query is not successful, the first node <NUM> selects another DNS server, and performs the verification of steps <NUM> and <NUM> again. At step <NUM>, in accordance with Action <NUM>, the first node <NUM> forwards the UE policy to the another node <NUM>, by sending the second indication in the Npcf_AMPolicyControl_Create Response message, as follows. The second indication is a UE DNS Policy (UDNSP), which includes, in this example, a Rule precedence, a Traffic Descriptor, and a DNS Descriptor. The rule precedence determines the order the UDNSP rule is enforced in the device <NUM>. The Traffic Descriptor determines the traffic to which the UDNSP rule applies to, as follows: List of appld: in this example, traffic for a certain edge computing application, e.g. example. com, and "Any", which indicates that this policy is always applied. It may be used as the default UDNSP when no other UDNSPs with higher precedence have been applied. The DNS Descriptor determines the DNS policies, as follows. DNS Server <NUM> instance, selected by the operator of the communications network <NUM>, based on different criteria, such as, e.g., current location of the device <NUM>, slice type, in order of precedence, where each instance includes the following information: the DNS Server <NUM> IP address, which may identify the DNS Server <NUM> instance, DNS server encryption, which may indicate if the DNS Server <NUM> instance supports encryption or not, and which type of encryption, e.g. DoH, DoT, DNS server filtering, which may indicate if the DNS Server <NUM> instance supports filtering or not, and which type of filtering, and DNS server location, which may indicate if the DNS Server <NUM> is located on the public Internet or on private or local networks. At step <NUM>, the another node <NUM> transparently forwards to the device <NUM> the above UE Policy for DNS in a PDU Session Establishment Response, which is received by the device <NUM> in accordance with Action <NUM>. At step <NUM>, the device <NUM> stores the UE policy for DNS. The PDU Session is therefore established.

<FIG> is a continuation of the procedure depicted in <FIG>. Application traffic is received back and forth from the Application Server <NUM>. At step 20the device <NUM> starts an edge computing application, e.g., example. When the device <NUM> detects the UE application, example. com, tries to send application traffic which matches the Traffic Descriptor, e.g. appld=example. com, in the UDNSP policy, the device <NUM> may, in accordance with Action <NUM>, select the DNS server <NUM> instance in the DNS Descriptor in order to resolve all DNS queries from that application, and with higher precedence than the default DNS server for the user's PDU session. If the device <NUM> received several UDNSP policies for the appID, the device <NUM> may select one of the DNS server instances according to the UDNSP policies received for that appID and their precedence. The device <NUM> may perform step <NUM> for each application. Therefore, the device <NUM> may be enabled to: select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations. At step <NUM>, the device <NUM> triggers a DNS query to the selected DNS Server <NUM> instance in the UE Policy for DNS, in order to resolve the application's FQDN domain, e.g., example. At step <NUM>, the DNS server <NUM> replies to the device <NUM> with a DNS answer including the list of Application Server IP addresses. At step <NUM>, the device <NUM> selects one Application Server IP address from the list and sends the application traffic to it. At steps <NUM>, the fifth node <NUM> detects application traffic based on PDR rules and applies the corresponding actions, e.g., FAR/QER/URR, specifically the FAR instructs to forward the application traffic towards the Application Server <NUM>, which the fifth node <NUM> does at step <NUM>.

As a simplified example overview of the foregoing, embodiments herein may be understood to relate to a mechanism which may enable to solve the earlier described problems of the existing methods, and which may be understood to be based on the definition of a new type of UE policy: a UE DNS Policy (UDNSP), which may allow the operator of the communications network <NUM> to dynamically instruct the device <NUM> on the DNS server instance/s to use on a per application basis and according to different criteria, e.g. user's location, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc..

Whenever a DNS policy may need to be triggered, e.g., after the device <NUM> may trigger a PDU session establishment or when the location of the device <NUM> may change, the first node <NUM> may triggers a new UE policy: UE DNS Policy (UDNSP) which may then be forwarded to the device <NUM>, e.g., through the another node <NUM>.

One advantage of embodiments herein is that they allow the operator of the communications network <NUM> for optimal allocation of different DNS servers based on different criteria, e.g., application, user's location, slice type, DNS server encryption support, DNS server filtering support, DNS server location: on the public Internet or on private or local networks etc, this on a per application basis and specifically for Edge Computing scenarios. As explained earlier, using the proposed solution the device <NUM> may be configured to use: DNS server <NUM>, a first local DNS server, for App <NUM> in location A, DNS server <NUM>, a second local DNS server, for App <NUM> in location B, DNS server <NUM>, a central DNS server for App <NUM> in any location. In other words, the device <NUM> may be able to select different DNS servers for different applications in the same location, and/or select different DNS servers for the same application in different locations. Another advantage of embodiments herein may be that, the allocation of DNS servers in the device <NUM> may be changed or updated by the operator at any moment. Yet another advantage of embodiments herein may be that, the security issues related to DNS cache poisoning may be improved due to the fact that those queries may be handled based on information provided via UDNSP instead of DNS cache. A further advantage of embodiments herein may be that, the time to solve DNS queries may be reduced due to the fact that host names addresses may be provisioned so it may not be needed to check from top to down in the DNS hierarchy. Yet a further advantage of embodiments herein may be that, an application may receive the most suitable application server according to the area in which subscriber is connected. The first node <NUM> may determine the service area of a certain Edge Cloud by means of the mapping of the location of the device <NUM> to the corresponding DNS server resolving the IP addresses for the Edge Cloud.

<FIG> depicts two different examples in panels a) and b), respectively, of the arrangement that the first node <NUM> may comprise to perform the method actions described above in relation to <FIG>, <FIG>, <FIG> or <FIG>. In some embodiments, the first node <NUM> may comprise the following arrangement depicted in <FIG>. The first node <NUM> may be understood to be for handling usage of the DNS server <NUM> in the communications network <NUM>. The first node <NUM> is configured to operate in the communications network <NUM>.

Several embodiments are comprised herein. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. In <FIG>, optional boxes are indicated by dashed lines. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the first node <NUM> and will thus not be repeated here. For example, the first node <NUM> the first node <NUM> may be configured to be a PCF, the another node <NUM> may be configured to be an AMF, and the second node <NUM> may be configured to be a UDR or a further node configured to operate in the communications network <NUM>. The device <NUM> may be configured to be a UE.

The first node <NUM> is configured to, e.g. by means of an obtaining unit <NUM> within the first node <NUM> configured to, obtain the one or more first indications. The one or more first indications are configured to indicate the one or more rules on how the device <NUM> configured to operate in the communications network <NUM> is to select, based on the one or more criteria, the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The one or more first indications are configured to comprise the explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

The first node <NUM> is also configured to, e.g. by means of a sending unit <NUM> within the first node <NUM> configured to, send the second indication to one of: the another node <NUM> configured to operate in the communications network <NUM> and the device <NUM>. The second indication is configured to indicate the one or more first indications configured to be obtained.

The one or more criteria may be configured to comprise one or more of: a) the application for which the device <NUM> is to instantiate the DNS server <NUM>, b) whether or not the application is for edge computing, c) the first location of the device <NUM>, d) the second location of the DNS server <NUM>, e) the type of slice configured to be instantiated for the use of the DNS server <NUM> by the device <NUM>, and f) the RAT configured to be to be used by the device <NUM> to run the application.

The one or more first indications may be configured to indicate one or more of: a) the address of the DNS server <NUM>, b) whether or not the DNS server <NUM> may support encryption, c) whether or not the DNS server <NUM> supports filtering, d) the type of filtering configured to be supported by the DNS server <NUM>, and e) the second location of the DNS server <NUM>.

The one or more first indications may be configured to indicate a policy.

The second indication may be further configured to indicate one or more of: a) the order of enforcement of the policy, and b) the type of traffic the policy may apply to.

In some embodiments, the first node <NUM> may be configured to, e.g. by means of a selecting unit <NUM> within the first node <NUM> configured to, select the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The selecting may be configured to be based on the one or more first indications configured to be indicated. The second indication may be configured to indicate the selected DNS server <NUM>.

The first node <NUM> may be further configured to, e.g. by means of the sending unit <NUM> further configured to, send the query to the DNS server <NUM> configured to be selected based on the address of the application.

In some embodiments, the first node <NUM> may be configured to, e.g. by means of a determining unit <NUM> within the first node <NUM> configured to, determine whether or not to select another DNS server, based on whether or not the response to the query is received from the DNS server <NUM> configured to be selected.

In some embodiments, the one or more first indications may be configured to be obtained from the second node <NUM> configured to operate in the communications network <NUM>.

The embodiments herein may be implemented through one or more processors, such as a processor <NUM> in the first node <NUM> depicted in <FIG>, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the first node <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the first node <NUM>.

The first node <NUM> may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the first node <NUM>.

In some embodiments, the first node <NUM> may receive information from, e.g., the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, and/or the device <NUM> through a receiving port <NUM>. In some examples, the receiving port <NUM> may be, for example, connected to one or more antennas in the first node <NUM>. In other embodiments, the first node <NUM> may receive information from another structure in the communications network <NUM> through the receiving port <NUM>. Since the receiving port <NUM> may be in communication with the processor <NUM>, the receiving port <NUM> may then send the received information to the processor <NUM>. The receiving port <NUM> may also be configured to receive other information.

The processor <NUM> in the first node <NUM> may be further configured to transmit or send information to e.g., the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM> and/or another structure in the communications network <NUM>, through a sending port <NUM>, which may be in communication with the processor <NUM>, and the memory <NUM>.

Those skilled in the art will also appreciate that any of the units <NUM>-<NUM> described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor <NUM>, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

Any of the units <NUM>-<NUM> described above may be the processor <NUM> of the first node <NUM>, or an application running on such processor.

Thus, the methods according to the embodiments described herein for the first node <NUM> may be respectively implemented by means of a computer program <NUM> product, comprising instructions, i.e., software code portions, which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the first node <NUM>. The computer program <NUM> product may be stored on a computer-readable storage medium <NUM>. The computer-readable storage medium <NUM>, having stored thereon the computer program <NUM>, may comprise instructions which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the first node <NUM>. In some embodiments, the computer-readable storage medium <NUM> may be a non-transitory computer-readable storage medium, such as a CD ROM disc, a memory stick, or stored in the cloud space. In other embodiments, the computer program <NUM> product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium <NUM>, as described above.

The first node <NUM> may comprise an interface unit to facilitate communications between the first node <NUM> and other nodes or devices, e.g., the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM> and/or another structure in the communications network <NUM>. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the first node <NUM> may comprise the following arrangement depicted in <FIG>. The first node <NUM> may comprise a processing circuitry <NUM>, e.g., one or more processors such as the processor <NUM>, in the first node <NUM> and the memory <NUM>. The first node <NUM> may also comprise a radio circuitry <NUM>, which may comprise e.g., the receiving port <NUM> and the sending port <NUM>. The processing circuitry <NUM> may be configured to, or operable to, perform the method actions according to <FIG>, <FIG>, <FIG> and/or <FIG>, in a similar manner as that described in relation to <FIG>. The radio circuitry <NUM> may be configured to set up and maintain at least a wireless connection with the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM> and/or another structure in the communications network <NUM>.

Hence, embodiments herein also relate to the first node <NUM> operative to handle usage of a DNS server <NUM> in the communications network <NUM>, the first node <NUM> being operative to operate in the communications network <NUM>. The first node <NUM> may comprise the processing circuitry <NUM> and the memory <NUM>, said memory <NUM> containing instructions executable by said processing circuitry <NUM>, whereby the first node <NUM> is further operative to perform the actions described herein in relation to the first node <NUM>, e.g., in <FIG>, <FIG>, <FIG> and/or <FIG>.

<FIG> depicts two different examples in panels a) and b), respectively, of the arrangement that the device <NUM> may comprise to perform the method actions described above in relation to <FIG>, <FIG>, <FIG> and/or <FIG>. In some embodiments, the device <NUM> may comprise the following arrangement depicted in <FIG>. The device <NUM> may be understood to be for handling usage of a DNS server <NUM> in the communications network <NUM>. The device <NUM> is configured to operate in the communications network <NUM>.

The device <NUM> is configured to, e.g. by means of a receiving unit <NUM> within the device <NUM> configured to, receive, from the first node <NUM> configured to operate in the communications network <NUM>, the second indication. The second indication is configured to indicate the one or more first indications configured to indicate the one or more rules on how the device <NUM> is to select, based on the one or more criteria, the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The second indication is configured to comprise the explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

The device <NUM> is also configured to, e.g. by means of a selecting unit <NUM> within the device <NUM> configured to, select the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The selecting is configured to be based on the second indication configured to be received.

The embodiments herein may be implemented through one or more processors, such as a processor <NUM> in the device <NUM> depicted in <FIG>, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the device <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the device <NUM>.

The device <NUM> may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the device <NUM>.

In some embodiments, the device <NUM> may receive information from, e.g., the first node <NUM>, the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, and/or any of the one or more DNS servers <NUM>, through a receiving port <NUM>. In some examples, the receiving port <NUM> may be, for example, connected to one or more antennas in the device <NUM>. In other embodiments, the device <NUM> may receive information from another structure in the communications network <NUM> through the receiving port <NUM>. Since the receiving port <NUM> may be in communication with the processor <NUM>, the receiving port <NUM> may then send the received information to the processor <NUM>. The receiving port <NUM> may also be configured to receive other information.

The processor <NUM> in the device <NUM> may be further configured to transmit or send information to e.g., the first node <NUM>, the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM> and/or another structure in the communications network <NUM>, through a sending port <NUM>, which may be in communication with the processor <NUM>, and the memory <NUM>.

Any of the units <NUM>-<NUM> described above may be the processor <NUM> of the device <NUM>, or an application running on such processor.

Thus, the methods according to the embodiments described herein for the device <NUM> may be respectively implemented by means of a computer program <NUM> product, comprising instructions, i.e., software code portions, which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the device <NUM>. The computer program <NUM> product may be stored on a computer-readable storage medium <NUM>. The computer-readable storage medium <NUM>, having stored thereon the computer program <NUM>, may comprise instructions which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the device <NUM>. In some embodiments, the computer-readable storage medium <NUM> may be a non-transitory computer-readable storage medium, such as a CD ROM disc, a memory stick, or stored in the cloud space. In other embodiments, the computer program <NUM> product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium <NUM>, as described above.

The device <NUM> may comprise an interface unit to facilitate communications between the device <NUM> and other nodes or devices, e.g., the first node <NUM>, the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM> and/or another structure in the communications network <NUM>. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the device <NUM> may comprise the following arrangement depicted in <FIG>. The device <NUM> may comprise a processing circuitry <NUM>, e.g., one or more processors such as the processor <NUM>, in the device <NUM> and the memory <NUM>. The device <NUM> may also comprise a radio circuitry <NUM>, which may comprise e.g., the receiving port <NUM> and the sending port <NUM>. The processing circuitry <NUM> may be configured to, or operable to, perform the method actions according to <FIG>, <FIG>, <FIG> and/or <FIG>, in a similar manner as that described in relation to <FIG>. The radio circuitry <NUM> may be configured to set up and maintain at least a wireless connection with the first node <NUM>, the second node <NUM>, the another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM> and/or another structure in the communications network <NUM>.

Hence, embodiments herein also relate to the device <NUM> operative to handle usage of a DNS server <NUM> in the communications network <NUM>, the device <NUM> being operative to operate in the communications network <NUM>. The device <NUM> may comprise the processing circuitry <NUM> and the memory <NUM>, said memory <NUM> containing instructions executable by said processing circuitry <NUM>, whereby the device <NUM> is further operative to perform the actions described herein in relation to the device <NUM>, e.g., in <FIG>, <FIG>, <FIG> and/or <FIG>.

<FIG> depicts two different examples in panels a) and b), respectively, of the arrangement that the second node <NUM> may comprise to perform the method actions described above in relation to <FIG>, <FIG>, <FIG>, and/or <FIG>. In some embodiments, the second node <NUM> may comprise the following arrangement depicted in <FIG>. The second node <NUM> may be understood to be configured to handle usage of a DNS server <NUM> in the communications network <NUM>. The second node <NUM> may be configured to operate in the communications network <NUM>.

Several embodiments are comprised herein. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. In <FIG>, optional boxes are indicated by dashed lines. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the second node <NUM> and will thus not be repeated here. For example, the first node <NUM> the first node <NUM> may be configured to be a PCF, the another node <NUM> may be configured to be an AMF, and the second node <NUM> may be configured to be a UDR or a further node configured to operate in the communications network <NUM>. The device <NUM> may be configured to be a UE.

The second node <NUM> is configured to, e.g. by means of a sending unit <NUM> within the second node <NUM> configured to send, to the first node <NUM> configured to operate in the communications network <NUM>, the one or more first indications. The one or more first indications are configured to indicate the one or more rules on how a device <NUM> configured to operate in the communications network <NUM> is to select, based the on one or more criteria, the DNS server <NUM>, out of the one or more DNS servers <NUM>, for use by the device <NUM> for the application. The one or more first indications are configured to comprise the explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications.

The embodiments herein may be implemented through one or more processors, such as a processor <NUM> in the second node <NUM> depicted in <FIG>, together with computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the in the second node <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the second node <NUM>.

The second node <NUM> may further comprise a memory <NUM> comprising one or more memory units. The memory <NUM> is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the second node <NUM>.

In some embodiments, the second node <NUM> may receive information from, e.g., the first node <NUM>, another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, and/or the device <NUM>, through a receiving port <NUM>. In some examples, the receiving port <NUM> may be, for example, connected to one or more antennas in the second node <NUM>. In other embodiments, the second node <NUM> may receive information from another structure in the communications network <NUM> through the receiving port <NUM>. Since the receiving port <NUM> may be in communication with the processor <NUM>, the receiving port <NUM> may then send the received information to the processor <NUM>. The receiving port <NUM> may also be configured to receive other information.

The processor <NUM> in the second node <NUM> may be further configured to transmit or send information to e.g., the first node <NUM>, another node <NUM>, the fourth node <NUM>, and the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM>, and/or another structure in the communications network <NUM>, through a sending port <NUM>, which may be in communication with the processor <NUM>, and the memory <NUM>.

Those skilled in the art will also appreciate that the unit <NUM> described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processor <NUM>, perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

The unit <NUM> described above may be the processor <NUM> of the second node <NUM>, or an application running on such processor.

Thus, the methods according to the embodiments described herein for the second node <NUM> may be respectively implemented by means of a computer program <NUM> product, comprising instructions, i.e., software code portions, which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the second node <NUM>. The computer program <NUM> product may be stored on a computer-readable storage medium <NUM>. The computer-readable storage medium <NUM>, having stored thereon the computer program <NUM>, may comprise instructions which, when executed on at least one processor <NUM>, cause the at least one processor <NUM> to carry out the actions described herein, as performed by the second node <NUM>. In some embodiments, the computer-readable storage medium <NUM> may be a non-transitory computer-readable storage medium, such as a CD ROM disc, a memory stick, or stored in the cloud space. In other embodiments, the computer program <NUM> product may be stored on a carrier containing the computer program, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium <NUM>, as described above.

The second node <NUM> may comprise an interface unit to facilitate communications between the second node <NUM> and other nodes or devices, e.g., the first node <NUM>, another node <NUM>, the fourth node <NUM>, the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM>, and/or another structure in the communications network <NUM>. In some particular examples, the interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

In other embodiments, the second node <NUM> may comprise the following arrangement depicted in <FIG>. The second node <NUM> may comprise a processing circuitry <NUM>, e.g., one or more processors such as the processor <NUM>, in the second node <NUM> and the memory <NUM>. The second node <NUM> may also comprise a radio circuitry <NUM>, which may comprise e.g., the receiving port <NUM> and the sending port <NUM>. The processing circuitry <NUM> may be configured to, or operable to, perform the method actions according to <FIG>, <FIG>, <FIG> and/or <FIG>, in a similar manner as that described in relation to <FIG>. The radio circuitry <NUM> may be configured to set up and maintain at least a wireless connection with the first node <NUM>, another node <NUM>, the fourth node <NUM>, and the fifth node <NUM>, the sixth node <NUM>, the DNS server <NUM>, any of the one or more DNS servers <NUM>, the device <NUM>, and/or another structure in the communications network <NUM>.

Hence, embodiments herein also relate to the second node <NUM> operative to handle usage of a DNS server <NUM> in the communications network <NUM>, the second node <NUM> being operative to operate in the communications network <NUM>. The second node <NUM> may comprise the processing circuitry <NUM> and the memory <NUM>, said memory <NUM> containing instructions executable by said processing circuitry <NUM>, whereby the second node <NUM> is further operative to perform the actions described herein in relation to the second node <NUM>, e.g., in <FIG>, <FIG>, <FIG> and/or <FIG>.

When using the word "comprise" or "comprising", it shall be interpreted as non- limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the invention.

As used herein, the expression "at least one of:" followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the "and" term, may be understood to mean that only one of the list of alternatives may apply, more than one of the list of alternatives may apply or all of the list of alternatives may apply. This expression may be understood to be equivalent to the expression "at least one of:" followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the "or" term.

Any of the terms processor and circuitry may be understood herein as a hardware component.

As used herein, the expression "in some embodiments" has been used to indicate that the features of the embodiment described may be combined with any other embodiment or example disclosed herein.

Claim 1:
A method, performed by a first node (<NUM>), for handling usage of a Domain Name Service, DNS, server (<NUM>) in a communications network (<NUM>), the first node (<NUM>) operating in the communications network (<NUM>), the method comprising:
- obtaining (<NUM>) one or more first indications, the one or more first indications indicating one or more rules on how a device (<NUM>) operating in the communications network (<NUM>) is to select, based on one or more criteria, a DNS server (<NUM>), out of one or more DNS servers (<NUM>), for use by the device (<NUM>) for an application, wherein the one or more first indications comprise an explicit indication of one of: a) which applications the one or more rules apply to, and b) that the one or more rules apply to all applications, wherein the one or more criteria comprise one or more of:
i. the application for which the device (<NUM>) is to instantiate the DNS server (<NUM>),
ii. whether or not the application is for edge computing,
iii. a first location of the device (<NUM>),
iv. a second location of the DNS server (<NUM>),
v. a type of slice instantiated for the use of the DNS server (<NUM>) by the device (<NUM>), and
vi. a Radio Access Technology to be used by the device (<NUM>) to run the application, and
- sending (<NUM>) a second indication to one of: another node (<NUM>) operating in the communications network (<NUM>) and the device (<NUM>), the second indication indicating the obtained one or more first indications, wherein the first node (<NUM>) is a Policy Charging Function, PCF, and the another node (<NUM>) is an Access and Mobility Management Function, AMF, the device (<NUM>) is a User Equipment, UE, and the second indication is a UE DNS Policy generated by the first node (<NUM>).