Dynamic service discovery and offload framework for edge computing-based cellular network systems

Abstract

This invention provides a system and method for edge computing in cellular network systems. [Solution] User equipment (UE) or other devices perform service discovery of edge computing resources in a cellular network system and dynamic offload of UE application tasks to the discovered edge computing resources. The device requests edge server site capability information. When performing dynamic offloading, it obtains information on channel status, cellular network parameters, or application requirements to dynamically determine whether the application tasks running on the UE should be offloaded to an edge server or run locally on the UE.

Description

Technical Field

[0001] This application relates to wireless devices, and more particularly, to systems and methods for improved discovery of edge computing resources and offloading to edge computing resources in a cellular network system.

Background Art

[0002] The use of wireless communication systems has been increasing rapidly in recent years. Wireless devices such as smartphones and tablet computers have become increasingly high-performance. Mobile devices (i.e., user equipment devices or UEs) not only support voice calls, but also provide access to the Internet, email, text messaging, and navigation using the Global Positioning System (GPS), and can run advanced applications that utilize these functions. In addition, there are numerous different wireless communication technologies and standards. Some examples of wireless communication standards include GSM, UMTS (associated with, for example, the WCDMA or TD-SCDMA air interface), LTE, LTE Advanced (LTE-A), NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), IEEE802.11 (WLAN or Wi-Fi), BLUETOOTH (trademark), and the like.

[0003] Despite the rapid technological advancements in mobile user devices (UEs), computationally demanding applications on smartphones or tablets remain constrained by limited battery capacity, temperature limits, device size, and cost considerations. To overcome this problem, computationally complex processing can be offloaded to centralized servers, i.e., the cloud. For example, Mobile Cloud Computing (MCC) refers to servers that provide cloud computing resources for mobile users. However, the use of MCC introduces significant communication latency. Such latency is inconvenient and makes computation offloading unsuitable for real-time applications.

[0004] To address this issue, cloud services are being physically moved closer to users, i.e., towards the network's "edge." The concept of Multi-access Edge Computing (MEC), also known as "mobile edge computing" or simply "edge computing," refers to an evolution of cloud computing that brings applications hosted in centralized data centers to the "network edge," that is, physically closer to the data generated by consumers and applications. Edge computing is recognized as one of the key components for meeting the performance requirements of modern cellular networks, such as 5G networks, particularly in terms of reducing latency and improving bandwidth efficiency.

[0005] However, improvements are desired in this area. [Overview of the project]

[0006] This specification presents embodiments of devices, systems, and methods for performing service discovery of edge computing resources in a cellular network system, for devices such as UEs, base stations, or servers. It also presents embodiments of devices capable of dynamically offloading UE application tasks to discovered edge computing resources.

[0007] According to the technology described herein, a wireless device such as a user equipment (UE) comprises at least one antenna, a radio operably coupled to the antenna for communicating with a cellular network, memory for storing applications, and a processor operably coupled to the radio. The applications may have real-time requirements (or low-latency requirements).

[0008] Before offloading a task, a UE, base station, or another device can discover available edge server resources in the vicinity of the UE. As part of the discovery process, a device (e.g., a UE) can request edge server site capability information. Edge server site capability information may include, among other possible information, the computing power of one or more edge servers, the site load of one or more edge servers, and information about the latency between the UE and one or more edge servers.

[0009] When performing discovery, a device (e.g., a UE) can send an edge computing availability request to the cellular network. The request may include information identifying the UE and information identifying the applications running on the UE. The cellular network can receive this request and send an edge computing availability response to the device. The availability response may include information about the available edger server network and site capability information.

[0010] The UE can be configured to obtain (collect and / or receive) information about one or more of the following, among other possible information: channel status, cellular network parameters, or application requirements of an application running on the UE. The UE may dynamically receive some or all of this information, for example, while the UE is operating or while the UE is running an application.

[0011] The UE can also dynamically determine whether application tasks running on the UE should be offloaded to edge servers or executed locally on the UE. This determination can be based on the information mentioned above, such as channel status, cellular network parameters, and / or application requirements. For example, when making this determination, the UE can compare the expected application quality of the experience for offloaded task execution with the expected quality of the experience for local task execution.

[0012] In some embodiments, the UE can calculate a utility function based on one or more application latency or energy consumption associated with offloading the task, and one or more application latency or energy consumption associated with running the task locally on the UE. The utility function may also be based on offload costs and possibly other information. The utility function may be a predetermined function associated with the application or the application type of the application.

[0013] The UE can calculate a value for a utility function based on at least a portion of the information and compare that value to a threshold. The comparison can indicate whether an application task should be offloaded to an edge server or executed locally on the UE. For example, the utility function could represent the difference between the utility or benefit (e.g., in terms of latency, energy consumption, etc.) of offloading the task to an edge server and the utility or benefit of executing the task locally on the UE. If the calculated difference in utility is greater than the threshold, the task can be assigned to remote execution on the edge server. If the calculated difference in utility is less than the threshold, the task can be executed locally on the UE. In some embodiments, the UE can use a first threshold when determining whether to offload a task and a second different threshold when determining whether to bring the offloaded task back to the UE for local execution. This hysteresis can prevent the task from unnecessarily ping-ponging back and forth between remote and local execution.

[0014] The UE may send an application task for offloaded execution on an edge server if it determines that the task should be offloaded. When sending a task to an edge server for offloaded execution, the UE may also send a message containing task parameters to one or more edge servers or cellular networks. Task parameters may include two or more of the following, among other possible information: task priority, latency requirements, periodicity, or computational complexity. Alternatively, the UE may execute the task locally on the UE if it determines that the task should be executed locally on the UE.

[0015] In some cases, the UE may determine that a task cannot be executed on the edge server or locally on the UE due to one or more of the following: a bad channel condition or insufficient power levels on the UE. When this occurs, the UE will not offload the task or execute it locally. Instead, the UE may generate information that will be used to allocate network and computing resources at a future time for the task to be executed.

[0016] In some embodiments, the service discovery and offload operations described above can be performed by an "offload controller." The offload controller can be implemented in the UE as described above. Alternatively, the offload controller can be implemented in a cellular base station, a network element within the core network, or a server outside the core network, or, in some cases, distributed among two or more of these.

[0017] It should be noted that the technologies described herein may be implemented in and / or used with multiple different types of devices, including but not limited to base stations, access points, cellular phones, portable media players, tablet computers, wearable devices, and various other computing devices.

[0018] This summary of the invention is intended to provide a brief overview of some of the subject matter described herein. Therefore, it should be understood that the features described above are merely examples and should not be construed as narrowing the scope or spirit of the subject matter described herein. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, drawings, and claims.

[0019] A more accurate understanding of the present invention can be obtained by considering the following detailed description of the embodiments in conjunction with the following drawings. [Brief explanation of the drawing]

[0020] [Figure 1] FIG. is a diagram showing an exemplary (and simplified) wireless communication system according to some embodiments. [Figure 2] FIG. is a diagram showing an example of an access point communicating with a base station (BS) and user equipment (UE) devices according to some embodiments. [Figure 3] FIG. is an exemplary block diagram of a UE according to one embodiment. [Figure 4] FIG. is an exemplary block diagram of a base station according to one embodiment. [Figure 5] FIG. is a diagram showing an exemplary cellular network system including mobile edge computing according to the prior art. [Figure 6] FIG is a block diagram of a cellular network system including mobile edge computing and an offloading controller unit according to some embodiments. [Figure 7] FIG. is an exemplary block diagram of a server (or network element) according to some embodiments. [Figure 8] FIG. is a flowchart showing service discovery according to some embodiments. [Figure 9] FIG. is a diagram showing task parameters that can be broadcast to a network and an MEC server by an offloading controller unit according to some embodiments. [Figure 10] FIG. is a flowchart showing the operation of a decision and scheduling unit within an offloading controller unit according to some embodiments. [Figure 11] FIG. is a block diagram of a cross-reality (XR) distributed computing architecture according to some embodiments. [Figure 12] FIG. is a block diagram showing a proposed MEC controller implemented in an XR architecture according to some embodiments. [Figure 13]A graph of the kill (death) rate against the median ping in a first-person shooter game. [Figure 14] A diagram showing a method that enables the UE to determine MEC requirements.

[0021] Although the present invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and are described in detail herein. However, the drawings and the detailed description thereof are not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

Mode for Carrying Out the Invention

[0022] Acronym

[0023] Various acronyms are generally used throughout the present disclosure. The definitions of the most prominently used acronyms that may appear throughout the present disclosure are as follows. · UE: User Equipment · RF: Radio Frequency · BS: Base Station · DL: Downlink · UL: Uplink · GSM: Global System for Mobile Communications · UMTS: Universal Mobile Telecommunications System · LTE: Long-Term Evolution · NR: New Radio · TX: Transmit / Transmitting · RX: Receive / Receiving · RAT: Radio Access Technology · MCC: Mobile Cloud Computing · MEC: Multi-Access Edge Computing (or Mobile Edge Computing) · OCU: Offload Controller Unit SDU: Service Discovery Unit APU: Application Profile Unit • SPU: System Profile Unit • DSU: Decision and Scheduling Unit IE: Information element • AF: Application Function • UPF: User Plane Function • PCF: Policy control function • NEF: Network Disclosure Function LADN: Local Area Data Network • URSP: User Root Selection Policy • XR: Cross Reality • PUSCH: Physical uplink shared channel • PDCCH: Physical Downlink Control Channel term The following is a definition of terms that may appear in this disclosure.

