Patent Description:
It would be desirable to provide a more efficient and optimal selection of (e.g. mobile) network resources for UE sessions in a multi-access edge computing (MEC) environment, especially suitable for use in a <NUM> mobile network.

<CIT> describes, according to its abstract, a communication system including: a communication terminal; a base station configured to connect the communication terminal; a management apparatus configured to manage positional information regarding the communication terminal; a server configured to provide a communication service for the communication terminal, a communication apparatus configured to connect the base station and the server; and a control apparatus configured to control start or stop of a communication function included in the communication apparatus. The server is arranged in the vicinity of the base station, the management apparatus transmits the positional information regarding the communication terminal to the control apparatus, the control apparatus controls start or stop of the communication function that the communication apparatus includes based on the positional information, and the control apparatus notifies the communication terminal of start or stop of the communication function that the communication apparatus includes via the management apparatus.

ETSI DRAFT "Multi-access Edge Computing (MEC); Phase <NUM>: Use Cases and Requirements" specifies, according to its "Scope" section, the requirements for Multi-access Edge Computing with the aim of promoting interoperability and deployments.

<CIT> describes, according to its abstract, a method for accessing a content located in a telecommunications network implemented by a user terminal connected to an equipment item of at least one access network of the telecommunications network. This method comprises a step of receiving at least one message originating from the equipment item, comprising an information item relating to the location of the said user terminal, a step of generating a request for access to a content comprising a location indication obtained on the basis of the information item extracted from the message, a step of dispatching the said access request generated to a server able to select a contents server and a step of receiving an address of the contents server selected.

In accordance with common practice the various features illustrated in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may not depict all of the components of a given system, method or device. Finally, like reference numerals may be used to denote like features throughout the specification and figures.

Numerous details are described in order to provide a thorough understanding of the example implementations shown in the drawings. However, the drawings merely show some example aspects of the present disclosure and are therefore not to be considered limiting. Those of ordinary skill in the art will appreciate that other effective aspects and/or variants do not include all of the specific details described herein. Moreover, well-known systems, methods, components, devices and circuits have not been described in exhaustive detail so as not to obscure more pertinent aspects of the example implementations described herein.

Although the present disclosure may disclose any number of inventions, the invention or group of related inventions to which the present European application/patent relates is defined in the appended claims.

Methods and apparatus for use in selecting (e.g. mobile) network resources for user equipment (UE) sessions based on location of multi-access edge computing (MEC) resources and applications of interest are described herein.

More detailed and alternative techniques and implementations are provided herein as will be described below.

As described in the Background section, it would be desirable to provide a more efficient and optimal selection of (e.g. mobile) network resources for user equipment (UE) sessions in a multi-access edge computing (MEC) environment, especially suitable for use in a <NUM> mobile network.

<FIG> is an illustrative representation of a network architecture 100A of a <NUM> mobile network configured to facilitate communications for a UE <NUM>. In general, network architecture 100a includes common control network functions (CCNF) <NUM> and a plurality of slice-specific core network functions <NUM>. UE <NUM> may obtain access to the mobile network via an access network (AN) <NUM>, which may be a radio access network (RAN). In the present disclosure, the UEs operating in the <NUM> mobile network may be any suitable type of devices, such as cellular telephones, smart phones, tablet devices, Internet of Things (IoT) devices, and machine-to-machine (M2M) communication devices, to name but a few.

CCNF <NUM> includes a plurality of network functions (NFs) which commonly support all sessions for UE <NUM>. UE <NUM> may be connected to and served by a single CCNF <NUM> at a time, although multiple sessions of UE <NUM> may be served by different slice-specific core network functions <NUM>. CCNF <NUM> may include, for example, an access and mobility management function (AMF) and a network slice selection function (NSSF). UE-level mobility management, authentication, and network slice instance selection are examples of common functionalities provided by CCNF <NUM>.

Slice-specific core network functions of network slices <NUM> are separated into control plane (CP) NFs <NUM> and user plane (UP) NFs <NUM>. In general, the user plane carries user traffic while the control plane carries network signaling. CP NFs <NUM> are shown in <FIG> as CP NF <NUM> through CP NF n, and UP NFs <NUM> are shown in <FIG> as UP NF <NUM> through UP NF n. CP NFs <NUM> may include, for example, a session management function (SMF), whereas UP NFs <NUM> may include, for example, a user plane function (UPF).

