Patent Description:
Edge Computing is a network architecture concept that enables cloud computing capabilities and service environments to be deployed at the edge of the cellular network. It promises several benefits such as lower latency, higher bandwidth, reduced backhaul traffic and prospects for several new services.

The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most prominently, it translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been defined by IETF and specifies the technical functionality of the database service that is at its core. It defines the DNS protocol, a detailed specification of the data structures and data communication exchanges used in the DNS, as part of the Internet Protocol Suite. The Internet maintains two principal namespaces, the domain name hierarchy and the Internet Protocol (IP) address spaces. The Domain Name System maintains the domain name hierarchy and provides translation services between it and the address spaces. Internet name servers and a communication protocol implement the Domain Name System. A DNS name server is a server that stores the DNS records for a domain; a DNS name server responds with answers to queries against its database.

DNS today can return different responses based on the perceived topological location of the user. These servers use the IP address of the incoming query to identify that location. Since most queries come from Intermediate Recursive Resolvers, the source address is that of the Recursive Resolver rather than of the query originator. Traditionally, and probably still in the majority of instances, recursive Resolvers are reasonably close in the topological sense to the query originator. For these resolvers, using their own IP address is sufficient for Authoritative Nameservers that tailor responses based upon location of the querier.

To address the case of Recursive Resolvers that are not topologically close to the query originator IETF has defined RFC <NUM> which defines an EDNS0 (that is, a DNS extension according to RFC6891) option to convey network information that is relevant to the DNS message. It can carry sufficient network information about the originator (in form of a client IP subnet) for the Authoritative Nameserver to tailor responses. It also provides for the Authoritative Nameserver to indicate the scope of network addresses for which the tailored answer is intended.

The next generation (<NUM>) networks architecture is defined in 3GPP Rel. <FIG> (PRIOR ART) depicts the <NUM> reference architecture as defined by 3GPP TS <NUM>. In the scope of this application, it is worth to highlight, the role of the Network Functions as illustrated in <FIG> (prior art):.

A Network Function (NF), which can be an SMF, UPF, AF, etc. can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure. An NF on the control plane of the <NUM> Service based architecture may be an NF service consumer or NF service producer.

Each NF as sown in <FIG> (PRIOR ART) is self-contained and offer different services to distinct NF consumers. Each of the NF services offered by a Network Function is self-contained (e.g., cloud native microservices), reusable and use management schemes independently of other NF services offered by the same Network Function (e.g. for scaling, healing, etc). Each NF service provided by an NF shall be accessible by means of standardized Application Protocol interface (API) specified by 3GPP in 3GPP TS <NUM>. 5xx series.

Each NF is deployed as one or more NF instance or as an NF instance set, i.e., a group of interchangeable NF instances of the same type, supporting the same services and the same Network Slice(s). The NF instances in the same NF Set may be stateless and geographically distributed providing the services from several locations and several execution instances in each location. Each NF instance can have multiple instances of the same service, NF service set, i.e., a group of interchangeable NF service instances of the same service type within an NF instance. See <FIG>, <FIG> and c (PRIOR ART).

NF/service instances within a single Set have access to common session context / database. Note that although the above description of the NF seems to be applied to control plane NFs in the <NUM> SBA, it may be possible that the UPF which is part of the user plane in the <NUM> SBA, be enhanced to also support SBA principles.

As stated in 3GPP TS <NUM> clause <NUM>, Edge computing enables operator and 3rd party services to be hosted close to the UE's access point of attachment, so as to achieve an efficient service delivery through the reduced end-to-end latency and load on the transport network. The <NUM> Core Network selects a UPF close to the UE and executes the traffic steering from the UPF to the local Data Network via the N6 interface to the external data network.

A number of enablers have been defined that alone or in combination support Edge Computing (clause <NUM>. in 3GPP TS <NUM>), including:.

At least three connectivity models have been found relevant for Edge computing. They are captured in 3GPP Technical Report TR <NUM> clause <NUM> illustrated in <FIG> (prior art), including:.

Document "<NPL>, discloses a solution to address both KI#<NUM>: Discovery of Edge Application Server and KI#<NUM>: Edge relocation. When the EAS serving the UE changes during edge relocation, in order to maintain service continuity, the UE needs to discover and connect to the target EAS. The solution solves this problem by leveraging and enhancing AF influence.