[0024] Memory medium – any of the various types of non-temporary memory devices or storage devices. The term “memory medium” is intended to include, for example, installation media such as CD-ROMs, floppy disks, or tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM; non-volatile memory such as magnetic media such as flash, hard drives, or optical storage; registers, or other similar types of memory elements. The memory medium may also include other types of non-temporary memory, or combinations thereof. In addition, the memory medium may be located on a first computer system on which a program is executed, or on a second different computer system connected to the first computer system via a network such as the Internet. In the latter case, the second computer system may provide the first computer system with program instructions to be executed. The term “memory medium” may include two or more memory mediums that may exist in different locations, for example, on different computer systems connected via a network. The memory medium may store program instructions (embodied, for example, as computer programs) that can be executed by one or more processors.

[0025] Carrier medium - memory media as described above, as well as physical transmission media such as buses and networks, and / or other physical transmission media that transmit signals such as electrical signals, electromagnetic signals, or digital signals.

[0026] Computer system (or computer) – any of the various types of computing or processing systems, including personal computer systems (PCs), mainframe computer systems, workstations, network equipment, internet appliances, personal digital assistants (PDAs), television systems, grid computing systems, or other devices or combinations of devices. Generally, the term “computer system” may be broadly defined to include any device (or combination of devices) having at least one processor that executes instructions from a memory medium.

[0027] User equipment (UE) (or "UE device") - any computer system or device of any kind that is mobile or portable and performs wireless communication. Examples of UE devices include mobile phones or smartphones (e.g., iPhone®, Android®-based phones), tablet computers (e.g., iPad®, Samsung Galaxy®), portable gaming devices (e.g., Nintendo DS®, PlayStation Portable®, Gameboy Advance®, iPhone®), wearable devices (e.g., smartwatches, smart glasses), laptops, PDAs, portable internet devices, music players, data storage devices, or other handheld devices, unmanned aerial vehicles (UAVs), unmanned aerial controllers (UACs), etc. Generally, the terms "UE" or "UE device" can be broadly defined to encompass any electronic device, computing device, and / or telecommunications device (or combination of devices) that is easily carried by a user and capable of wireless communication.

[0028] A wireless device is any of the various types of computer systems or devices that perform wireless communication. A wireless device may be portable (or mobile) or fixed or stationary in a location. A UE is an example of a wireless device.

[0029] A communication device is any of the various types of computer systems or devices that perform communication, which may be wired or wireless. A communication device may be portable (or mobile) or fixed or permanently installed in a specific location. A wireless device is an example of a communication device. A UE is another example of a communication device.

[0030] Base station (BS) - The term "base station" has all of its ordinary meanings and includes at least a radio communication station that is installed in a fixed location and used for communication as part of a radiotelephone system or a radio system.

[0031] Processing element (or processor) refers to various elements or combinations of elements that can perform functions within a device, for example, within a user equipment device or within a cellular network device. Processing elements may include, for example, processors and associated memory, parts or circuits of individual processor cores, entire processor cores, processor arrays, circuits such as Application Specific Integrated Circuits (ASICs), programmable hardware elements such as field-programmable gate arrays (FPGAs), and any of the various combinations of the above.

[0032] The term "Wi-Fi" encompasses the full scope of its ordinary meaning and includes, at a minimum, wireless communication networks or RATs (Radio-Aided Networks) that are serviced by wireless LAN (WLAN) access points and provide connectivity to the Internet through these access points. Modern Wi-Fi networks (or WLAN networks) are based on the IEEE 802.11 standard and are marketed under the name "Wi-Fi." Wi-Fi (WLAN) networks are distinct from cellular networks.

[0033] Automatically – This refers to the execution of user input by a computer system (e.g., software run by the computer system) or device (e.g., circuit mechanisms, programmable hardware elements, ASICs, etc.) without the user directly specifying or performing the action or operation. Therefore, the term “automatically” is in contrast to operations performed or specified manually by the user, where the user provides input and directly executes the operation. An automated procedure may be initiated by user-provided input, but the subsequent actions performed “automatically” are not specified by the user; that is, each action performed is not “manually” specified by the user. For example, when a user fills out an electronic form by selecting each field and providing input specifying the information (e.g., by typing information, selecting checkboxes, selecting radio selections, etc.), the computer system must update the form in response to the user action, but this is considered manually filling out the form. The form may also be automatically filled out by a computer system, where the computer system (e.g., software run by the computer system) analyzes the fields of the form and fills it out without user input specifying the answers to the fields. As described above, users can invoke form autofill but do not participate in the actual form completion (for example, the user does not manually specify answers in the fields; rather, the answers are completed automatically). This specification provides various examples of actions that are performed automatically in response to actions taken by the user.

[0034] "Configured to" - Various components can be described as "configured to" perform a task. In such contexts, "configured to" is a broad description that generally means "having a structure" that performs a task or a set of tasks during operation. Thus, a component may be configured to perform a task even when the component is not currently performing that task (for example, a set of conductors may be configured to electrically connect two modules to another module even when the two modules are not connected). In some contexts, "configured to" may be a broad description of a structure that generally means "having a circuit" that performs a task or a set of tasks during operation. Thus, a component may be configured to perform a task even when the component is not currently turned on. Generally, the circuit that forms a structure corresponding to "configured to" may include hardware circuits.

[0035] For convenience, various components may be described in this specification as performing one or more tasks. Such descriptions should be interpreted as including the phrase “configured to perform.” Descriptions of components configured to perform one or more tasks are expressly intended to be exempt from the interpretation of those components under 112, paragraph 6 of the U.S. Patent Act. Figures 1 and 2 - Exemplary Communication System

[0036] Figure 1 shows a simplified exemplary wireless communication system that can implement aspects of the present disclosure according to several embodiments. Note that the system in Figure 1 is merely one example of a possible system, and embodiments can be implemented in various systems as desired.

[0037] As illustrated, an exemplary wireless communication system includes a base station 102 that communicates with one or more (e.g., any number) user devices 106A, 106B, etc. ~ 106N via a transmission medium. In this specification, each user device may be referred to as a “user equipment” (UE) or UE device. Therefore, user device 106 is referred to as a UE or UE device. A UE device is an example of a wireless device.

[0038] Base station 102 may be a base transceiver station (BTS) or a cell site, and may include hardware and / or software that enables wireless communication with UE106A~106N. When base station 102 is implemented in the context of LTE, it may be referred to as "eNodeB" or "eNB" instead. When base station 102 is implemented in the context of 5G NR, it may be referred to as "gNodeB" or "gNB" instead.

[0039] The communication area (or coverage area) of a base station may be referred to as a "cell." The base station 102 and user devices may be configured to communicate over a transmission medium using various radio access technologies (RATs), also known as wireless communication technologies, or telecommunications standards such as GSM, UMTS (WCDMA), LTE, LTE-Advanced (LTE-A), LAA / LTE-U, 5G NR, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), and Wi-Fi.

[0040] Furthermore, base station 102 may be equipped to communicate with network 100 (for example, among various possibilities, the core network of a cellular service provider, a telecommunications network such as the Public Switched Telephone Network (PSTN), and / or the Internet). Thus, base station 102 can facilitate communication between user devices and / or communication between user devices and network 100. In particular, cellular base station 102A can provide UE 106 with various telecommunications capabilities such as voice, SMS, and / or data services.

[0041] Furthermore, as used herein, from the perspective of a UE, a base station may be considered representative of the network insofar as it relates to the UE's uplink and downlink communications. Therefore, a UE communicating with one or more base stations in the network may be interpreted as a UE communicating with the network.

[0042] Base station 102A, and other similar base stations (such as base stations 102B-102N) operating according to the same or different cellular communication standards, may be provided as a network of cells, which can provide continuous or nearly continuous superimposed services over a geographical area to UE106A-106N and similar devices via one or more cellular communication standards.

[0043] Therefore, as shown in Figure 1, base station 102A can function as a “serving cell” for UEs 106A to 106N, and each UE 106 can also receive signals from one or more other cells (which may be provided by base stations 102B to 102N and / or any other base stations) (within their communication range, if possible). Such cells can also facilitate communication between user devices and / or between user devices and the network 100. Such cells may include “macro” cells, “micro” cells, “pico” cells, and / or other cells that provide various other granularities of service area size. For example, base stations 102A to 102B shown in Figure 1 may be macrocells, and base station 102N may be a microcell. Other configurations are also possible.

[0044] In some embodiments, base station 102A may be a next-generation base station, such as a 5G New Radio (5G NR) base station, or a "gNB". In some embodiments, the gNB may be connected to a conventional evolved packet core (EPC) network and / or an NR core (NRC) network. In addition, a gNB cell may include one or more transition and reception points (TRPs). In addition, UEs capable of operating in accordance with 5G NR may be connected to one or more TRPs in one or more gNBs.