<FIG> is an illustrative representation of a more detailed network architecture 100B of the <NUM> mobile network of <FIG>. As provided in 3GPP standards for <NUM> (e.g. 3GPP <NUM> and <NUM>), network architecture 100b for the <NUM> mobile network may include an authentication server function (AUSF) <NUM>, a unified data management (UDM) <NUM> (having a unified data repository or UDR), an AMF <NUM>, a policy control function (PCF) <NUM>, an SMF 120a, and a UPF 122a. A plurality of interfaces or reference points N1 through N15 shown in <FIG> may define the communications and/or protocols between each of the entities, as described in the relevant (evolving) standards documents. One or more application functions, such as an application function (AF) <NUM>, may connect to the <NUM> mobile network via PCF <NUM>. One or more data networks (DN) <NUM> having application servers (AS) may be connected to the <NUM> mobile network through UPFs such as UPF 122a.

UPF 122a is part of the user plane and all other NFs (i.e. AMF <NUM>, SMF 120a, PCF <NUM>, AUSF <NUM>, and UDM <NUM>) are part of the control plane. Separation of user and control planes guarantees that each plane resource can be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. The NFs in the CP are modularized functions; for example, AMF and SMF are independent functions allowing for independent evolution and scaling. As specifically illustrated in <FIG>, NFs such as SMF 120a and UPF 122a of <FIG> may be provided as specific instances in a first network slice (e.g. network slice <NUM>). Additional instances of NFs for additional network slices may be provided as well, as illustrated by SMF 120b and UPF 122b provided as additional specific instances in a second network slice (e.g. network slice <NUM>).

In <FIG>, a service-based architecture 100C of the <NUM> mobile network of <FIG> is illustrated. Network node functions in the service-based architecture 100C of <FIG>, not shown in <FIG>, include a network exposure function (NEF) entity <NUM> and an NF repository function (NRF) <NUM>. A plurality of interfaces N1 through N6, as well as interfaces Nnef, Nnrf, Npcf, Nudm, Nausf, Namf, Nsmf, and Naf, may define the communications and/or protocols between each of the entities, as described in the relevant (evolving) standards.

Mobile-edge computing, now referred to as multi-access edge computing (MEC), may be understood to be a cloud-based service environment provided at the "edge" of the network, bringing real-time, high-bandwidth, low-latency access to information. One goal of MEC is to reduce network congestion and improve application performance by performing task processes closer to the user. MEC aims to improve the delivery of content and applications to those users. MEC use cases realized today include Augmented Reality (AR) and Virtual Reality (VR); connected car, which also thrives in high-bandwidth, low-latency, highly-available settings; and various Internet of Things (IoT) applications that rely on high performance and smart utilization of network resources.

Large public venues and enterprise organizations are amongst the beneficiaries of MEC. In large-scale situations where localized venue service are important, content is delivered to onsite consumers from a MEC server located at the venue. The content is locally-stored, processed, and delivered, without requiring a backhaul or centralized core network. Large enterprises are increasingly motivated to process users locally, rather than backhaul traffic to a central network, e.g. with use of small cell networks.

<NUM> networks operating according to 3GPP <NUM> specifications are a future target environment for MEC deployments. MEC is acknowledged as one of the key pillars for meeting the demanding Key Performance Indicators (KPIs) of <NUM>, especially as far as low latency and bandwidth efficiency are concerned. ETSI ISGMEC (Industry Specification Group for Multi-access Edge Computing) is the home of technical standards for edge computing; this group has already published a set of specifications associated with MEC.

The design approach taken by 3GPP allows the mapping of MEC onto Application Functions (AF) that can use the services and information offered by other 3GPP network functions based on the configured policies. In addition, a number of enabling functionalities were defined to provide flexible support for different deployments of MEC and to support MEC in case of user mobility events. The new <NUM> architecture is described and explained in more detail in the next clause.

<FIG> is an illustrative representation of a generic MEC system architecture <NUM> of an MEC system 204A for use in a <NUM> mobile network (e.g. the mobile network of <FIG>). Architecture <NUM> may include, at the system level, an MEC orchestrator <NUM> and, at the distributed host level, an MEC platform <NUM>, an MEC platform manager <NUM>, a virtualization infrastructure <NUM>, a plurality of applications <NUM>, and a plurality of services <NUM>.