<CIT> discloses a mobility management processing method that includes receiving, by an SMF network element, a data notification message that includes a PDU session identifier and that is sent by a UPF network element, and determining, based on the PDU session identifier, a session and service continuity SSC mode corresponding to the PDU session identifier and/or a service area of the user plane function UPF network element, where the UPF network element is a network element that establishes a PDU session corresponding to the PDU session identifier, determining, by the SMF network element, a paging area based on the SSC mode and/or the service area of the UPF network element, and sending, by the SMF network element, a first message including the paging area to an access and mobility management function AMF network element, where the first message is used to trigger the AMF network element to page, in the paging area, a terminal that establishes the PDU session by using the UPF network element.

According to the present disclosure, a method, a server system, a computer-readable medium and a computer program according to the independent claims are provided. Developments are set forth in the dependent claims.

According to a first aspect of the present disclosure, there is provided a method performed by a one or more network functions in a network. The method comprises receiving a DNS query for a service related to an application in a User Equipment, UE, over a first Packet Data Unit, PDU, session anchored at a first User Plane Function, UPF; determining that UPF re-anchoring is required for the application based on the DNS query; in response to determining that UPF re-anchoring is required, establishing a second PDU session to a local UPF to be used between the application in the UE and an edge application server; in response to determining that UPF re-anchoring is not required, providing the service for the application as triggered via the first UPF; and in response to determining that re-anchoring is successful: - dropping the DNS query, and - facilitating setup of the application through the new anchor by providing a DNS resolver address at PDU session re-establishment procedure at UPF re-anchoring to force the UE to send another DNS request over the new PDU session.

According to a second aspect of the present disclosure, there is provided a server system adapted to perform the first aspect.

According to a third aspect of the present disclosure, there is provided a non-transitory computer readable medium containing a computer program or instructions, wherein when the computer program or instructions is executed by a compute server, causes it to perform the first aspect.

According to a fourth aspect of the present disclosure, there is provided a computer program comprising instructions which, when executed by at least one processor of a server system, causes the server system to carry out the steps of the first aspect.

Whenever in the following disclosure any of the above-stated aspects (corresponding to the independent claims) is disclosed as "optional" (e.g., due to usage of conjunctive terms, such as "can", "may", "should", etc.), it is nevertheless to be read as "mandatory".

Hereinabove and in the following, "examples" pertain to principles underlying the claimed subject-matter and/or being useful for understanding the claimed subject-matter, while "embodiments" pertain to the claimed subject-matter within the claim scope.

Whenever in this description an "embodiment" is described, reference is to be made to the above figure list to determine whether this is to be read as "embodiment" or "example".

The embodiments are described herein using the <NUM> system as an example, however, it will be apparent to a skilled person in the art that the embodiments described herein can be applied to network functions or system of network functions performing similar edge computing and relocation based on application related trigger functionality, but may be a <NUM> or <NUM> or subsequent generations of networks.

The following are referred to in this application:
Stub Resolver: A simple DNS protocol implementation on the client side as described in [RFC1034], Section <NUM>.

Authoritative Nameserver: A nameserver that has authority over one or more DNS zones. These are normally not contacted by Stub Resolver or end user clients directly but by Recursive Resolvers. Described in [RFC1035], Section <NUM>.

Recursive Resolver: A nameserver that is responsible for resolving domain names for clients by following the domain's delegation chain. Recursive Resolvers frequently use caches to be able to respond to client queries quickly. Described in [RFC1035], Section <NUM>.