[0045] It should be noted that UE106 may be capable of communicating using multiple wireless communication standards. For example, UE106 may be configured to communicate using at least one cellular communication protocol (e.g., GSM, UMTS (associated with WCDMA or TD-SCDMA air interfaces), LTE, LTE-A, 5G NR, HSPA, 3GPP2 CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD)) in addition to a radio network protocol (e.g., Wi-Fi) and / or peer-to-peer wireless communication protocol (e.g., Bluetooth, Wi-Fi peer-to-peer). In addition, or alternatively, UE106 may be configured to communicate using one or more Global Navigational Satellite Systems (GNSS, e.g., GPS or GLONASS), one or more mobile television broadcasting standards (e.g., ATSC-M / H or DVB-H), and / or any other wireless communication protocol, if desired. Other combinations of wireless communication standards (including three or more wireless communication standards) are also possible.

[0046] Figure 2 shows a user equipment (UE) 106 (e.g., one of devices 106A to 106N) communicating with a base station 102 and an access point 112 according to several embodiments. The UE 106 may be a device having both cellular and non-cellular communication capabilities (e.g., Bluetooth, Wi-Fi, etc.), such as a mobile phone, handheld device, computer or tablet, or substantially any type of wireless device as defined above.

[0047] UE106 may include a processor (processing element) configured to execute program instructions stored in memory. By executing such stored instructions, UE106 may perform any of the embodiments described herein. Alternatively or in addition, UE106 may include programmable hardware elements such as a field-programmable gate array (FPGA), an integrated circuit, and / or any of the embodiments described herein, or any part of any of the embodiments described herein (e.g., individually or in combination).

[0048] UE106 may include one or more antennas for communication using one or more wireless communication protocols or technologies. In some embodiments, UE106 may be configured to communicate using, for example, CDMA2000 (1xRTT / 1xEV-DO / HRPD / eHRPD), LTE / LTE-Advanced, or 5G NR using a single shared radio and / or GSM, LTE / LTE-Advanced, or 5G NR using a single shared radio. The shared radio may be coupled to a single antenna or (for example, for MIMO) to perform wireless communication. Generally, the radio may include any combination of a baseband processor, analog RF signal processing circuits (including, for example, filters, mixers, oscillators, amplifiers, etc.), or digital processing circuits (for, for example, digital modulation and other digital processing). Similarly, the radio may implement one or more receive and transmit chains using the above hardware. For example, UE106 may share one or more parts of the receive and / or transmit chains among multiple wireless communication technologies such as the above technologies.

[0049] In some embodiments, UE106 may include separate transmit and / or receive chains (including, for example, separate antennas and other radio components) for each of the radio communication protocols to which UE106 is configured to communicate. Further possibilities include UE106 including one or more radios shared among multiple radio communication protocols and one or more radios used by only one radio communication protocol. For example, UE106 may include a shared radio for communication using either LTE or 5G NR (or LTE, or 1xRTT, or LTE, or GSM) and separate radios for communication using Wi-Fi and Bluetooth, respectively. Other configurations are also possible. Figure 3 - Block diagram of an exemplary UE device

[0050] Figure 3 shows a block diagram of an exemplary UE106 according to several embodiments. As shown, the UE106 may include a system-on-chip (SOC) 300 which may include parts for various purposes. For example, as shown in the figure, the SOC 300 may include one or more processors 302 that can execute program instructions for the UE106, and a display circuit 304 that can perform graphics processing and supply display signals to a display 360. The SOC 300 may also include a motion sensing circuit 370 that can detect the movement of the UE106 using, for example, a gyroscope, an accelerometer, and / or various other motion sensing components. The processor(s) 302 may also be coupled to a memory management unit (MMU) 340, which can be configured to receive addresses from the processor(s) 302 and translate those addresses to locations in memory (e.g., memory 306, read-only memory (ROM) 350, flash memory 310), and / or to other circuits or devices such as a display circuit 304, a radio 330, a connector I / F 320, and / or a display 360. The MMU 340 may be configured to perform memory protection and page table translation or setup. In some embodiments, the MMU 340 may be included as part of the processor(s) 302.

[0051] As shown in the figure, the SOC 300 may be coupled to various other circuits of the UE 106. For example, the UE 106 may include various types of memory (including, for example, NAND flash 310), a connector interface 320 (for coupling to, for example, a computer system, dock, charging station, etc.), a display 360, and a wireless communication circuit 330 (for, for example, LTE, LTE-A, NR, CDMA2000, Bluetooth®, Wi-Fi, GPS, etc.). The UE device 106 may include at least one antenna (e.g., 335a) and optionally multiple antennas (e.g., illustrated by antennas 335a and 335b) for performing wireless communication with base stations and / or other devices. Antennas 335a and 335b are shown as examples, and the UE device 106 may include fewer or more antennas. In general, one or more of these antennas are collectively referred to as antenna 335. For example, the UE device 106 may use antenna 335 and wireless circuit 330 to perform wireless communication. As described above, in some embodiments, the UE may be configured to communicate wirelessly using multiple wireless communication standards.

[0052] UE106 may include hardware and software components for implementing a method by which UE106 performs the simultaneous generation of multiple codebooks for CSI reporting, such as as will be further described later in this specification. The processor(s) 302 of the UE device 106 may be configured to perform some or all of the methods or operations described herein by executing program instructions stored in a memory medium (e.g., a non-temporary computer-readable memory medium), for example. In other embodiments, the processor(s) 302 may be configured as a programmable hardware element such as a field-programmable gate array (FPGA) or as an application-specific integrated circuit (ASIC). Furthermore, the processor(s) 302 may be coupled to and / or interoperable with other components, as shown in Figure 3, in order to perform the various embodiments described herein. The processor(s) 302 may also implement various other applications and / or end-user applications that run on UE106.

[0053] In some embodiments, the radio 330 may include separate controllers dedicated to communication control for various respective RAT standards. For example, as shown in Figure 3, the radio 330 may include a Wi-Fi controller 352, a cellular controller (e.g., an LTE and / or LTE-A controller) 354, and a Bluetooth® controller 356, and in at least some embodiments, one or more or all of these controllers may be implemented as separate integrated circuits (abbreviated as ICs or chips) that communicate with each other and with the SOC 300 (more specifically with the processor(s) 302). For example, the Wi-Fi controller 352 may communicate with the cellular controller 354 via a cell-ISM link or WCI interface, and / or the Bluetooth® controller 356 may communicate with the cellular controller 354 via a cell-ISM link, etc. Although three separate controllers are shown within the radio 330, other embodiments may have fewer or more similar controllers for various different RATs that can be implemented in the UE device 106. Figure 4 - Exemplary base station block diagram

[0054] Figure 4 shows a block diagram of an exemplary base station 102 according to several embodiments. Note that the base station in Figure 4 is only one example of a possible base station. As shown in the figure, the base station 102 may include one or more processors 404 capable of executing program instructions for the base station 102. The processors 404 may also be coupled to a memory management unit (MMU) 440 which may be configured to receive addresses from the processors 404 and translate those addresses to locations in memory (e.g., memory 460 and read-only memory (ROM) 450) or to locations in other circuits or devices.

[0055] The base station 102 may include at least one network port 470. The network port 470 may be configured to connect to a telephone network and provide access to the telephone network to multiple devices, such as UE devices 106, as described in Figures 1 and 2 above. The network port 470 (or additional network ports) may also, or alternatively, be configured to connect to a cellular network, such as the core network of a cellular service provider. The core network can provide mobility-related services and / or other services to multiple devices, such as UE devices 106. In some cases, the network port 470 may connect to the telephone network via the core network, and / or the core network may provide a telephone network (for example, between other UE devices serviced by a cellular service provider).

[0056] The base station 102 may include at least one antenna 434, and possibly more antennas. The antenna(s) 434 may be configured to operate as a radio transceiver and may be further configured by the radio 430 to communicate with the UE device 106. The antenna(s) 434 communicate with the radio 430 via a communication chain 432. The communication chain 432 may be a receive chain, a transmit chain, or both. The radio 430 may be designed to communicate via a variety of radio telecommunications standards, including but not limited to NR, LTE, LTE-A, WCDMA, CDMA2000, etc. The processor 404 of the base station 102 may be configured to implement and / or support some or all of the methods described herein by, for example, executing program instructions stored in a memory medium (e.g., a non-temporary computer-readable memory medium). Alternatively, the processor 404 may be configured as a programmable hardware element such as a field-programmable gate array (FPGA), as an application-specific integrated circuit (ASIC), or a combination thereof. In the case of a given RAT, for example Wi-Fi, the base station 102 may be designed as an access point (AP), in which case the network port 470 may be implemented to provide access to a wide area network and / or local area network(s), and may include, for example, at least one Ethernet port, and the radio 430 may be designed to communicate in accordance with the Wi-Fi standard. Multi-access edge computing