Architecture <NUM> of the MEC system illustrated in <FIG> may be provided for the <NUM> network environment of <FIG>, where some of the functional entities of MEC interact with NFs of the <NUM> core network. Discussion of <NUM> entities (e.g. <FIG>) in relation to MEC entities will now follow.

NFs and associated services produced in a <NUM> network are registered with the NRF, while services produced by applications are registered in a service registry of the MEC platform <NUM>. Service registration is part of an application enablement functionality. To use a service, a network function may directly interact with an NF that produces the service. A list of available services may be discovered from the NRF. Some of the services may be accessible only via the NEF, which is also available to untrusted entities that are external to the domain, for accessing the service. In other words, the NEF acts as a centralized point for service exposure and also has a role in authorizing access requests originating from outside of the system.

As described earlier, one of the key concepts in <NUM> is "network slicing. " Network slicing allows the allocation of the required features and resources from the available network functions to different services or to tenants that are using the services. A Network Slice Selection Function (NSSF) of the <NUM> mobile network is a function that assists in the selection of suitable network slice instances for users, as well as the allocation of an AMF. An MEC application (i.e. an application hosted in a distributed cloud of an MEC system) can belong to one or more network slices that have been configured in the <NUM> core network.

The UDM is responsible for many services related to users and subscriptions. It generates the 3GPP AKA authentication credentials, handles user identification related information, manages access authorization (e.g. roaming restrictions), registers the user serving NFs (serving AMF, SMF), supports service continuity by keeping record of SMF/Data Network Name (DNN) assignments, supports Lawful Interception (LI) procedures in outbound roaming by acting as a contact point and performs subscription management procedures.

Policies and rules in the <NUM> system may be handled by the PCF. The PCF is also the function that services an AF (e.g. an MEC platform). The PCF may be accessed either directly or indirectly via the NEF, depending whether the AF is considered trusted or not; in the case of traffic steering, is may depend on whether the corresponding PDU session is known at the time of the request.

The UPF has a key role in an integrated MEC deployment in a <NUM> network. UPFs may be seen as a distributed and configurable data plane from the MEC system perspective. Thus, in some deployments, the local UPF may be part of the MEC implementation. To better illustrate, <FIG> shows how MEC system 204A may be deployed in an integrated manner in a <NUM> network. More specifically, what is shown in <FIG> is an illustrative representation of an MEC system architecture <NUM> of an integrated MEC deployment with a <NUM> network (e.g. the mobile network of <FIG>).

As shown in <FIG>, the MEC system 204A may be deployed on the N6 reference point of a UPF <NUM>, i.e. in a data network <NUM> external to the <NUM> system. This is enabled by the flexibility in locating a UPF. MEC orchestrator <NUM> may be configured to operate as an AF in the <NUM> network and interact with an NEF; in some cases, it may directly interact with target <NUM> NFs. On the MEC host level, MEC platform <NUM> is configured to interact with <NUM> NFs, again in the role of an AF. The MEC host, i.e. the host level functional entities, are most often deployed in a data network in the <NUM> system. While the NEF as a core network function is a system level entity deployed centrally together with similar NFs, an instance of NEF may also be deployed in the edge to allow low latency, high throughput service access from an MEC host.

Managing user mobility is a central function in a mobile communications system. In a <NUM> system, it is the AMF that handles mobility related procedures. In addition, the AMF is responsible for the termination of RAN control plane and Non-Access Stratum (NAS) procedures, protecting the integrity of signaling, management of registrations, connections and reachability, interfacing with the LI function for access and mobility events, providing authentication and authorization for the access layer, and hosting Security Anchor Functionality (SEAF). With the SBA, the AMF provides communication and reachability services for other NFs and it also allows subscriptions to receive notifications regarding mobility events.

Some of the functionality provided by the SMF may include session management, IP address allocation and management, DHCP services, selection / re-selection and control of the UPF, configuring the traffic rules for the UPF, LI for session management events, charging and support for roaming. As MEC services may be offered in both centralized and edge clouds, for example, the SMF may play a significant role due to its role in selecting and controlling the UPF. The SMF exposes service operations to allow MEC as a <NUM> AF to manage PDU sessions, control policy settings and traffic rules, and subscribe to notifications on session management events.