Forwarding Resolver: A nameserver that passes that responsibility to another Recursive Resolver, called a "Forwarder" in [RFC2308], Section <NUM>. Intermediate Nameserver: Any nameserver in between the Stub Resolver and the Authoritative Nameserver, such as a Recursive Resolver or a Forwarding Resolver. DNS is the most commonly used mechanism for Application clients to discover the IP address of Applications in the internet. It allows users to handle application hostnames and have them translated into the IP address of the Application Server.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (PGW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node or a compute server implementing or hosting one or more network function/ NF instance/ NF set, such as Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

CP or UP Function: A function in a network, which has a defined functional behavior and defined interfaces.

3GPP Mobile Terminals have a DNS Stub Resolver in their Operative System that originates DNS queries as required by the Applications in the UE. At PDU session establishment, the Mobile Network can provide the UE with the address of a DNS server in the PCO, typically the operator DNS. The UE DNS client sends then the DNS queries of applications using that PDU session to the provided DNS server.

With Edge Computing (EC), Applications Servers can be distributed and be deployed at the edge of the cellular networks. In this scenario, there is a desire to be able to select the Edge Application Server that is closest to the UE. It is the topological distance that matters, that is the number of hops or the time it takes for a packet to travel from one host to the other, and that is not necessarily related to geographical distance, but it is related to how the traffic is routed between the UE and the Application Server. Therefore, for edge Computing both Edge Application Server and a suitable local UPF that steers the application traffic received on the N6 interface to the best access needs to be selected.

Note: There could be different UPFs for each of these two roles.

Centralization of resources is better than distribution from total cost of ownership point of view. Solutions which allow for example dynamic ULCL insertion are preferred.

When the Recursive Resolver is behind a central PDU session anchor and so topologically far from the query originator. Its IP address cannot be used to tailor the response and provide an Edge Application server close to the UE. The response will in principle include the address of an Application Server which is close to the central PDU session anchor, even if another AS is deployed closer to the UE.

The 3GPP Technical Report TR <NUM> studies and performs evaluations of potential architecture enhancements to support Edge Computing (EC) in the <NUM> Core network (5GC) for Rel-<NUM>. One of the two main objectives is to study the potential system enhancements for enhanced Edge Computing support, including the discovery of IP address of application server deployed in Edge Computing environment.

Several solutions have been proposed in TR <NUM> for EAS discovery The solutions are targeting different connectivity models for Edge Computing.

Different solutions proposed for EAS discovery and selection in 3GPP TR <NUM> currently assume that:.

However, there is an important scenario that has not been handled. It could be assumed that the Mobile Network Operator (MNO) deployments will gradually distribute PSAs and during such migration phases, it may be that distributed PSAs can handle only a fraction of the UE traffic in the area of interest due to reasons such as cost, scalability, Internet access limitation etc.. A solution would therefore be needed that provides a transition from the Centralized Anchor Point to the Distributed Anchor Point connectivity model on-demand, i.e., for specific UEs that would like to initiate sessions for which EC applies.

In this document, various embodiments describe a solution to this problem. Some embodiments present a functionality of on-demand transition to the Distributed Anchor Point connectivity model for a UE that initiates an EC related session. The trigger for the transition is e.g., the UE DNS query requesting FQDN resolution for an EC application. Based on the request, the MNO (e.g., SMF) decides if a Distributed Anchor Point is to be assigned for the UE PDU Session. If a Distributed Anchor Point is to be assigned, then the MNO either relocates the current PSA or sets up a new PDU session for the UE with a local PSA. The original DNS query is dropped, letting the UE repeat the DNS request through the new (local) PSA after failing to receive a response to the original request within a retransmission time window. The DNS which now receives the retransmitted request through the new (local) PSA resolves the FQDN into an AS close to the user location.

This is a solution for Application Server discovery and selection for Edge Computing in Mobile Networks that allows.

hence providing distributed anchors on a per-need basis which can contribute significantly in reducing the EC related operational costs in certain operator deployment scenarios.

The functionality required can be implemented independently or integrated to an existing network function (NF) of the <NUM> SBA, such as the SMF. If integrated with an SMF, the SMF could provide the following enhancements or simplifications, e.g.,.

<FIG> illustrates one example of a cellular communications system <NUM> in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system <NUM> is a <NUM> system (5GS) including a NR Radio Access Network (RAN) or an Evolved Packet System (EPS) including a LTE RAN. In this example, the RAN includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in LTE are referred to as eNBs and in <NUM> NR are referred to as gNBs, controlling corresponding (macro) cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the (macro) cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as (macro) cells <NUM> and individually as (macro) cell <NUM>. The RAN may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The cellular communications system <NUM> also includes a core network <NUM>, which in the 5GS is referred to as the <NUM> core (5GC). The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to the core network <NUM>.

Embodiments for the generic functionality of the proposed new logic is shown in <FIG> that illustrates a method in accordance with one or more embodiments. The pre-requisite of the method is that the user (UE) has a preestablished PDU session, and that for cost efficiency, the PDU session has been assigned a central PSA by for example an SMF in the <NUM> Core. The method starts with step <NUM> of receiving a trigger related to a specific application (App) to be started within the UE PDU session. There are multiple alternative embodiments for this trigger, each implying a slightly different procedure, e.g.:.

Once the trigger has been received, the new logic identifies at step <NUM> the App and checks the relevant SLA configurations and may also check or request for the policies related to the given App and user (PDU) session. At step <NUM>, If UPF re-anchoring is required for the App, the at step <NUM>, it initiates or triggers initiation of the UPF re-anchoring procedure of the corresponding PDU session, else no re-anchoring takes place (step <NUM>). If at step <NUM>, UPF re-anchoring was successful, then the method proceeds by facilitating at step <NUM> the App setup through the new anchor, by providing a DNS resolver address at PDU session re-establishment procedure at UPF re-anchoring to force the UE to send another DNS request over the new PDU session. Otherwise the application continues over the previous UPF (step <NUM>).

An embodiment of a method performed by the new logic is illustrated in <FIG>. The new logic may be co-located within an existing NF of the <NUM> Core (such as SMF or UPF) or the NF in <NUM> Core is enhanced with the additional logic to support the embodiments herein. Other suitable NF could be used to host the additional logic. The new logic may also be a standalone network function NF. In this embodiment, the augmented NF or standalone NF receives a DNS query at step <NUM> (also referred to as request) from the UE over the PDU session. If the augmented NF is an SMF, the UPF first receives the DNS query over N3 reference point, filters out the DNS query and sends it to the SMF over N4 reference point. The DNS query from the client in the UE triggers initiation of a UPF re-anchoring by the augmented NF or standalone NF in the network. At step <NUM>, if DNS over TLS or DNS over HTTP over TLS is used with the DNS query, the network is configured such that the NF that receives the DNS query (standalone NF or NF hosting the new logic or the UPF terminating the PDU session or the N3 reference point), terminates the secure connection. If the SMF is enhanced with the additional logic, the UPF could also terminate the secure connection for the DNS request received over N3 interface and forwards the DNS query to the SMF hosting the new logic, The augmented NF or standalone NF buffers the DNS query, extracts the FQDN and checks the relevant SLA configurations. It may further check or request for policies related to the given service (FQDN) and the user (PDU) session. At step <NUM>, if it determines that re-anchoring is needed or should be applied for the service (i.e., App), it initiates at step <NUM> the re-anchoring procedure for the given session. Otherwise, the DNS request (query) is forwarded towards the DNS system/server (step <NUM>). If at step <NUM>, re-anchoring was successful or acknowledged, then the NF drops the initial DNS query (request) at step <NUM>, i.e., does not forward it to the DNS system/server.

When dropping the DNS request (query), the UE would subsequently retransmit another request after expiration of an internal retransmission time for the DNS request (query). If the re-anchoring was unsuccessful at step <NUM> or a timer associated to the buffering of the trigger expires before getting an indication of a successful re-anchoring, handle the DNS request by forwarding to the DNS or handling the trigger if the trigger is application request or data.

<FIG> illustrates an example sequence diagram for an embodiment illustrating the functionality of triggering UPF re-anchoring based on a DNS request implemented in a separate NF named a DNS application Function (AF). The DNS AF is not a full fledge DNS server as described herein.

When the UE establishes a PDU session for which Edge Computing (EC) should be applied, the <NUM> Core Network existing mechanisms could be used to enable the UE to send the DNS queries to the DNS AF. Example of such mechanism includes sending by the SMF to the UE in a PDU session establishment accept message, the PCO information element that comprises the DNS AF address to be used as a DNS server. The established PDU session is used for the communication of application traffic. The detailed steps are described below:.

The transmission of the Application Traffic starts between the UE and the selected Edge AS over the local PSA/UPF2.

The case when the proposed functionality for a DNS query trigger is deployed in the SMF offers possibilities for simplification, as depicted in <FIG>. The pre-requisite shown in Steps <NUM>-0a and <NUM>-0b consist of:.

As part of the PDU Session establishment, the SMF provides to the UE a PCO information element indicating the DNS address to use for sending DNS requests. The SMF also configures the UPF is to forward certain DNS requests to the SMF. The following describes the steps illustrated in the sequence diagram of <FIG> following the pre-requisite steps <NUM>-0a and <NUM>-0b.

Step <NUM>-<NUM>, the PDU session is already established. the EC service is identified by an FQDN, the AS-FQDN. The application (App) in the UE sends a DNS discovery request to discover the Edge Application Server (EAS). The DNS discovery request is forwarded by the central PSA (UPF1) to the SMF.

Step <NUM>-<NUM>, the SMF extracts the FQDN and determines whether the App (with FQDN) triggers UPF re-anchoring for Edge Breakout. If yes, then the SMF buffers the DNS request. The determination whether UPF re-anchoring for the application could be based either on SLA information locally configured in the SMF or based on the PCC Rules provisioned by the PCF for the PDU Session.

Step <NUM>-<NUM>, the DNAI provided does not point to a specific UE location but represents the closest PSA to the UE. The SMF selects a local PSA(UPF2) that is the closest possible to the UE for the application.

If the latest (or more recent, or current) UE Location is not available, the SMF retrieves the UE location from the AMF by invoking Namf_EventExposure service with OneTime Report type (as described in 3GPP TS <NUM>, clause <NUM>. The location is then used in selecting the local PSA (UPF2).

Step <NUM>-<NUM>. The SMF initiates re-anchoring to the selected local PSA (UPF2). Any of the existing SSC mode <NUM> and SSC mode <NUM> procedures could be applied, where the SMF requests the UE to re-establish the PDU session (via for example a PDU session establishment modification/release with indication to re-establish the PDU session) and the local PSA (UPF2) is assigned as the local anchor for the PDU session. The SMF provides a DNS resolver address in the PCO IE to the UE as part of the new PDU session establishment procedure with to the UE. Usage reporting for the relevant EC flows is activated in the local PSA (UPF2) to track the activity.

Note: inactivity reports from UPF2 may later trigger another re-anchoring back to a central PSA.

Step <NUM>-<NUM>, The SMF drops the DNS request buffered at step <NUM>-<NUM>.

Step <NUM>. 6a, <NUM>-6b, The UE sends again the DNS Request for that same FQDN (e.g., after expiration timer at the UE). The DNS request goes through the Local PSA (UPF2) to the DNS resolver provided at the session establishment of the new session, and it is resolved to an Edge AS as described in Solution <NUM>. X of TR <NUM>. The Application Traffic then starts towards the selected Edge AS.

Examples not being part of the invention describing when the trigger for UPF re-anchoring is received at the core network from an external AF are described herein and illustrated in <FIG>.

Step <NUM>-<NUM>, The external AF receives a trigger for an App setup message request over an established PDU session in the core network, where the PDU session is anchored at a central PSA/UPF1. The App setup request may be for example a TCP Syn or an HTTP request, or other application suitable protocol).

Step <NUM>-<NUM>, The AF determines whether the App could benefit from UE re-anchoring to a local PSA(UPF2). As an example, based on the current UE IP address as well as the AS server distribution.

Step <NUM>-<NUM>- Step <NUM>-<NUM>, As in Steps <NUM>-<NUM> to <NUM>-<NUM> in <FIG> (note the usage of the DNAI is for this purpose as described in the referenced steps.

Step <NUM>-<NUM>, The external AF transmits an App setup response to the UE in response to the setup message in Step <NUM>-<NUM>. The App setup response may be for example a redirect which resolves to an EAS that is closer to the new anchor.

Step <NUM>-<NUM>, Same as Step <NUM>-<NUM> in <FIG>.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. The network node <NUM> may be, for example, a radio access node, such as a base station <NUM> or <NUM>, or a core network node. As illustrated, the network node <NUM> includes a control system <NUM> that includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. The network node hosting a core network network function software is also as a server that may be deployed in a datacenter.

In addition, if the network node <NUM> is a radio access node, for example, it may include one or more radio units <NUM> that each includes one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The radio units <NUM> may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) <NUM> is external to the control system <NUM> and connected to the control system <NUM> via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) <NUM> and potentially the antenna(s) <NUM> are integrated together with the control system <NUM>. The one or more processors <NUM> operate to provide one or more functions of a network node <NUM> as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the network node <NUM> according to some embodiments of the present disclosure.