[0057] Modern cellular phones are required to run increasingly complex applications. Generally, users prefer using smartphones (UEs) due to their portability, size, and ease of use. However, being portable or mobile devices, UEs such as smartphones are battery-powered and smaller in size than non-portable devices such as desktop computers. Consequently, UE devices have various hardware limitations, including battery life, power, processing power, and memory capacity. Efforts have been made to offload the computing requirements of UEs to other computing resources in order to reduce the load on applications running on UE devices and to provide more efficient use of UE resources. As mentioned above, the term "mobile cloud computing" (MCC) refers to the use of cloud servers to perform computing tasks that could otherwise be performed by UEs. However, as mentioned above, the use of cloud servers located physically remote from the UEs they attempt to assist (the UEs to which they attempt to offload tasks) can introduce communication delays that make such cloud servers unsuitable for real-time applications.

[0058] Multi-access edge computing (MEC) provides information technology (IT) service environments and cloud computing capabilities at the edge of the mobile network, within the radio access network (RAN) and physically close to mobile subscribers. In other words, MEC works to localize mobile cloud computing (MCC) services to be physically closer to mobile users or to cellular base stations serving UEs (closer to the network "edge") in order to reduce communication latency. Thus, specific user requests can be managed directly at the network edge instead of forwarding all traffic to remote internet services at a greater distance. MEC promises significant reductions in latency and mobile energy consumption while providing reliable and advanced services.

[0059] In the MEC system described herein, processing tasks from the UE can be offloaded to a nearby MEC host via a cellular network. The MEC host can perform data collection, processing, and broadcasting of computationally intensive tasks, and thus can cover a wide range of use cases and applications. The MEC host can then return the resulting data from the processing tasks to the application running on the UE.

[0060] The two main phases of MEC operation are sometimes called the control phase (control plane) and the operation phase (data plane). The control phase (control plane) can include auxiliary procedures for starting, connecting, maintaining, and terminating MEC operations. The control plane determines what, when, where, and how to correctly offload tasks to the MEC servers. The operation phase (data plane) handles the routing of data to and from the edge cloud.

[0061] The control phase poses a significant challenge in designing MEC-based systems because it requires reliable signaling between users, the network, and MEC hosts. Due to the dynamic nature of cellular networks, signaling can leverage and integrate aspects from both wireless communication and mobile computing.

[0062] As described above, UEs have limited computing power and may incur additional latency during task offloading. Consequently, as described herein, UEs can leverage efficient resource allocation for local computing and careful, dynamic selection of tasks to be offloaded via wireless transmission when the application being executed is latency-sensitive or mission-critical.

[0063] The embodiments described herein provide a service discovery and offload framework for MEC-based cellular (e.g., 3GPP) systems. The service discovery and offload framework can also take into account radio channel characteristics and UE capabilities, along with processing task requirements. The embodiments are described herein in the context of cellular systems (e.g., 3GPP-based systems). However, the embodiments described herein can be readily extended to non-cellular (non-3GPP-based) systems.

[0064] The currently proposed standard (3GPP TS 23.758) identifies key issues and corresponding application architectures for edge computing and discusses several potential high-level architectural frameworks. However, specific details and implementability are still unclear. 3GPP defines User Route Selection Policies (URSP) in 3GPP TS 23.503, which are provided by the network or pre-configured in the UE. However, the URSP procedure lacks flexibility. Furthermore, these policies do not consider any UE-related factors such as computing power, energy levels, or radio channel characteristics (interference, channel fading, Doppler, etc.). These UE-related factors can have a significant impact on normal offloading and system reliability. Also, the assumption of static pre-configured MEC offloading limits the system's capabilities.

[0065] Studies on latency sensitivity in internet-based game applications have shown that latency sensitivity is important to players. Therefore, latency sensitivity is important for service providers who want to optimize their servers and services in the future.

[0066] Figure 13 is a graph showing the number of kills (deaths) per minute as a function of median ping time. Here, the term "kill" refers to "death" in online games such as first-person shooter games. The term "ping time" refers to the round-trip time from when a signal or packet reaches the host computer until a response from the host returns to the sender. Figure 13 shows that players with a median ping of 45 milliseconds had, on average, one more kill (death) per minute than players with a median ping of 200 milliseconds. Considering games played for several tens of minutes, this represents a significant impact on the gaming experience. See, for example, G. Armitage, "An experimental estimation of latency sensitivity in multiplayer Quake 3" (The 11th IEEE International Conference on Networks, 2003. ICON2003).