Logically, MEC hosts are deployed in the edge or central data network. The UPF may handle the steering of user plane traffic towards the targeted MEC applications in the data network. The locations of the data networks and the UPF are a choice of the network operator, and the network operator may choose to place the physical computing resources based on technical and business parameters such as available site facilities, supported applications and their requirements, measured or estimated user load etc. In some implementations, the MEC management system, orchestrating the operation of MEC hosts and applications, may be configured to determine dynamically where to deploy the MEC applications.

In terms of physical deployment of MEC hosts, there are different options available based on various operational, performance and/or security related requirements. To better illustrate, <FIG> is an illustrative representation of network node arrangements <NUM> of some options for the physical location of the MEC and associated applications. In a node arrangement <NUM>, the MEC and the local UPF may be collocated with the base station. In a node arrangement <NUM>, the MEC may be collocated with a transmission node, possibly with a local UPF. In a node arrangement <NUM>, the MEC and the local UPF may be collocated with a network aggregation point. In a node arrangement <NUM>, the MEC may be collocated with Core Network (CN) functions (i.e. in the same data center). Other node arrangements may be realized as one skilled in the art would readily appreciate.

As is apparent, the physical deployment options indicate that MEC may be flexibly deployed in different locations, from near the base station to closer to the central data network. Common to most or all deployments is the UPF that is deployed and used to steer the traffic towards targeted MEC applications and towards the network.

Again, an MEC system combines the environments of networking and computing at the edge of the network to optimize the performance for ultra-low latency and high bandwidth services. A direct consequence of hosting the applications at the edge, however, is the exposure of those applications to UE mobility. The UEs are indeed expected to be mobile, and their movements may render the location of the currently-used edge application non-optimal in the long run, even though the underlying network maintained the service continuity between the endpoints. For the MEC system to maintain the application requirements in a mobile environment, application mobility may be most desirable (if not necessary). In practice, this means that the application instance that is serving the user may be changed to a new location.

Thus, application mobility is another feature of the MEC system. Here, it may be necessary to be able to relocate a user's context and/or application instance from one MEC host to another to continue offering an optimized service experience for the user. Application mobility is a part of service continuity support, in which the service to the UE will resume once the user's context and/or application instance has been relocated to another MEC host.

Shifting gears back to <NUM> network functionality, what is shown in <FIG> is a flow diagram <NUM> for describing a method of selecting NF instances or nodes in the mobile network (e.g. SMF and UPF selection) for use in creating and/or establishing a session for a UE, according to some implementations of the present disclosure.

The method of <FIG> may be performed at one or more mobility nodes, such as one or more NF or NRF nodes (e.g. an AMF, SMF, and/or NRF, e.g., as described). The node may include one or more processors and one or more memories coupled to the one or more processors. The method may be embodied as a computer program product (e.g. memory) including a computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the node for performing the steps of the method. The medium may be a non-transitory medium, such as a hard disk or an optical disc, or a transitory medium, such as a cable or wireless signal.

In <FIG>, a UE <NUM> may send a message to the network for service. Here, an AMF <NUM> may receive a message which indicates a session establishment request for establishing a PDU session for the UE (step <NUM> of <FIG>). In response, the AMF <NUM> may consult with an NRF <NUM> for discovery of one or more SMF instances that may be appropriate for use in the session (step <NUM> of <FIG>). An SMF instance may be selected for use in the session for the UE (step <NUM> of <FIG>). The discovery and/or selection of the SMF instance may be based on a set of parameters, where at least some data items are obtained from a UDM/UDR <NUM>. Then, the AMF <NUM> may send a message to the selected SMF (step <NUM> of <FIG>). The selected SMF may receive the message from the AMF. The message may indicate a create session request for creating a PDU session for the UE. In response, the SMF may consult with the NRF for discovery of one or more UPF instances that may be appropriate for use in the session (step <NUM> of <FIG>). A UPF instance may be selected for use in the session for the UE (step <NUM> of <FIG>), The discovery and/or selection of the UPF instance may be based on a set of parameters, where at least some data items are obtained from a UDM/UDR <NUM>.

As indicated earlier, it would be desirable to provide a more efficient and optimal selection of network resources for UE sessions in MEC environment. For MEC, this would provide even lower latency and bandwidth efficiency.

Accordingly, the selection of the UPF instance in step <NUM> of <FIG> may be based on a set of parameters which include one or more locations of one or more MEC resources and applications of interest for UE <NUM>. A location of an application of interest may be derived or determined from a server address of an application server obtained from an address resolution server <NUM> (e.g. a DNS server).