Multiple NFs are used to perform the embodiments described herein. The multiple NFs may be deployed in a system of servers or a single server.

As used herein, a "virtualized" node is an implementation of the network node <NUM> in which at least a portion of the functionality of the network node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node <NUM> includes the control system <NUM> that includes the one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory <NUM>, and the network interface <NUM> and, optionally, the one or more radio units <NUM> that each includes the one or more transmitters <NUM> and the one or more receivers <NUM> coupled to the one or more antennas <NUM>, as described above. The control system <NUM> may be connected to the radio unit(s) <NUM> via, for example, an optical cable or the like. The control system <NUM> is connected to one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM> via the network interface <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the network node <NUM> described herein are implemented at the one or more processing nodes <NUM> or distributed across the control system <NUM> and the one or more processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM>, consisting of one or more NF instances, of the network node <NUM> described herein are implemented as virtual components executed by one or more virtual machines or container implemented in a virtual environment(s) hosted by the processing node(s) <NUM>. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) <NUM> and the control system <NUM> is used in order to carry out at least some of the desired functions <NUM>. Notably, in some embodiments, the control system <NUM> may not be included, in which case the radio unit(s) <NUM> communicate directly with the processing node(s) <NUM> via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node <NUM> or a node (e.g., a processing node <NUM>) which may be a computer server or a system of computer server implementing one or more of the functions <NUM> (NF or NF instance of <NUM> Core) in a virtual environment according to any of the embodiments described herein is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a computer readable medium or non-transitory computer readable medium such as memory). When storing and/or downloading the computer program on the target node, compute server or compute server system enables starting or instantiating, configuring one or more NF, NF instance, NF set.