[0067] A comparative experimental study of computation offloading to MCC and cloudlets was conducted by Hu et al. (W. Hu et al., "Quantifying the Impact of Edge Computing on Mobile Applications," ACM APSys'16). The authors measured latency in LTE and Wi-Fi offload scenarios for facial recognition and augmented reality applications. The results show that offloading to the network edge can provide substantial gains in terms of latency and energy consumption.

[0068] Embodiments described herein may utilize either or both service discovery and / or dynamic offloading capabilities to improve the performance of a cellular system. As described herein, dynamic offloading can take the form of channel quality-dependent offloading and / or location-dependent offloading, and can provide greater improvements than statically determined offloading. As used herein, the term “dynamic” in relation to service discovery or offloading refers to the concept that these activities are performed while the UE is running. Specifically, the term “dynamic offloading” may specify that offloading decisions are evaluated and made while the UE is operating, and possibly while an application is running that is to which tasks are to be offloaded.

[0069] Embodiments described herein may include a service discovery unit for mobile edge computing (MEC). The service discovery unit can collect information about available MEC servers, edge data networks (EDNs), and their capabilities through communication with a 5G core network and exchange of site capability parameters.

[0070] Embodiments described herein may also include an offload controller, which can be characterized as a logical unit that supports processing task offloading. The offload controller may take into account channel status, cellular network system parameters, and application requirements, as well as other information. The controller may calculate a value for a default utility function and compare this calculated value to an application-specific threshold. The controller can then determine whether the task is offloaded to the MEC server, executed locally, or dropped entirely (not executed). In some embodiments, the offload controller includes a service discovery unit and therefore performs both service discovery and offloading.

[0071] The embodiments described herein may be standardized, i.e., may become part of a cellular specification followed by most or all of the cellular industry. Alternatively, the embodiments described herein may be used as proprietary solutions by a single manufacturer, such as a UE that communicates directly with an MEC server, manufactured by Company A and owned or operated by Company A. Thus, the embodiments described herein, such as service discovery units and / or offload controllers, do not require standardization. MEC operation in Figure 5-5G

[0072] Figure 5 is a block diagram showing a typical mobile edge computing (MEC) configuration in a current 5G network. As shown in the diagram, an UE communicates wirelessly with a base station called a gNB. The base station then communicates with the cellular network, specifically the user plane function (UPF). The UPF then connects to the Local Area Data Network (LADN). During operation, traffic from each UE is routed from the base station (gNB) to the UPF (user plane function). The UPF is located near and / or within the Local Area Data Network (LADN). The LADN hosts MEC servers and applications, and computing tasks are performed by these MEC servers and applications within the LADN. Figure 6 - MEC with Off-Road Controller

[0073] Figure 6 is a block diagram of a portion of a cellular network implementing multi-access edge computing (MEC) according to an embodiment described herein. As shown in Figure 6, the UE communicates wirelessly with a cellular base station called a gNB. The base station then communicates with the cellular network, specifically the user plane function (UPF) of the core network. The UPF then connects to the local area data network (LADN). The LADN hosts MEC servers and applications, and computing tasks that would otherwise be performed by the UE are offloaded to or can be performed by these MEC servers and applications within the LADN.

[0074] Figure 6 is somewhat similar to the block diagram of Figure 5, but includes a very important addition: an Offloading Controller Unit (OCU). More specifically, embodiments described herein can operate to provide improved Multi-Access Edge Computing (MEC) operation by utilizing an offload decision logic unit, referred to herein as the Offloading Controller Unit (OCU). The OCU can operate to facilitate and manage the dynamic offloading of tasks in an MEC-based system. More specifically, the presence of the OCU allows tasks that would normally need to be performed by the UE to be intelligently offloaded by computer servers that are part of the MEC infrastructure.

[0075] In some embodiments, the offload controller unit (OCU) may consist of four parts, as shown in the figure: an Application Profile Unit (APU), a System Profile Unit (SPU), a Service Discovery Unit (SDU), and a Decision and Scheduling Unit (DSU).

[0076] The offload controller unit can be located within the UE (implemented within the UE), or it can be implemented in another device such as a base station (gNB), or at a service provider (SP) site. In some embodiments, a portion of the offload controller unit can be distributed across multiple devices. For example, in some embodiments, the service discovery unit can be implemented in a network element within the core network, or on a server outside the core network, while some or all of the APU, SPU, and DSU can be implemented in the UE (and / or base station). Various other implementation configurations are also conceivable.

[0077] In embodiments where the offload controller is implemented in a base station, the OCU can operate to serve multiple UEs located within a geographical area. In addition, in embodiments where the offload controller is implemented in a base station, UEs can provide application requirements to the base station via dedicated signaling. Users of the UEs can control the disclosure of UE application data to the base station.

[0078] As shown in the diagram, the Service Discovery Unit (SDU) can communicate with Application Functions (AFs), which then communicate with the core network, for example, the 5G core network (5GC). The core network may include Policy Control Functions (PCFs) and Network Exposure Functions (NEFs). The core network block can then communicate with the PCFs. The Service Discovery Unit (SDU) can operate to obtain information about available MEC servers, edge data networks (EDNs), and their capabilities. The SDU can also establish basic connectivity with the EDN. The Service Discovery Unit can provide information about available edge computing resources to the Application Profile Unit and the System Profile Unit.

[0079] The Application Profile Unit (APU) can analyze application parameters and requirements and communicate them to the DSU.

[0080] The System Profile Unit (SPU) can operate to analyze system parameters, including the capabilities of the network, RAN, UE, and MEC.

[0081] The Decision and Scheduling Unit (DSU) can analyze information from the APU and SPU to determine which offloads will be performed. The DSU can then schedule or assign tasks(s) to the associated MEC servers.

[0082] An OCU can be implemented in one of several ways. More specifically, the functions of an OCU can be implemented or divided into one of several types of logical units, as needed. Furthermore, as described above, parts or units of an OCU can be distributed across two or more different devices. Figure 7 - Exemplary Block Diagram of Network Elements

[0083] Figure 7 shows an exemplary block diagram of a network element 500 according to several embodiments. According to some embodiments, the network element 500 can implement one or more logical functions / entities of a cellular core network, such as a mobility management entity (MME), a serving gateway (S-GW), an access and management function (AMF), a session management function (SMF), and an Edge Discovery Service (EDS). Note that the network element 500 in Figure 5 is just one example of a possible network element 500. As shown in the figure, the core network element 500 may include one or more processors 504 that can execute program instructions for the core network element 500. The processors 504 may also be coupled to a memory management unit (MMU) 540 which may be configured to receive addresses from the processors 504 and translate those addresses to locations in memory (e.g., memory 560 and read-only memory (ROM) 550) or other circuits or devices.

[0084] The network element 500 may include at least one network port 570. The network port 570 may be configured to connect to one or more base stations and / or other cellular network entities and / or devices. The network element 500 may communicate with base stations (e.g., eNB / gNB) and / or other network entities / devices using any of a variety of communication protocols and / or interfaces.

[0085] As will be further described later in this specification, the network element 500 may include hardware and software components for performing and / or supporting the functions described herein. The processor(s) 504 of the core network element 500 may be configured to perform or support some or all of the methods described herein by, for example, executing program instructions stored in a memory medium (e.g., a non-temporary computer-readable memory medium). Alternatively, the processor(s) 504 may be configured as a programmable hardware element such as a field-programmable gate array (FPGA), or as an application-specific integrated circuit (ASIC), or a combination thereof. For example, the network element 500 may implement the service discovery unit described herein.

[0086] The block diagram in Figure 7 may also represent a server computer (which may be located outside the cellular network) capable of performing some or all of the operations described herein, such as an SDU. Figure 8 - Service Discovery

[0087] The OCU can implement service discovery capabilities to enable a User Equipment (UE) to locate an MEC application server that can meet the UE's application requirements. Edge data network (EDN) deployments may not be available in all locations due to cost and / or operational constraints. Therefore, it is important that the User Equipment (UE) can find an MEC application server that can meet the key performance indicators (KPIs) of its required application requirements. Thus, it is desirable for the OCU to provide a service discovery framework (referred to herein as a service discovery unit) that enables the UE to discover and associate the most suitable available MEC application server.

[0088] In some embodiments, service discovery may be a requirement for dynamic offloading, or it may be performed offline (non-dynamically) before dynamic offloading. Service discovery can be repeated whenever necessary, for example, periodically or based on subscriptions to events (e.g., in the case of UE or application mobility). In some embodiments, service discovery can be performed in systems that support static offloading only. In some embodiments, service discovery can be performed dynamically during application execution.

[0089] As described above, the SDU function can be located in the UE, at the service provider (SP) site (e.g., on a computer maintained by the service provider), or on the cellular network itself (e.g., on a network element). The SDU function can also be located on the MEC server. As described above, Figure 7 shows an exemplary block diagram of a computer system that can represent either a service provider computer, a network element, or an MEC server.

[0090] Figure 8 is a flowchart (or timing diagram) illustrating the operation of the service discovery function performed by the OCU in several embodiments. The service discovery process can operate as described below.

[0091] First, in 602, the SDU can receive application information from the APU. Application information may include the type of application running on an individual UE or an application ID that identifies a specific application. Application information may also include MEC requirements associated with the application, such as MEC server requirements, to enable the server to meet the application's needs. Note that application information may be obtained by the APU from the application itself or from an application information database.

[0092] In step 604, upon receiving application information from the APU, the SDU may communicate an MEC availability request to the core network (e.g., 5GC) via the Application Function (AF) or NEF. The purpose of the MEC availability request may be to obtain information about available edge data networks (EDNs) and MEC servers, along with their MEC site capabilities.

[0093] In 606, the core network can provide the SDU with an MEC availability response. The MEC availability response may include information about the availability of MEC servers, such as location and available computing resources. For example, the MEC availability response may include information about some or all of the MEC servers or edge data networks within the UE's service area. The MEC availability response may also include additional or supplementary information, which may be called MEC site capability information. The MEC availability response may also include other non-technical parameters, such as "offload cost," or other parameters. The determination of which MEC servers are available may be based on various criteria, such as the UE's subscription to this type of service.

[0094] In some embodiments, MEC site capability information can potentially be useful in determining dynamic MEC selection. MEC site capability information may include various parameters characterizing the capabilities of the MEC servers, such as information about the computing power of the MEC servers, latency between the UE and the servers, and other desirable parameters when making offload decisions. Capability can be communicated in the form of statistical guarantees, mean guarantees, or other forms.

[0095] The core network can access various UE information to acquire and provide MEC site capability information. For example, the core network can access UE information such as UE identification information, UE location, and tracking area ID. This UE information can be acquired from other network core functions via AF / NEF.

[0096] Upon receiving MEC availability responses from the core network in 606, the SDU can filter edge data networks in 608 based on their capabilities. For example, certain edge data networks that are computationally insufficient, overburdened, or have excessively high latency can be excluded from consideration.

[0097] In version 610, the SDU can pre-select EDN and MEC servers based on their capabilities / cost and application requirements, and the SDU can communicate the available EDN / MECs and their capabilities to the SPU.

[0098] In 612, the SDU can communicate an MEC setup request to the core network. Providing an MEC setup request to the core network can trigger the establishment of a basic connection with a selected EDN, such as a URSP, PDU session, or network slice. In some embodiments, the MEC setup request can, if necessary, trigger the establishment of a connection with a pre-selected EDN.

[0099] In version 614, in response to an MEC setup request, the core network can compile a user route selection policy for EDNS. The core network can also install the application's USRP for EDN.

[0100] In 616, the core network can send a MEC setup response to the SDU. The MEC setup response can include an acknowledgment or a negation response (ACK / NACK). The MEC setup response can also include various routing information that can be used to enable communication with the EDN.

[0101] Service discovery procedures (e.g., operations 602-616) can be performed offline, for example, before running an application on the UE. These operations may be performed periodically as needed to ensure that the UE has up-to-date information about the available edge network, or they may be performed on a case-by-case basis based on specific events. Examples of events that may trigger (or repeat) service discovery procedures include notifications of changes in MEC site capacity, such as MEC load, power-on of the UE, when the UE enters a new service area or cell, changes in the UE mobility state, or other factors.

[0102] Alternatively, the operations 602-616 can be performed more dynamically, such as when an application that may require or has previously subscribed to off-road services is launched (selected for execution) on the UE.

[0103] (In some cases) applications that require or subscribe to offload services can later run on the UE. In 618, the SDU can dynamically make offload decisions based on various information, such as MEC availability response information and / or MEC setup response information. For example, the SDU can dynamically make offload decisions based at least in part on MEC site capability information, among other factors. In 620, the application to be offloaded can be routed to one or more MEC services using the installed URSP. Task offloading is described in more detail below. Dynamic task offloading

[0104] The following provides more information about the components of the OCU that perform the offloading of dynamic tasks. As mentioned above, the OCU may consist of an application profile unit, a system profile unit, and a decision and scheduling unit. The operation of the fourth component, the service discovery unit, was described above with reference to Figure 8.

[0105] The application profiling unit can store processing information about application tasks(s) that are candidates for offloading. The APU can also store information about application task partitioning and the computational cost of each task. The cost of a task may be entirely known, for example, provided by the application developer, or obtained from runtime profiling. If the exact cost is unknown, cost estimation (e.g., coarse quantization of the cost), such as low, medium, or high computational load, may suffice. This can be pre-configured or estimated during runtime. The computational cost of a task may be based on the average cost, the worst-case cost, or any other value related to the statistical distribution of computational costs. The APU can store this information during runtime by utilizing common operating system and application processor performance profiling services. In some embodiments, the application profiling unit can be implemented as a software component running on a computer (such as a UE).

[0106] The System Profile Unit can operate to process various information necessary for performing offload tasks, such as UE system information, radio channel characteristics, and power levels. The SPU can acquire this information during runtime by utilizing energy monitoring and cellular radio link status information provided by a common operating system, application processor, and respective energy management and cellular modem driver components. In some embodiments, the System Profile Unit can be implemented as a software component running on a computer (such as the UE).

[0107] The decision and scheduling unit can collect data from the application profile unit and the system profile unit to determine whether a task is offloaded to the MEC server or executed locally. The decision and scheduling unit can determine whether to offload a task based on a threshold θ defined for a particular task(s). The threshold θ may be application-dependent and may be derived at runtime based on radio conditions, data rate requirements, and computational requirements, or it may be statically defined at design time.

[0108] In some embodiments, a utility function U(l,e) can be defined for each application. The utility function can represent the relative utility (or relative benefit) of offloading a task versus executing it locally. The utility function may be a general performance measure and may potentially incorporate application characteristics (e.g., quality of experience, offload cost) and system characteristics (e.g., energy consumption). The utility function can describe how performance depends on the latency l, energy e, and offload cost c during the task execution interval t. Decision and scheduling units can apply the utility function to the local and offload calculation options to make offload decisions. Thus, the utility function can be used to refine offload decisions. In some embodiments, the utility function can be used to calculate a value to be compared against a specific threshold θs described above. An example of the form of the utility function is as follows:

number

[0109] If the calculated difference is lower than a default threshold, the task(s) are executed locally. If the calculated difference is higher than a default threshold, the task(s) are executed remotely. The utility function and thresholds can be defined so that acceptable tolerances (upper and lower limits) for delay, energy, and cost are included in the decision. In some embodiments, different thresholds, i.e., hysteresis, are applied to the decision to offload local tasks and to the decision to move offloaded tasks back to the local UE. This can operate to prevent task execution from being "ping-pong transmitted" back and forth between local and offloaded executions.

[0110] Finally, the decision and scheduling unit can schedule the tasks to be offloaded and send a request to the network to initiate the offloading process. The request may also include a message broadcasting basic task parameters to the network and the MEC server. An example of parameters included in the message is shown in Figure 9. As shown in the figure, basic task parameters may include, among other possibilities, task priority, latency requirements, periodicity, and computational complexity. The MEC server can use the received values ​​of these parameters when executing the offloaded tasks.

[0111] In some cases, the decision and scheduling unit may determine that a task(s) cannot be executed at any of those locations, for example, due to insufficient power levels at the UE or poor channel conditions with the 5G network. In this case, the task may be dropped, i.e., simply not executed. When this occurs, one or both of the network and the MEC server will determine the offload mode index I(t) at time t. mIt is possible to maintain m={u,s,d}, where u,s,d are flags that specify execution for UE, server, or drop, respectively. In some embodiments, the offload mode index for a future timeframe can be used by the network and the MEC server to plan the allocation of network and computing resources among all users. In other embodiments, the flag d can be used by the host for error handling or concealment.

[0112] In some embodiments, the decision of whether or not to offload may remain performed locally on the UE. In this case, the implementation of the offload controller is purely proprietary and does not require any changes to the standardization of the cellular network or MEC system.

[0113] In some embodiments, the decision and scheduling unit can be implemented as a software component that runs on a computer, such as a UE or application processor.

[0114] Figure 10 shows one embodiment of the task offload signaling flow in which the OCU is implemented in the UE. The flow in Figure 10 assumes, for example, that a route through the MEC server and network has already been established by a preceding service discovery process.

[0115] As shown in the figure, in 702, the UE determines whether task offloading should be performed. In some embodiments, the UE can make this determination dynamically during application execution. In 702, the task offloading decision can be performed by the decision and scheduling unit as described above. For example, the UE may be running a time-critical application, or an application that requires real-time performance, such as an interactive game, and can determine that one or more tasks required within the application should be offloaded to help ensure real-time performance. The UE can make this determination in any of several ways. For example, when making this determination, the UE may take into account one or more of its battery level, current computational requirements, and processing latency. In some embodiments, as described above, the UE can use a utility function and thresholds as described above when making this determination. The utility function may be the same for each application, or it may be specific to the particular application being run. Similarly, the threshold may be general-purpose, or it may be specific to the application. One or both of the utility function and / or thresholds can be dynamically adjusted during application execution to reflect the current state.

[0116] In 704, the UE provides an offload request to the MEC server. After successful discovery of the MEC server and establishment of a connection between the UE and the server, the UE can initiate the offload procedure. This may involve the UE sending an offload request, which may be a message containing key information about the application and its requirements. For example, this information may include information about the application type (e.g., V2X, game, health), application requirements (e.g., end-to-end latency requirements, bandwidth, memory), application priority (e.g., high, medium, low), etc. The offload request may also contain various other information. Thus, in 704, the UE sends a signaling to the base station intended for the MEC server and requesting computing resources for offloading.

[0117] Upon receiving an offload request in 704, the MEC server can retrieve task information and requirements from the offload request in 706.

[0118] In response 708, the MEC server can send an offload confirmation back to the UE. This offload confirmation message can indicate that the MEC server has accepted the offload request and will perform the task that the UE wishes to offload.

[0119] In 710, the UE can send one or more application tasks to the MEC server. Depending on privacy requirements, the UE can also send the entire application to the MEC server. A task identifier can be attached to each task. Thus, when the UE receives an offload confirmation in 708, the UE can send the data to be offloaded to the MEC server.

[0120] Once the task transfer is complete, in step 712, the UE can send a transfer completion notification to the MEC server indicating that the task transfer to the MEC server is complete.

[0121] In 714, the MEC server can execute tasks that have been offloaded to it. More specifically, the MEC server can perform task calculations and generate various results.

[0122] In version 716, the MEC server can send the calculated results to the UE for use by applications running on the UE. Discovery and offloading in 5G core networks

[0123] Support for edge computing in 5G networks is defined in TS23501, Section 5.13. The 5G core network selects a User Plane Function (UPF) close to the UE and performs traffic steering from the UPF to the local data network via the N6 interface. This can be based on the UE's subscription data, the UE's location, information from Application Functions (AFs), policies, or other relevant traffic rules.

[0124] To enable dynamic offloading in 5G networks, the Network Disclosure Function (NEF) can be enhanced with UE discovery and offload parameters used for service discovery and dynamic offloading, as shown in the table below. [Table 1]

[0125] In some embodiments, UE discovery and offload parameters may be part of a network status report from the NEF to the AF. The report may be a one-time report or a series of (repeated) requests. In other embodiments, UE discovery and offload parameters may be for message exchange between the AF and the NEF that is specific to the MEC application and can only be exchanged on request. Implementation Examples

[0126] 3GPP TR 26.928 defines cross-reality (XR) in 5G networks; that is, this part of the standard provides use cases, network architectures, media format analysis, etc. Chapter 5 of the standard includes information on different XR processing and media-centric architectures, considering XR servers and XR devices communicating over a 5G network. The proposed architectures are general and do not have any specific offload mechanisms that take into account network characteristics and XR clients. For example, section 5.2.6 defines an XR distributed computing architecture for XR applications that support XR partitioned rendering. The workload is partitioned between XR edge servers and devices, as shown in Figure 11 (3GPP TR 26.928, 5.2.6-1).

[0127] As shown in the diagram, the XR client connects to the network and participates in the XR rendering application. The XR client sends static device information (e.g., sensors, supported decoders, display configuration) to the XR edge server. Based on this information, the XR edge server configures the encoder and format.

[0128] Figure 12 shows how the proposed MEC controller can be implemented in the proposed 3GPP architecture. As shown in the figure, the offload controller can collect information about the XR tasks performed by the application unit. As shown in the figure, the application unit may include XR rendering tasks, sensor processing tasks, and XR scene generation tasks. In this particular embodiment, XR sensor data processing is a candidate for offloading. Experience quality can be used as a utility function that can be pre-calculated offline.

[0129] The application unit can transmit information about one or more of the following to the offload controller: data rate, latency requirements, and / or average power. The UE can also collect RSRP and RSSI measurements, as well as network system parameters such as bandwidth, frequency, modulation, and available transmit power. The UE can perform these measurements and collect network system parameters within the same timeframe as transmitting the information to the offload controller.

[0130] The offload controller can derive energy and latency metrics from these system parameters. Based on these energy and latency estimates for local and remote processing options, the offload controller can compare the utility function to a default threshold to make offload-related decisions.

[0131] Regarding latency, the following contributions can be considered when evaluating the latency for local processing options: 1) queuing latency at the UE (waiting time to schedule tasks for offloading), 2) transmission latency from the UE to the MEC server, 3) queuing latency at the MEC server (waiting time to execute tasks), and / or 4) computation latency at the MEC server.