In preferred implementations, the server address may be a client subnet location-dependent server address for the application server. Here, a DNS request may be submitted to address resolution server <NUM> with a client subnet of the client (e.g. the UE) for obtaining the client subnet location-dependent server address. See steps A and B of <FIG>. The subnet or truncated address of the client may be used to make a more informed determination by the address resolution server <NUM> for the selection of a more (or most) optimal (e.g. the closest) application server. In preferred implementations, the DNS query processing may be performed in accordance with RFC <NUM>, "Client Subnet in DNS Queries," an Extension Mechanism for DNS option (see e.g. www. afasterinternet.

<FIG> is a flowchart <NUM> for describing a method of selecting NF instances or nodes in the mobile network (e.g. SMF and UPF selection) for creating and/or establishing a session for a UE according to some implementations of the present disclosure. The method of <FIG> may be viewed as a flowchart representation of the flow of <FIG>. Beginning at a start block <NUM> of <FIG>, an AMF may receive a message which indicates a session establishment request for establishing a PDU session for a UE (step <NUM> of <FIG>). In response, the AMF may consult with an NRF for discovery of one or more SMF instances that may be appropriate for use in the session (step <NUM> of <FIG>). An SMF instance may be selected for use in the session for the UE (step <NUM> of <FIG>). The one or more SMF instances may be discovered and/or selected based on at least one service, application, or subscription requirement obtained according to the request.

Once the SMF is identified, the AMF may send a message to the selected SMF. The SMF may receive the message from the AMF (step <NUM> of <FIG>). The message may indicate a create session request for creating a PDU session for the UE. In response, the SMF may consult with the NRF for discovery of one or more UPF instances that may be appropriate for use in the session (step <NUM> of <FIG>). A UPF instance may be selected for use in the session for the UE (step <NUM> of <FIG>). The UPF instance has an assigned or associated pool of IP addresses. The one or more UPF instances may be discovered and/or selected based on at least one service, application, or subscription requirement obtained according to the request. Notably, the selection of the UPF instance may be based on one or more locations of one or more MEC resources and applications of interest for UE <NUM>. Here, as described in relation to <FIG>, a location of an application server for an application of interest may be derived or determined from a server address obtained from an address resolution server in a client subnet-based DNS query, where the server address is a client subnet location-dependent server address.

<FIG> is a flow diagram 700A for describing a method of selecting a UPF instance based on MEC and applications of interest according to some implementations of the present disclosure. <FIG> is a flowchart 700B which may be viewed as a flowchart representation of the method of <FIG>. The method of <FIG> may be performed at one or more mobility nodes, such as one or more NF or NRF nodes (e.g. an SMF and/or NRF). The node may include one or more processors and one or more memories coupled to the one or more processors. The method may be embodied as a computer program product (e.g. memory) including a computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the node for performing the steps of the method. The medium may be a non-transitory medium, such as a hard disk or an optical disc, or a transitory medium, such as a cable or wireless signal.

The method in the flowchart 700B of <FIG> will be described together with the flow diagram 700A of <FIG>. Beginning at a start block <NUM> of <FIG>, the mobility node (e.g. SMF) may receive a message which indicates a request for creating a session for a UE (step <NUM> of <FIG>; step <NUM> of <FIG>). A location of the UE may be obtained (step <NUM> of <FIG>). In addition, locations of MEC resources and applications of interest may be obtained (step <NUM> of <FIG>). A UPF instance may then be selected based on a set of parameters which include the location of UE and the locations of MEC resources and applications of interest (step <NUM> of <FIG>; step <NUM> of <FIG>). A pool of IP addresses may be assigned to or associated with the selected UPF instance. A message which indicates a request for establishing a session may be sent to the selected UPF instance (step <NUM> of <FIG>). Here, the selected UPF instance may be programmed or configured with information, including information for use of the applications of interest (step <NUM> of <FIG>). An acknowledgement of the session establishment may be sent to the UE (step of <FIG>).

Again, in at least some implementations of step <NUM> of <FIG> (and step <NUM> of <FIG>), a location of an application of interest may be derived or otherwise determined from an application server address which is a client subnet location-dependent server address that is received in response to a client subnet-based DNS query made by a UPF on behalf of a UE.

In some implementations, an initial (e.g. limited) set or list of applications for the UE may be considered in the selection of a UPF instance with its assigned pool of IP addresses. This initial information may be known or pre-configured in the network, for example, known or pre-configured at and for use by the SMF. For example, the set of applications of interest may be limited to those applications that are locally configured for the UE. As another example, the set of applications of interest may be limited to those that are applications in actual or frequency use (e.g. as tallied by the UE or UPF). As yet another example, the set of applications of interest may be limited to those that are learned or identified from a top-<NUM> or top-<NUM> website list (i.e. a set or subset thereof). As even another example, the set of applications of interest may be limited to those applications of application service providers (ASPs) that a service provider (SP) has a relationship with or alternatively SP-managed applications. Any suitable combination of these examples may also be implemented.

In at least some additional implementations of step <NUM> of <FIG> (step <NUM> of <FIG>), location data of the location(s) of the application(s) of interest may be (regularly) obtained by the SMF from updates from UPF instances associated with the SMF. As UPF instances are configured to facilitate the processing of DNS requests for clients for their use of applications at application servers, the UPF instances may cache this information according to time-to-live (TTL) settings, and regularly provide or submit such information to the SMF (e.g. for a more suitable or optimal UPF selection).

<FIG> is a flowchart for describing a method of selecting a UPF instance based on MEC and applications of interest according to some implementations of the present disclosure. The method of <FIG> is similar to the method of <FIG>, where it is described that a more varied set of parameters may be used in the UPF selection decision. Beginning at a start block <NUM> of <FIG>, the mobility node (e.g. SMF) may receive a message which indicates a request for creating a session for a UE (step <NUM> of <FIG>). A set of parameters may be obtained (step <NUM> of FIG. A UPF instance may then be selected based on the set of parameters (step <NUM> of <FIG>).

In preferred implementations, the set of parameters may include at least some of the following data items (information box <NUM> of <FIG>): (a) location(s) of candidate application(s); (b) location(s) of candidate applications on MEC resources; (c) capacity of MEC resources; (d) subscription data associated with the UE; (e) an enterprise identity associated with a PDU session; and (f) a DNN associated with a PDU session. Here again, a location of an application server address for an application of interest may be based on or determined from a server address which may be a client subnet location-dependent server address. Also, location data of the location(s) of the application(s) of interest may be (regularly) obtained by the SMF with updates from UPF instances associated with the SMF (step <NUM> of <FIG>). As UPF instances are configured to facilitate the processing of DNS requests for clients for their use of applications at application servers, the UPF instances may cache this information according to TTL settings and regularly submit such information to the SMF for a more optimal UPF selection (as previously and elsewhere described herein).

<FIG> is a flow diagram 800A for describing a method of processing DNS requests according to some implementations of the present disclosure. <FIG> is a flowchart 800B which may be viewed as a flowchart representation of the method of <FIG>. The method of <FIG> may be performed at one or more mobility nodes, such as one or more NF nodes (e.g. a UPF, or a UPF plus an address resolution server). The node may include one or more processors and one or more memories coupled to the one or more processors. The method may be embodied as a computer program product (e.g. memory) including a computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the node for performing the steps of the method. The medium may be a non-transitory medium, such as a hard disk or an optical disc, or a transitory medium, such as a cable or wireless signal.

The method in the flowchart 800B of <FIG> will be described together with the flow diagram 800A of <FIG>. Beginning at a start block <NUM> of <FIG>, the mobility node (e.g. UPF) may receive from a UE a message which indicates a DNS request for obtaining an address of a server associated with a requested application (step <NUM> of <FIG>; step <NUM> of <FIG>). A message which indicates a DNS request for the server address may be sent to an address resolution server, where the DNS request includes a client subnet address of the UE (step <NUM> of <FIG>; step <NUM> of <FIG>). A message which includes a server address may be received from the address resolution server, and this server address may be a client subnet location-dependent server address (step <NUM> of <FIG>; step <NUM> of <FIG>). A message which includes the client subnet location-dependent server address may be sent to the UE as a DNS response (step <NUM> of <FIG>; step <NUM> of <FIG>). A stored mapping or association between an identifier of the application and the received client subnet location-dependent server address may be cached in memory (e.g. at the UPF instance) (step <NUM> of <FIG>; step <NUM> of <FIG>). The cached data may be stored according to TTL settings. Where the steps of the method are repeated for different requests and applications, the cache may be built with a plurality of such stored mappings or associations.

In some implementations, location data of the location associated with the application which is based on or determined from the server address (e.g. the stored mapping or association) may be submitted to the SMF, for a more optimal selection of UPF instances at the SMF.

The cached data which are stored according to TTL settings in step <NUM> may be utilized by the UPF instance for a more efficient processing of subsequent DNS requests from the same or different UEs. <FIG> is a flowchart 300C for describing a method of processing DNS requests according to some implementations of the present disclosure. The method of <FIG> may follow the method of <FIG> and be performed by the same UPF. Beginning at a start block <NUM> of <FIG>, the mobility node (e.g. the UPF) may receive from a UE (the same or different UE) a message which indicates a DNS request for obtaining an address of a server associated with a requested application (step <NUM> of <FIG>). The cache may be consulted for a stored mapping or association between an identifier of the requested application and (client subnet location-dependent) server address (step <NUM> of <FIG>). If the information is not cached ("no" at step <NUM> of <FIG>), then the method may proceed back to step <NUM> of <FIG>. If the information is indeed cached ("yes" at step <NUM> of <FIG>), then the method may continue where the client subnet location-dependent server address is retrieved from the cache based on the stored mapping or association (step <NUM> of <FIG>). A message which includes the client subnet location-dependent server address may be sent to the UE as a DNS response (step <NUM> of <FIG>).

<FIG> is a flow diagram 900A for describing a method of processing DNS requests and providing location data to an SMF for UPF selection (i.e. based on DNS cache data of stored mappings or associations between application identities (or domain names) and client subnet location-dependent service addresses) according to some implementations of the present disclosure. Note that steps <NUM>, <NUM>, <NUM>, and <NUM> of <FIG> may correspond to many processing steps of <FIG> already described above.

<FIG> is a flowchart 900B which may be viewed as a flowchart representation of part of the method of <FIG>. The method of <FIG> may be performed at one or more mobility nodes, such as one or more NF nodes (e.g. UPF, or UPF plus address resolution server, or UPF and SMF, etc.). The node may include one or more processors and one or more memories coupled to the one or more processors. The method may be embodied as a computer program product (e.g. memory) including a computer readable medium and instructions stored in the computer readable medium, where the instructions are executable on one or more processors of the node for performing the steps of the method. The medium may be a non-transitory medium, such as a hard disk or an optical disc, or a transitory medium, such as a cable or wireless signal.

Beginning at a start block <NUM> of <FIG>, a cache of stored mappings or associations between application identifiers (or domain names) and server addresses, determined based on UE DNS requests, may be maintained and regularly updated / changed (step <NUM> of <FIG>; step <NUM> of <FIG>). Again, the caches may be caches of server addresses (e.g. based on TTL settings) obtained by the UPF instance from serving DNS requests from UEs. The server addresses may be client subnet location-dependent server addresses. Updates and/or changes of location data associated with the applications from the updated / changed cache data may be regularly sent to the SMF associated with the UPF instance (step <NUM> of FIG. 9C; steps <NUM> and <NUM> of <FIG>). The SMF may therefore be configured to select UPF instances based on (regularly) updated information.

Regarding <FIG>, it is understood that location-based DNS results will change as MEC resource locations are added and/or modified, and application assignments to those locations are modified. This will result in modification of the initial, static information known by the SMF. In some implementations, the UPF may be configured to (intelligently) act on cached content, for example, based on or in response to identifying certain information or conditions. The information or conditions may include temporary network conditions, such as updated knowledge of available MEC resources, connectivity changes, etc. Such information or conditions may be locally learnt and/or received as a result of Operations Administration and Maintenance (OAM) actions (e.g. provided via the SMF).

<FIG> is a table 1000A which is an example of an MEC selection table according to some implementations of the present disclosure. Such a table 1000A is an illustrative representation of how data may be input, output, determined, and/or stored with use in the techniques described above. In table 1000A, an application identity or profile is indicated as an input in a column <NUM> and a UE location is indicated as an input in a column <NUM>. An MEC location or identification is indicated as an output in a column <NUM> and description information is indicated in a column <NUM>. As indicated, when the application profile is Sales_Cisco and the UE location is 1000_Block_Main_St, then the MEC is determined to be MEC_Downtown. When the application profile is Sales_Cisco and the UE location is <NUM>nd_Avenue, then the MEC is determined to be MEC_West Side. When the application profile is Marketing_Cisco and the UE location is <NUM>nd_Avenue, then the MEC is determined to be MEC_North Side.

<FIG> is a table 1000B which is an example of an UPF and IP pool selection table according to some implementations of the present disclosure. Such a table 1000B is an example of an illustrative representation of how data may be input, output, determined, and/or stored with use in the techniques described above. In table 1000B, an MEC location is indicated as an input in a column <NUM> and a UE location is indicated as an input in a column <NUM>. A UPF instance is indicated as an output in a column <NUM> and a pool of IP addresses is indicated as an output in a column <NUM>. As indicated, when the MEC is MEC_Downtown and the UE location is 1000_Block_Main_St, then the UPF is determined to be MEC_Downtown and its assigned pool of IP addresses is <NUM>. <NUM> / <NUM>. When the MEC is MEC_West Side and the UE location is <NUM>nd_Avenue, then the UPF is determined to be UPF_North Shore Downtown and its assigned pool of IP addresses is <NUM>. <NUM> / <NUM>. When the MEC is MEC_North Side and the UE location is <NUM>nd_Avenue, then the UPF is determined to be UPF_North Shore Downtown and its assigned pool of IP addresses is <NUM>. <NUM> / <NUM>.

Thus, methods and apparatus for use in selecting (e.g. mobile) network resources for UE sessions based on locations of MEC resources and applications of interest have been described. In one illustrative example, a mobility node (e.g. an SMF) may receive a message which indicates a request for creating a session for a user equipment (UE). A user plane function (UPF) instance for the session may be selected based on a set of parameters. The set of parameters may include one or more location(s) of one or more multi-access edge computing (MEC) resources and applications of interest for the UE. Location data associated with the MEC resources and applications may be derived, provisioned or otherwise determined from server addresses obtained from UPF processing of domain name server (DNS) queries associated with the applications. The server addresses or location data derived therefrom may be regularly submitted to the SMF for improved UPF selection based on locations of MEC resources and applications. In preferred implementations, the server addresses are client subnet location-dependent server addresses obtained from client subnet-based DNS queries.

Implementations of the present disclosure have been shown in the figures to apply to a <NUM> mobile network; however, implementations may be readily applied to other suitable types mobile networks, such as <NUM>, Long Term Evolution (LTE) based networks having a control and user plane separation (CUPS) architecture, as one ordinarily skilled in the art will readily appreciate. In <NUM>/LTE with CUPS, the user plane function may be a gateway - user plane (GW-U). As other examples, the SMF may instead be a GW - control plane (GW-C), the AMF may instead be a mobility management entity (MME), the PCF may instead be a policy and control rules function (PCRF). The SMF and GW-C may be more generally referred to as a CP entity for session management. Other naming conventions may be adopted or realized.

Note that, although in some implementations of the present disclosure, one or more (or all) of the components, functions, and/or techniques described in relation to the figures may be employed together for operation in a cooperative manner, each one of the components, functions, and/or techniques may indeed be employed separately and individually, to facilitate or provide one or more advantages of the present disclosure.

It will also be understood that, although the terms "first," "second," etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first application could be termed a second application, and similarly, a second application could be termed a first application, without changing the meaning of the description, so long as all occurrences of the "first application" are renamed consistently and all occurrences of the "second application" are renamed consistently. The first application and the second application are both applications, but they are not the same application.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the claims. As used in the description of the embodiments and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

Claim 1:
A method (700C) comprising:
receiving (<NUM>, <NUM>), at a user plane function, UPF, for use in a mobile network, from a first user equipment, UE, a first message which indicates a domain name server, DNS, request for obtaining an address of a server associated with a multi-access edge computing, MEC, application;
sending (<NUM>), from the UPF to an address resolution server, a second message which indicates a corresponding DNS request, the corresponding DNS request including a client subnet of the first UE;
receiving (<NUM>), at the UPF from the address resolution server as a DNS response, a third message which includes a client subnet location-dependent server address associated with the MEC application;
sending (<NUM>), from the UPF to the first UE as a DNS response, a message which includes the received client subnet location-dependent server address;
sending (<NUM>), from the UPF to a control plane, CP, entity for session management, the server address or location data determined from the server address; and
selecting (<NUM>), by the CP entity and using the server address or location data, UPF instances for UE sessions based on the location of the MEC application.