<FIG> is a schematic block diagram of the network node/server <NUM> according to some other embodiments of the present disclosure. The network node/server <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the network node <NUM> described herein, e.g., SMF. The modules may consist of microservices or the services provided by the NF, where each service is described by its API.

<FIG> is a schematic block diagram of a UE <NUM> according to some embodiments of the present disclosure. As illustrated, the UE <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and one or more transceivers <NUM> each including one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The transceiver(s) <NUM> includes radio-front end circuitry connected to the antenna(s) <NUM> that is configured to condition signals communicated between the antenna(s) <NUM> and the processor(s) <NUM>, as will be appreciated by on of ordinary skill in the art. The processors <NUM> are also referred to herein as processing circuitry. The transceivers <NUM> are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. Note that the UE <NUM> may include additional components such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE <NUM> and/or allowing output of information from the UE <NUM>), a power supply (e.g., a battery and associated power circuitry), etc..

<FIG> illustrates a telecommunication network according to some embodiments of the present disclosure. With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a RAN, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 1206A, 1206B, 1206C, such as Node Bs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1208A, 1208B, 1208C. Each base station 1206A, 1206B, 1206C is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1208C is configured to wirelessly connect to, or be paged by, the corresponding base station 1206C. A second UE <NUM> in coverage area 1208A is wirelessly connectable to the corresponding base station 1206A.