[0132] Regarding energy, the contributions of cellular uplink and downlink transmission can be taken into account and compared to the energy required for local XR sensor data processing. Therefore, if the energy required for cellular uplink and downlink transmission is higher than the energy required for local XR sensor data processing, the offload controller can decide not to perform any offloading. Alternatively, if the energy required for cellular uplink and downlink transmission is by some threshold lower than the energy required for local XR sensor data processing, the offload controller can decide to perform offloading. Another alternative is that the offload controller may consider this comparison energy calculation along with other factors when making an offloading decision. New information elements

[0133] To support dynamic offloading, the embodiments of the systems described herein may include the following new common information elements. These new information elements (IEs) are shown in bold below. It is proposed that these new IEs be added to 3GPP TS 23.558, Chapter 8, as shown in the table below.

[0134] [Table 2]

[0135] [Table 3]

[0136] [Table 4] Method for determining MEC requirements

[0137] In the discovery process described in Figure 8, the APU obtains the MEC requirements before it can inform the SDU about them. The MEC requirements may include information such as values ​​for computing power, memory, and storage. In some embodiments, these values ​​may be "hardcoded" into the application client installed on the UE. However, such a solution is not flexible. For example, if a new version of the application server software is deployed to the network side, this may result in a different set of requirements, such as higher computing power or lower storage requirements.