The host computer <NUM> may be under the ownership or control of a service provider or may be operated by the service provider or on behalf of the service provider.

<FIG> illustrates a communication system according to some embodiments of the present disclosure.

The hardware <NUM> may include a communication interface <NUM> for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system <NUM>, as well as a radio interface <NUM> for setting up and maintaining at least a wireless connection <NUM> with the UE <NUM> located in a coverage area served by the base station <NUM>. The connection <NUM> may be direct or it may pass through a core network of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system.

It is noted that the host computer <NUM>, the base station <NUM>, and the UE <NUM> may be similar or identical to the host computer <NUM>, one of the base stations 1206A, 1206B, 1206C, and one of the UEs <NUM>, <NUM> of <FIG>, respectively.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may provide for the ability to measure data usage in terms of packets and thereby provide benefits such as enhance the system's ability to derive a proper traffic model in the mobile network, which is vital for dimensioning and deployment.

The measurements may be implemented in that the software <NUM> and <NUM> causes messages to be transmitted, in particular empty or'dummy' messages, using the OTT connection <NUM> while it monitors propagation times, errors, etc..

Claim 1:
A method performed by a one or more network functions in a network, the method comprising:
receiving (<NUM>) a DNS query for a service related to an application in a User Equipment, UE, over a first Packet Data Unit, PDU, session anchored at a first User Plane Function, UPF;
determining (<NUM>) that UPF re-anchoring is required for the application based on the DNS query;
in response to determining that UPF re-anchoring is required, establishing (<NUM>) a second PDU session to a local UPF to be used between the application in the UE and an edge application server;
in response to determining (<NUM>) that UPF re-anchoring is not required, providing (<NUM>) the service for the application as triggered via the first UPF;
characterized by:
in response to determining (<NUM>) that re-anchoring is successful:
- dropping the DNS query, and
- facilitating (<NUM>) setup of the application through the new anchor by providing a DNS resolver address at PDU session re-establishment procedure at UPF re-anchoring to force the UE to send another DNS request over the new PDU session.