[0138] Figure 14 shows one exemplary method that enables a UE to discover or retrieve MEC requirements. In some embodiments, the UE can discover MEC requirements by retrieving them from a server in the network. When a software package with a server application is deployed on the network side, the MEC requirements (e.g., computing power, memory, storage, etc.) can be provided to a server on the network ("configuration server") as shown in 802. This may be a server in the cloud or an edge server. Furthermore, the server that stores the MEC requirements may be the server on which the server application itself is running, or it may be a different server. The address of the configuration server can be provided to the UE in the form of a fully qualified domain name (FQDN), e.g., "Config.AppX.Serv1", stored in the client application on the UE.

[0139] Subsequently, once the client application is started on the UE, in 804, the UE may send a registration or configuration request message to the network, using the configuration server's FQDN as the destination address. The network resolves the FQDN to the configuration server's IP address via a DNS query. Then, in 806, the configuration server responds with a registration or configuration confirmation message containing parameters describing the MEC requirements. The UE may send this request, for example, each time the application is started, or at regular intervals, or upon receiving a trigger message from the server running the server application software.

[0140] It is well understood that the use of personally identifiable information should be governed by privacy policies and practices that are generally recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and handled in a manner that minimizes the risk of unintended or unauthorized access or use, and the nature of authorized use should be clearly indicated to the user.

[0141] Embodiments of the present invention may be implemented in any of the following forms. For example, in some embodiments, the present invention may be implemented as a method executed by a computer, a computer-readable memory medium, or a computer system. In other embodiments, the present invention can be implemented using one or more custom-designed hardware devices, such as ASICs. In other embodiments, the present invention can be implemented using one or more programmable hardware elements, such as FPGAs.

[0142] In some embodiments, a non-temporary computer-readable memory medium (e.g., a non-temporary memory element) stores program instructions and / or data, and the program instructions may be configured to cause a computer system, when executed by that computer system, to execute a method, for example, an embodiment of the method herein, a combination of embodiments of the method herein, a subset of embodiments of the method herein, or a combination of such subsets.

[0143] In some embodiments, the device (e.g., UE) may be configured to include a processor (or a set of processors) and a memory medium (or memory elements), the memory medium storing program instructions, and the processor being configured to read and execute program instructions from the memory medium, the program instructions being executable to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset of any of the method embodiments described herein, or any combination of such subsets). The device may be implemented in various forms.

[0144] Although the embodiments described above are described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art if the above disclosure is fully understood. The following claims are intended to be construed as encompassing all such variations and modifications.

Claims

1. At least one antenna, A radio operably coupled to at least one antenna for communicating with a cellular network, Memory for storing applications, A processor operably coupled to the aforementioned wireless device, User equipment (UE) equipped with, Obtain information on two or more of the following: channel status, cellular network parameters, UE power status, or application requirements. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. In response to the UE's determination that the task of the application should be offloaded to the edge server, the UE transmits the task of the application for offloaded execution on the edge server. It is structured in such a way. UE.

2. The UE according to claim 1, wherein when determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the UE is configured to compare the quality of the experience of offloaded task execution with the quality of the experience of local task execution.

3. The memory of the aforementioned UE stores information regarding the computational cost of each of the multiple tasks within the application. When dynamically determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the UE is configured to access the information regarding computation costs. The UE according to claim 1.

4. The determination is based on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The UE according to claim 1.

5. The determination is based on the channel status, cellular network parameters, UE power status, and application requirements. The UE according to claim 1.

6. The determination is at least in part based on the maximum response time associated with offloading the task to the edge server. The UE according to claim 1.

7. When determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the UE is configured to calculate a utility function. The utility function is based on one or more of the maximum response times or energy consumption associated with offloading the task, and one or more of the maximum response times or energy consumption associated with running the task locally on the UE. The UE according to claim 1.

8. The utility function is based on the maximum application response time and energy consumption associated with offloading the task, the maximum application response time and energy consumption associated with running the task locally on the UE, and the offload cost during the task execution interval. The UE according to claim 7.

9. The aforementioned UE, Based on at least a portion of the aforementioned information, calculate the value of the utility function. The value of the utility function is compared with a threshold. It is further structured in the following way: The comparison indicates whether the task of the application should be offloaded to the edge server or executed locally on the UE. The UE according to claim 7.

10. The UE is further configured to use a first threshold when determining whether to offload a task, and a second different threshold when determining whether to return the offloaded task to the UE for local execution. The UE as described in claim 9.

11. The utility function is a predetermined function associated with the application. The UE according to claim 7.

12. When sending the task of the application for offloaded execution on the edge server, the UE is configured to send a message containing task parameters to one or more of the edge servers or the cellular network, wherein the task parameters include two or more of the following: task priority, maximum response time requirement, periodicity, or computational complexity. The UE according to claim 1.

13. In response to a determination that the task of the application should be executed locally on the UE, the UE executes the task of the application locally on the UE. It is further structured in such a way. The UE according to claim 1.

14. The aforementioned UE, The system is further configured to determine that the task cannot be performed on the edge server or locally on the UE due to one or more of the following: a bad channel condition or an insufficient power level on the UE. If the UE determines that the task cannot be executed on the edge server or locally on the UE, it will not send the task of the application for offloaded execution on the edge server and will not execute the task locally on the UE. The UE according to claim 1.

15. In response to determining that the task cannot be executed locally on the cloud server or on the UE, the UE is configured to generate information used to allocate network resources and computing resources for the execution of the task at a future time. The UE according to claim 14.

16. The UE is further configured to discover available edge server resources in its vicinity before dynamically determining whether the tasks of the application running on the UE should be offloaded to an edge server. The UE according to claim 1.

17. When discovering available edge server resources in the vicinity of the UE, the UE is configured to request edge server site capability information, which includes information regarding the computing power of one or more edge servers, the site load of one or more edge servers, and the maximum response time between the UE and one or more edge servers. The UE according to claim 16.

18. The aforementioned UE, An edge computing availability request is sent to the cellular network, including information identifying the UE and information identifying the application running on the UE. In response to the aforementioned edge computing availability request, the cellular network receives an edge computing availability response, which includes information about available edge server networks and site capability information. It is further structured in such a way. The UE according to claim 17.

19. The UE determines, based on the information regarding the available edge server network and site capability information, one or more edge servers on which the task of the application should be offloaded. It is further structured in such a way. The UE according to claim 18.

20. A non-temporary computer-readable medium included in user equipment (UE), Obtain information on two or more of the following: channel status, cellular network parameters, UE power status, or application requirements. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. In response to a determination that the task of the application should be offloaded to the edge server, the sender of the task of the application for offloaded execution on the edge server is triggered. It stores executable program instructions in such a way. Non-temporary computer-readable media.

21. When determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the program instructions are executable in such a way as to compare the quality of the experience of offloaded task execution with the quality of the experience of local task execution. The non-temporary computer-readable medium according to claim 20.

22. The aforementioned medium stores information regarding the computational cost of each of the multiple tasks within the application. When dynamically determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the program instructions are executable to access the information relating to the computation cost. The non-temporary computer-readable medium according to claim 20.

23. The determination is based on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The non-temporary computer-readable medium according to claim 20.

24. The determination is at least in part based on the maximum response time associated with offloading the task to the edge server. The non-temporary computer-readable medium according to claim 20.

25. When determining whether the tasks of the application executed on the UE should be offloaded to the edge server or executed locally on the UE, the program instructions are executable to compute a utility function. The utility function is based on one or more of the maximum response times or energy consumption associated with offloading the task, and one or more of the maximum response times or energy consumption associated with running the task locally on the UE. The non-temporary computer-readable medium according to claim 20.

26. The utility function is based on the maximum application response time and energy consumption associated with offloading the task, the maximum application response time and energy consumption associated with running the task locally on the UE, and the offload cost during the task execution interval. The non-temporary computer-readable medium according to claim 25.

27. The aforementioned program instruction, Based on at least a portion of the aforementioned information, calculate the value of the utility function. The value of the utility function is compared with a threshold. It is even more feasible, The comparison indicates whether the task of the application should be offloaded to the edge server or executed locally on the UE. The non-temporary computer-readable medium according to claim 25.

28. The form of the utility function is based on one or more of the tasks or applications, The non-temporary computer-readable medium according to claim 27.

29. The threshold is based on one or more of the tasks or applications. The non-temporary computer-readable medium according to claim 27.

30. Multiple antennas, A radio unit operably coupled to the aforementioned multiple antennas, A processor operably coupled to the aforementioned wireless device, A cellular base station equipped with, It receives information about two or more of the following: channel status, cellular network parameters, or application requirements for an application running on the UE. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. In response to the cellular base station's determination that the task of the application should be offloaded to the edge server, the cellular base station transmits the task of the application for offloaded execution on the edge server. It is structured in such a way. Cellular base station.

31. When determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the base station is configured to compare the quality of the experience of offloaded task execution with the quality of the experience of local task execution. A cellular base station according to claim 30.

32. The determination is based on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. A cellular base station according to claim 30.

33. The determination is based on the channel status, cellular network parameters, UE power status, and application requirements. A cellular base station according to claim 30.

34. The determination is at least in part based on the maximum response time associated with offloading the task to the edge server. A cellular base station according to claim 30.

35. The cellular base station, Based on the information regarding available edge servers and site capability information, one or more edge servers on which the user equipment's (UE) application tasks should be offloaded are determined. The UE transmits information about one or more edge servers on which the tasks of the application should be offloaded. It is further structured in such a way. A cellular base station according to claim 30.

36. The information relating to one or more edge servers on which the tasks of the application should be offloaded is operable to be filtered by the UE in order to select an edge server on which the tasks of the application should be offloaded. A cellular base station according to claim 35.

37. Non-temporary computer-readable memory medium and A processor coupled to the memory medium, A server equipped with, Edge computing availability information, including information about available edge servers and site capability information, is obtained from the cellular network. Based on the information regarding available edge servers and site capability information, determine one or more edge servers on which the UE's application tasks should be offloaded. The UE transmits information about one or more edge servers on which the tasks of the application should be offloaded. It is structured in such a way. server.

38. The aforementioned server, One or more available edge servers are further configured to receive requests from the UE to offload the application tasks, The server acquires the edge computing availability information in response to the request. The server according to claim 37.

39. The server is further configured to determine one or more edge servers based on the application requirements of the UE. The server according to claim 37.

40. The server is further configured to determine one or more edge servers on which the UE's application tasks should be offloaded, at least in part, based on the maximum response time when processing requests from the UE. The server according to claim 37.

41. The information relating to one or more edge servers on which the tasks of the application should be offloaded is operable to be filtered by the UE in order to select an edge server on which the tasks of the application should be offloaded. The server according to claim 37.

42. The information relating to one or more edge servers includes information relating to a plurality of possible edge servers, wherein at least one of the plurality of possible edge servers is selectable by the UE for task offloading. The server according to claim 37.

43. The server is further configured to determine, at least in part, the one or more edge servers on which the UE application task should be offloaded, based on the UE application requirements. The server according to claim 37.

44. The server is further configured to determine one or more edge servers on which the UE's application task should be offloaded, based at least partially on two or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The server according to claim 37.

45. The server is further configured to determine one or more edge servers on which the UE's application task should be offloaded, based at least partially on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The server according to claim 37.

46. The server is further configured to determine one or more edge servers on which the UE's application tasks should be offloaded, at least in part, based on channel status, cellular network parameters, UE power status, and application requirements. The server according to claim 37.

47. Non-temporary computer-readable media, Obtain information on two or more of the following: channel status, cellular network parameters, UE power status, or application requirements. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. In response to a determination that the task of the application should be offloaded to the edge server, the sender of the task of the application for offloaded execution on the edge server is triggered. It stores executable program instructions in such a way. Non-temporary computer-readable media.

48. The non-temporary computer-readable medium according to claim 47, wherein the non-temporary computer-readable medium is included in a network element.

49. The non-temporary computer-readable medium according to claim 47, wherein the non-temporary computer-readable medium is included in the server of the cellular network.

50. The aforementioned program instruction, One or more available edge servers can be further configured to receive requests from the UE to offload the application tasks. The server transmits the edge computing availability request in response to the request. The non-temporary computer-readable medium according to claim 47.

51. The program instructions are further executable to determine one or more edge servers based on the application requirements of the UE. The non-temporary computer-readable medium according to claim 47.

52. The program instruction can further be executed to determine one or more edge servers on which an application task of the UE should be offloaded, at least in part, based on the maximum response time when processing a request from the UE. The non-temporary computer-readable medium according to claim 47.

53. The information relating to one or more edge servers on which the tasks of the application should be offloaded is operable to be filtered by the UE in order to select an edge server on which the tasks of the application should be offloaded. The non-temporary computer-readable medium according to claim 47.

54. The information relating to one or more edge servers includes information relating to a plurality of possible edge servers, wherein at least one of the plurality of possible edge servers is selectable by the UE for task offloading. The non-temporary computer-readable medium according to claim 47.

55. The program instruction is further executable to determine one or more edge servers on which a UE application task should be offloaded, at least in part, based on UE application requirements. The non-temporary computer-readable medium according to claim 47.

56. The program instruction can be further executed to determine one or more edge servers on which an application task of the UE should be offloaded, based at least partially on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The non-temporary computer-readable medium according to claim 47.

57. The program instruction can be further executed to determine one or more edge servers on which the UE's application task should be offloaded, based at least in part on the channel state, cellular network parameters, UE power state, and application requirements. The non-temporary computer-readable medium according to claim 47.

58. At least one antenna, A radio operably coupled to at least one of the aforementioned antennas, A processor operably coupled to the aforementioned wireless device, A wireless device equipped with, It receives information about two or more of the following: channel status, cellular network parameters, or application requirements for an application running on the UE. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. It is structured in such a way. Wireless device.

59. When determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the wireless device is configured to compare the quality of the experience of offloaded task execution with the quality of the experience of local task execution. The wireless device according to claim 58.

60. The determination is based on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The wireless device according to claim 58.

61. The determination is based on the channel status, cellular network parameters, UE power status, and application requirements. The wireless device according to claim 58.

62. The determination is at least in part based on the maximum response time associated with offloading the task to the edge server. The wireless device according to claim 58.

63. The aforementioned wireless device Based on the aforementioned information regarding available edge servers and site capability information, the system is further configured to determine one or more edge servers on which the application tasks of a user device (UE) should be offloaded. The wireless device according to claim 58.

64. A processor, for wireless devices, It receives information about two or more of the following: channel status, cellular network parameters, or application requirements. Based on the aforementioned information, it is dynamically determined whether the tasks of the application executed on the UE should be offloaded to an edge server or executed locally on the UE. In response to the UE's determination that the task of the application should be offloaded to the edge server, the UE causes the task of the application to be sent for offloaded execution on the edge server. A processor configured in such a way, A device equipped with the following features.

65. When determining whether the tasks of the application running on the UE should be offloaded to the edge server or run locally on the UE, the device is configured to compare the quality of the experience of offloaded task execution with the quality of the experience of local task execution. The apparatus according to claim 64.

66. The determination is based on three or more of the following: channel status, cellular network parameters, UE power status, or application requirements. The apparatus according to claim 64.

67. The determination is based on the channel status, cellular network parameters, UE power status, and application requirements. The apparatus according to claim 64.

68. The determination is at least in part based on the maximum response time associated with offloading the task to the edge server. The apparatus according to claim 64.

69. The device determines, based on the information regarding available edge servers and site capability information, one or more edge servers on which the task of the application should be offloaded. It is further structured in such a way. The apparatus according to claim 64.

70. At least one antenna, A radio operably coupled to at least one antenna for communicating with a cellular network, Memory for storing applications, A processor operably coupled to the aforementioned wireless device, User equipment (UE) equipped with, An edge computing availability request is sent to the cellular network, including information identifying the UE and information identifying the application running on the UE. In response to the aforementioned edge computing availability request, the cellular network receives an edge computing availability response, which includes information about available edge server networks and site capability information. It is configured in such a way, The site capability information includes the computing power of one or more edge servers, the site load of one or more edge servers, and information regarding the maximum response time between the UE and one or more edge servers. UE.

71. The UE determines, based on the information regarding the available edge server network and site capability information, one or more edge servers on which the task of the application should be offloaded. It is further structured in such a way. The UE according to claim 70.

72. A non-temporary computer-readable medium, wherein the non-volatile computer-readable medium is Send an edge computing availability request that includes information requesting the availability of edge computing resources within a specified geographical area. In response to the aforementioned edge computing availability request, the system receives an edge computing availability response that includes information about the available edge server network and site capability information. It stores executable program instructions in such a way, The site capability information includes the computing power of one or more edge servers, the site load of one or more edge servers, and information regarding the maximum response time between the UE and one or more edge servers. Non-temporary computer-readable media.

73. The program instruction determines one or more edge servers on which the task of the application should be offloaded, based on the information regarding the available edge server network and site capability information. It is even more feasible to do so. The non-temporary computer-readable medium according to claim 72.

74. The aforementioned medium is included in one of the following: base station, network element, or edge server. The non-temporary computer-readable medium according to claim 72.

75. The program instruction transmits to the UE the information relating to the computing power of one or more edge servers, the site load of one or more edge servers, or the maximum response time between the UE and one or more edge servers. It is even more feasible to do so. The non-temporary computer-readable medium according to claim 72.

Images