Method and apparatus for supporting application mobility in a multi-access edge computing platform architecture

Abstract

A method implemented by a multi-access edge computing (MEC) distributed controller includes: receiving an MEC computing task request, the MEC computing task request being used to request a computing node that supports executing a service on an MEC node controlled by the MEC distributed controller; obtaining geographic location information associated with a mobile device; determining an execution plan and an MEC node pool, the execution plan and the MEC node pool being used for executing the service, the determination being made based on the geographic location information associated with the mobile device; scheduling the execution plan on the MEC node pool; and deploying the scheduled execution plan.

Description

Technical Field

[0001] The present invention relates generally to methods and apparatus for digital computing, fifth generation (5G) telecommunications, autonomous driving, and in particular embodiments, to methods and apparatus for supporting application mobility in a multi-access edge computing (MEC) platform architecture. Background Art

[0002] Traditional cloud computing models can be used for certain mobile services that do not impose location or timing constraints and do not consider quality of service (QoS). With the increasing popularity of mobile computing, the timing and QoS constraints of mobile applications pose unique challenges. Specifically, mobile vehicles can request services that may exceed the capabilities of current cloud-based solutions, which can lead to failures to meet some application requirements (e.g., latency, QoS, etc.). Consequently, providing services for mobile applications becomes a greater challenge.

[0003] Multi-access edge computing (MEC) generally provides a new computing model that expands the capabilities of the computing resources typically available in mobile devices, allowing resource-limited mobile devices to not only offload the execution of computationally intensive tasks to MEC nodes (e.g., benefiting energy conservation), but also enable new services for the growing demands of mobile users.

[0004] Mobile devices can simply initiate requests or tasks to the MEC, provide interaction between the user and the task or request, and provide the results of the completed task to the user (where the user can be a human or another device). Offloading computationally intensive tasks to MEC nodes enables the execution of tasks that are typically impossible on mobile devices. In addition, by eliminating the need to provide large amounts of computational power, the ability to offload tasks allows for the design of smaller, low-power, and battery-efficient mobile devices.

[0005] However, when a mobile device moves, it may be necessary to migrate services associated with the mobile device from one MEC node to another MEC node to provide the best service to the mobile device. For example, a mobile device may be served by a first MEC node. However, when the mobile device is away from the first MEC node, the second MEC node can better provide services to the mobile device. If a task executed on the first MEC node is not completed, it may be necessary to migrate the task to the second MEC node. Task migration may result in significant delays and huge costs, which will have a negative impact on the overall user experience. Therefore, there is a need for methods and devices for supporting service mobility in a multi-access edge computing platform architecture. Summary of the Invention

[0006] According to a first aspect, a method implemented by a multi-access edge computing (MEC) distributed controller is provided. The method includes: receiving, by the MEC distributed controller, a MEC computing task request from a mobile device, the MEC computing task request being used to request a computing node that supports execution of a service on an MEC node controlled by the MEC distributed controller; obtaining, by the MEC distributed controller, geographic location information associated with the mobile device; determining, by the MEC distributed controller, an execution plan and an MEC node pool for executing the service, the execution plan and the MEC node pool being determined based on the geographic location information associated with the mobile device; scheduling, by the MEC distributed controller, the execution plan on the MEC node pool; and deploying, by the MEC distributed controller, the scheduled execution plan.

[0007] According to the first aspect, in a first implementation of the method, an execution plan and a MEC node pool are associated with the execution of a service for a time window or a specified number of MEC nodes.

[0008] According to the first aspect or any one of the above-mentioned implementations of the first aspect, in the second implementation of the method, determining the execution plan includes: the MEC distributed controller dividing the execution of the service into multiple tasks, each task being executable on an MEC node; and the MEC distributed controller selecting a subset of the MEC node pool for each of the multiple tasks based on a selection function.

[0009] According to the first aspect or any one of the above implementations of the first aspect, in a third implementation of the method, the MEC node pool is determined based on one of a user account level of the mobile device or an account level of an owner of an application associated with the service.

[0010] According to the first aspect or any one of the above implementations of the first aspect, in a fourth implementation of the method, selecting a subset of the MEC node pool includes: generating, by the MEC distributed controller, a cost and value of executing each of multiple tasks on the MEC node for each MEC node in the MEC node pool; and selecting, by the MEC distributed controller, a MEC node for executing the task from the MEC node pool for each of the multiple tasks, the selection being performed based on the cost and value of executing the task on the MEC node, thereby generating a subset of the MEC node pool.

[0011] According to the first aspect or any one of the above implementations of the first aspect, in a fifth implementation of the method, the scheduling execution plan includes: the MEC distributed controller assigning a release time and a deadline to a subset of the selected MEC node pool.

[0012] According to the first aspect or any one of the above implementations of the first aspect, in a sixth implementation of the method, deploying the scheduled execution plan includes: the MEC distributed controller provides application data associated with the execution of the service to a subset of the selected MEC node pool, and the provision is performed based on a release time and a deadline.

[0013] According to the first aspect or any one of the above implementations of the first aspect, in a seventh implementation of the method, the release time includes required start times of the plurality of tasks, and the deadline time includes required end times of the plurality of tasks.

[0014] According to the first aspect or any one of the above implementations of the first aspect, in an eighth implementation of the method, the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or multiple MEC nodes expected to be covered by the execution plan; and the geographic location information includes at least the route of the mobile device.

[0015] According to the first aspect or any one of the above-mentioned implementations of the first aspect, in a ninth implementation of the method, the method further includes: updating, by the MEC distributed controller, the geographic location information of the mobile device based on at least one of traffic information or emergency information; determining, by the MEC distributed controller, an updated execution plan and an updated MEC node pool based on the updated geographic location information; scheduling, by the MEC distributed controller, the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; and deploying, by the MEC distributed controller, the updated scheduling execution plan.

[0016] According to a second aspect, a MEC distributed controller is provided. The MEC distributed controller includes: one or more MEC nodes for executing a job; a receiver configured to receive an MEC computing task request from a mobile device, the MEC computing task request being used to request a computing node that supports executing a service on the MEC node controlled by the MEC distributed controller; an orchestrator operably coupled to the receiver and the one or more MEC nodes, the orchestrator being configured to: obtain geographic location information associated with the mobile device; determine an execution plan and an MEC node pool for executing the service, the execution plan and the MEC node pool being determined based on the geographic location information associated with the mobile device; schedule the execution plan on the MEC node pool; and deploy the scheduled execution plan.

[0017] According to the second aspect, in a first implementation of the MEC distributed controller, the orchestrator is further configured to: divide the execution of the service into multiple tasks, each of which can be executed on an MEC node; and select a subset of the MEC node pool for each of the multiple tasks based on a selection function.

[0018] According to the second aspect or any one of the above implementations of the second aspect, in the second implementation of the MEC distributed controller, the MEC node pool is determined based on one of the user account level of the mobile device or the account level of the owner of the application associated with the service.

[0019] According to the second aspect or any one of the above implementations of the second aspect, in a third implementation of the MEC distributed controller, the orchestrator is further configured to: generate a cost and value for each MEC node in the MEC node pool for executing each of the multiple tasks on the MEC node; and select a MEC node from the MEC node pool for executing the task for each of the multiple tasks, the selection being performed based on the cost and value for executing the task on the MEC node, thereby generating a subset of the MEC node pool.

[0020] According to the second aspect or any one of the above implementations of the second aspect, in a fourth implementation of the MEC distributed controller, the orchestrator is further configured to: assign a release time and a deadline to a subset of the selected MEC node pool.

[0021] According to the second aspect or any one of the above implementations of the second aspect, in a fifth implementation of the MEC distributed controller, the orchestrator is further configured to: provide application data associated with the execution of the service to a subset of the selected MEC node pool, the application data being provided based on a release time and a deadline.

[0022] According to the second aspect or any one of the above-mentioned implementations of the second aspect, in a sixth implementation of the MEC distributed controller, the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or multiple MEC nodes expected to be covered by the execution plan; and the geographic location information includes at least the route of the mobile device.

[0023] According to the second aspect or any one of the above-mentioned implementations of the second aspect, in the seventh implementation of the MEC distributed controller, the orchestrator is further configured to: update the geographic location information of the mobile device based on at least one of the traffic information or the emergency information; determine an updated execution plan and an updated MEC node pool based on the updated geographic location information; schedule the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; and deploy the updated scheduling execution plan.

[0024] According to a third aspect, a MEC distributed controller is provided. The MEC distributed controller includes: a non-transitory memory including instructions; one or more processors in communication with the memory; wherein the one or more processors execute the instructions to cause the MEC distributed controller to: receive a MEC computing task request from a mobile device, the MEC computing task request being used to request a computing node that supports execution of a service on an MEC node controlled by the MEC distributed controller; obtain geographic location information associated with the mobile device; determine an execution plan and an MEC node pool for execution of the service, the execution plan and the MEC node pool being determined based on the geographic location information associated with the mobile device; schedule the execution plan on the MEC node pool; and deploy the scheduled execution plan.

[0025] According to the third aspect, in a first implementation of the MEC distributed controller, the instructions further cause the MEC distributed controller to: divide the execution of the service into multiple tasks, each of which can be executed on an MEC node; and select a subset of the MEC node pool for each of the multiple tasks based on a selection function.

[0026] According to the third aspect or any one of the above implementations of the third aspect, in the second implementation of the MEC distributed controller, the MEC node pool is determined based on one of the user account level of the mobile device or the account level of the owner of the application associated with the service.

[0027] According to the third aspect or any one of the above implementations of the third aspect, in a third implementation of the MEC distributed controller, the instructions further cause the MEC distributed controller to: generate a cost and value for each MEC node in the MEC node pool for performing each of a plurality of tasks on the MEC node; and select a MEC node from the MEC node pool for performing the task for each of the plurality of tasks, the selection being performed based on the cost and value for performing the task on the MEC node, thereby generating a subset of the MEC node pool.

[0028] According to the third aspect or any one of the above implementations of the third aspect, in a fourth implementation of the MEC distributed controller, the instruction further causes the MEC distributed controller to: assign a release time and a deadline to a subset of the selected MEC node pool.

[0029] According to the third aspect or any one of the above implementations of the third aspect, in a fifth implementation of the MEC distributed controller, the instruction further causes the MEC distributed controller to: provide application data associated with the execution of the service to a subset of the selected MEC node pool, the application data being provided based on a release time and a deadline.

[0030] According to the third aspect or any one of the above-mentioned implementations of the third aspect, in a sixth implementation of the MEC distributed controller, the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or multiple MEC nodes expected to be covered by the execution plan; and the geographic location information includes at least the route of the mobile device.

[0031] According to the third aspect or any one of the above-mentioned implementations of the third aspect, in the seventh implementation of the MEC distributed controller, the instruction further causes the MEC distributed controller to: update the geographic location information of the mobile device based on at least one of the traffic information or the emergency information; determine an updated execution plan and an updated MEC node pool based on the updated geographic location information; schedule the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; and deploy the updated scheduling execution plan.

[0032] An advantage of the preferred embodiment is that task allocation planning is performed based on the mobile device's geographic location information. Consequently, tasks are assigned based on the mobile device's predicted location and time, preventing the need to pause and move tasks during execution. Because the planning and scheduling of tasks and jobs associated with an application is performed based on the mobile device's geographic location information (including the mobile device's planned route, geographic information, real-time traffic information, emergency information, weather, etc.), task migration (which can occur when a task assigned to a processing resource cannot be completed before the mobile device leaves the processing resource's associated service area) is minimized. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] For a more complete understanding of the present invention and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0034] Figure 1 An example autonomous vehicle is shown;

[0035] Figure 2 A schematic diagram of service migration is shown;

[0036] Figure 3 A diagram illustrating an example mapping of services of example embodiments described herein to multi-access edge computing (MEC) nodes of a MEC network, wherein the MEC nodes are to perform at least a portion of the services;

[0037] Figure 4 A communication system according to an example embodiment described herein is shown, which emphasizes support for computing power offloading service execution on mobile devices;

[0038] Figure 5 A communication system according to an example embodiment described herein is shown, the communication system emphasizing a virtual resource pool for supporting the execution of a computing offload service for a mobile device;

[0039] Figure 6 shows a high-level view of an MEC site of the example embodiments described herein;

[0040] Figure 7A shows a first example configuration of MEC node connections according to example embodiments described herein;

[0041] Figure 7B shows a second example configuration of MEC node connections according to example embodiments described herein;

[0042] Figure 8 An MEC platform of example embodiments described herein is shown, which emphasizes decentralized planning capabilities of the MEC system orchestration functions of MEC sites;

[0043] Figure 9 An MEC platform of example embodiments described herein is shown, emphasizing virtualization of the infrastructure provided by the MEC framework;

[0044] Figure 10 A flowchart illustrating example operations occurring in an MEC framework workflow of example embodiments described herein;

[0045] Figure 11 A flowchart illustrating example operations occurring in a mobile device for offloading service computing power to an MEC platform according to example embodiments described herein;

[0046] Figure 12 A flowchart illustrating example operations that occur when offloading service computing power to an MEC platform according to example embodiments described herein;

[0047] Figure 13 A flowchart illustrating example operations occurring in an MEC node performing a computing offload service according to an example embodiment described herein;

[0048] Figure 14A A schematic diagram illustrating a mobile device and an MEC node according to an example embodiment described herein, the MEC node performing a task of a computing power offloading service for the mobile device at a first time instance;

[0049] Figure 14B A schematic diagram illustrating a mobile device and an MEC node according to an example embodiment described herein, wherein the MEC node performs a task of a computing power offloading service for the mobile device at a second time instance;

[0050] Figure 15 A schematic diagram illustrating scheduling tasks associated with a computing power offloading service to an MEC node according to an example embodiment described herein;

[0051] Figure 16A schematic diagram illustrating scheduling tasks associated with a computing offload service to MEC nodes according to an example embodiment described herein, wherein the scheduling emphasizes resource optimization;

[0052] Figure 17 is a block diagram of a computing system that can be used to implement the various apparatus and methods disclosed herein. DETAILED DESCRIPTION

[0053] The following describes in detail the structure and use of the disclosed embodiments. However, it should be understood that the present invention provides many applicable concepts that can be embodied in a variety of specific contexts. The specific embodiments discussed are merely illustrative of the specific structure and use of the embodiments and are not intended to limit the scope of the present invention.

[0054] Figure 1 An example autonomous vehicle 100 is shown. Autonomous vehicle 100 includes multiple users, such as users 105 through 107, who have mobile devices, such as PCs 110 through 111, toys 112, and health sensors 113. Mobile devices can execute applications, such as games, productivity applications, video conferencing applications, and content consumption applications. These applications can utilize services, such as gaming services, media content streaming services, conferencing services, data aggregation services, and surveillance services. In addition to users and their mobile devices, autonomous vehicle 100 also includes applications for tracking, autonomous driving, security, navigation, machine learning, machine vision, speech recognition, and gesture recognition. As used herein, the term "mobile device" will be used to refer to both electronic devices within autonomous vehicle 100 (e.g., computer modules for tracking, autonomous driving, security, navigation, machine learning, machine vision, speech recognition, gesture recognition, and the like) and mobile devices used by users within autonomous vehicle 100 (e.g., PCs, toys, game consoles, health sensors, and the like).

[0055] Typically, applications on mobile devices or services used by applications running on mobile devices can have high computing requirements. In many cases, the computing requirements can exceed the computing capabilities of the mobile device. This is especially true when multiple applications are running simultaneously on a single device.

[0056] Multi-access edge computing (MEC) platform architectures have been utilized to offload application execution to MEC nodes, which possess more computing resources than the mobile devices interacting with the applications. MEC nodes can receive requests from mobile devices to execute services associated with applications, along with data to be processed by the services and any user interactions (if any), and execute the services. The MEC nodes then provide the results of the service execution back to the mobile devices.

[0057] Therefore, although the service is executed on the MEC node, the input and output of the service and the interaction with the service are all carried out through the mobile device. In other words, the MEC node provides the computing resources for executing the service, but the purpose is to make the service appear to be executed on the mobile device.

[0058] MEC nodes have extensive computing resources and ultra-low latency. To deliver good performance and meet user experience expectations, applications require continuous service from MEC nodes and uninterrupted user interaction as mobile devices move from their origin to their destination. Unobtrusive or noticeable service interruptions are a requirement for MEC smart road scenarios.

[0059] However, if the mobile device moves too quickly or if the service execution takes longer, the mobile device may move from the service area of ​​a first MEC site, which includes a first MEC node currently executing the service, to the service area of ​​a second MEC site. In this case, it may be necessary to suspend the execution of the service at the first MEC node and migrate the service to the second MEC node located at the second MEC site. Migrating the service may introduce latency to the execution of the service, which may adversely impact the performance of the application or the user experience of the application's users. For example, Quality of Service (QoS) or latency requirements may be violated. For example, latency may cause false detection of objects in front of the autonomous vehicle 100 in a machine vision application, resulting in a serious safety situation. In another example, latency may cause a user to lose a video game. For another example, latency may introduce jitter to a video stream, resulting in a poor video consumption experience.

[0060] Therefore, there is a need for methods and apparatuses that support service mobility within a multi-access edge computing platform architecture. Such methods and apparatuses support service mobility, enabling seamless handover of service execution between MEC nodes and MEC sites, thereby preventing service interruptions. Support for service mobility addresses service interruptions caused by migrating service-associated tasks between MEC nodes. Because services support applications, service mobility is often referred to as application mobility. Therefore, application mobility can be used in place of service mobility.

[0061] Generally, autonomous vehicles and in-vehicle applications have the following technical requirements:

[0062] - Inter-MEC service mobility: Automotive applications have added new requirements based on large bandwidth and low latency. Ultra-fast service mobility requires MEC-assisted computing migration between different MEC nodes.

[0063] - Cross-edge node service continuity: For MEC nodes along the car’s path, automotive applications (such as those described previously) need to interact with MEC nodes at a high frequency (approximately 40-60 times per second).

[0064] - Low latency guarantee: Due to the high mobility of autonomous vehicles, moving large amounts of real-time data between MEC nodes (and autonomous vehicles) makes it difficult to guarantee low latency and other QoS requirements.

[0065] Challenges associated with MEC include:

[0066] - Mobile Device Mobility and Application Service Continuity in MEC Environments: Service mobility may not be a primary use case in the cloud. Applications do not need to be migrated due to client (i.e., mobile device) mobility. Migration typically involves migrating the entire virtual machine (VM), which can be costly. Furthermore, sequential migration that follows mobile device mobility is not addressed.

[0067] - Guaranteeing QoS requirements for migrated applications: Meeting QoS requirements while maintaining high availability of services during migration can be challenging.

[0068] - Dynamic Scheduling: Decoupling MEC application deployment and MEC node mapping can automatically schedule service execution plans.

[0069] One purpose may be to meet the service continuity requirements of fast-moving applications in fifth generation core (5GC) MEC networks.

[0070] Figure 2 A schematic diagram 200 of service migration is shown. Figure 2 The migration of a service from source MEC node 205 to target MEC node 207 is shown, with time increasing from left to right. At source MEC node 205, the migration of the service may include obtaining a VM minimum state (event 210), which includes the state of the state machine of the VM executing the service, as well as the data processed by the VM and any unprocessed input or output of the service. The VM minimum state is then transferred from source MEC node 205 to target MEC node 207 (event 212). The VM minimum state can be large, particularly for services involving large amounts of data, such as machine vision, gesture detection, and feature detection. Therefore, transferring the VM minimum state may involve moving a large amount of data between MEC nodes or MEC sites.

[0071] At the target MEC node 207, the VM is restored (Event 214). For example, restoring the VM may include starting a new VM with the transferred minimal state of the VM. The target MEC node 207 runs the restored VM (Event 216). If the service does not complete execution before the mobile device leaves the coverage area of ​​the MEC site including the target MEC node 207, further service migration may be required.

[0072] According to one example embodiment, an application framework supporting service mobility is provided. The application framework uses data flow graphs to decompose the computational and data dependencies of services, as well as the execution order of services. Services can be decomposed into multiple computationally and data-independent layers, referred to herein as independent layers. In one embodiment, each independent layer is mapped to an MEC resource for execution. The application framework specifies a software architecture paradigm for layer-by-layer transmission of computational results between different MEC resources.

[0073] In one embodiment, data streams are parsed in different execution steps according to the speed at which the mobile device executes the interactive application and mapped to abstract MEC nodes.

[0074] Each layer of the data flow graph represents how various operations are combined. In one embodiment, computing tasks are mapped to different MEC nodes with constraint parameters so that the execution time can meet the user service level agreement (SLA) requirements and QoS constraints.

[0075] Figure 3 A diagram 300 illustrates an example mapping of services to MEC nodes of an MEC network 305, where the MEC nodes will execute at least a portion of the services. Although the services are executed on the MEC nodes, the input and output of the services, as well as interactions with the services, are all performed through the mobile device. In other words, the MEC nodes provide the computing resources for executing the services, but the intent is to make it appear as if the services are executing on the mobile device. Therefore, the execution of the services on the MEC nodes is transparent to the mobile device or the user of the mobile device.

[0076] The MEC network 305 includes a radio access network (RAN) 307, which provides wireless connectivity for mobile devices to the MEC platform 309. The RAN 307 can utilize one or more wireless communication protocols, such as 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE), LTE-Advanced (LTE-A), 5G, 5G LTE, 5G NR, sixth generation (6G), High Speed ​​Packet Access (HSPA), IEEE 802.11 family of standards, such as 802.11a / b / g / n / ac / ad / ax / ay / be, etc.

[0077] The MEC platform 309 provides computing resources for executing services associated with the device's applications. The MEC platform 309 may include multiple MEC sites deployed in various locations, such as along major roads and highways, in buildings, on cell phone towers, in schools, shopping malls, at traffic lights, and so on. Each MEC site may include one or more MEC nodes (providing computing resources, memory resources, storage resources, etc.) for executing applications in VMs. Typically, each MEC node has significantly more resources than a mobile device (multiple multi-core processors, multiple gigabytes of memory, high-bandwidth connections, etc.).

[0078] MEC platform 309 is connected to packet core 311, which provides voice and data services on the network. For example, packet core 311 provides mobility management, data routing management, interface management, etc. MEC network 305 also includes internet 313 coupled to packet core 311. For example, internet 313 provides connectivity to services. As shown and used herein, component internet 313 only includes an interface to the internet.

[0079] The MEC platform 309 may include an MEC abstraction layer 320 and an M-app framework layer 340. The MEC abstraction layer 320 includes abstract MEC sites, such as MEC sites 322 to 326. Each MEC site may be assigned to perform tasks associated with one or more layers of a service. An example of application layer mapping is provided below.

[0080] like Figure 3 As shown, service 330, for which computing power is to be offloaded from a mobile device, is decomposed into N layers (layers 332 through 336) based on computation and data dependencies. Service 330 represents the service for which computing power is to be offloaded from a mobile device to the MEC platform 309 for execution. In addition to being decomposed by computation and data dependencies, each layer is sequentially numbered to indicate the order of execution. The layers of service 330 are mapped to the M-app framework layer 340, where these layers are labeled using similar reference numerals, but these are enclosed in single quotes (') to simplify discussion and reduce confusion. For example, in service 330, layer 1 is referenced by reference numeral 332, but after being mapped to the M-app framework layer 340, it is referenced by reference numeral 332'.

[0081] In one embodiment, the application framework maps one or more layers of a service to one or more MEC nodes of an MEC site. For example, layer 1 332' is mapped to the MEC node of MEC site 323. For another example, layer 3 334' and layer 4 335' are mapped to the MEC node of MEC site 325.

[0082] like Figure 3As shown, the layers of service 330 are not mapped to MEC site 322. Generally, if the MEC site does not meet the selection criteria for mapping the layers of the application to the MEC site, the layers of the service may not be mapped to the MEC site. Examples of selection criteria may include expected completion time, application priority, mobile device priority, user priority, available computing resources, etc. For example, there may not be enough processing resources at the MEC site to map the layers of the service. For another example, there may be enough processing resources at the MEC site, but the expected completion time of the layer is after the expected completion of the layer. Although the layers of service 330 are not mapped to MEC site 322, one or more layers of other services may be mapped to the MEC node of MEC site 322.

[0083] Figure 4 A communication system 400 is shown that emphasizes support for computing offload service execution on a mobile device 405. Figure 4 As shown, mobile device 405 moves along route 406 and interacts with application 407. Application 407 interacts with service 409. Instead of using its own computing resources to execute service 409 associated with application 407, mobile device 405 offloads the execution of service 409 to MEC platform 309. Mobile device 405 communicates with MEC platform 309 using RAN 307 (shown as an antenna).

[0084] The mobile device 405 may send an MEC task request to the MEC controller 410 to initiate computing power offloading of the service 409. For example, the MEC task request may specify the service name of the service 409. As previously described, for example, the M-app framework layer 340 decomposes the service 409 into independent layers. In one embodiment, the M-app framework layer 340 decomposes the service 409 in response to receiving the MEC task request. In another embodiment, the services supported by the MEC platform 309 are a priori decomposed and stored in a memory or database for subsequent use. The MEC abstraction layer 320 maps the independent layers of the service 409 to the MEC nodes of the MEC site. The mapping of the independent layers of the service 409 to the MEC nodes of the MEC site is discussed in detail below.

[0085] As an illustrative example, service 409 is decomposed into three independent layers: layer 1 410, layer 2 411, and layer 3 412. As previously described, mobile device 405 moves along route 406, and MEC platform 309 includes MEC sites 420, 421, 422, and 423 located along route 406. The three independent layers are mapped onto MEC sites 420, 421, and 422, which have coverage areas that include route 406. Figure 4As shown, layer 1 410 is mapped to MEC node 430 of MEC site 420. MEC node 431 is not assigned a layer for service 409, but MEC node 431 may not be idle because it may be executing a layer for another service. Similarly, layer 2 411 is mapped to MEC node 432 of MEC site 421, and layer 3 412 is mapped to MEC node 434 of MEC site 422.

[0086] In one embodiment, the mapping of MEC nodes from the standalone layer to the MEC site is performed based on the geographic location information of the mobile device 405. The geographic location information includes geographic and positional information of the mobile device 405 and may include location information provided by a global navigation satellite system (GNSS) (e.g., Global Positioning System (GPS), GLONASS, Galileo, BeiDou Navigation Satellite System (BDS), etc.), location measurement information based on cellular communication systems, speed information, terrain information, geographic information, navigation system information, traffic information, emergency service information, weather information, and the like. The geographic location information may provide information regarding the current location of the mobile device 405 and the predicted location of the mobile device 405 at different times in the future. For example, GNSS information may be used to provide the current location, speed, and direction of the mobile device 405. The future location of the mobile device 405 may be predicted based on the navigation information, traffic information, emergency service information, terrain information, geographic information, weather information, and the like.

[0087] Figure 5 A communication system 500 is shown that emphasizes a virtual resource pool for supporting the execution of computing offload services for mobile devices 405. Figure 5 As shown, mobile device 405 moves along route 406 and interacts with service 409 associated with application 407. Instead of using its own computing resources to execute service 409, mobile device 405 offloads the execution of service 409 to MEC platform 309. Mobile device 405 communicates with MEC platform 309 using RAN 307 (shown as antennas 505, 506, and 507).

[0088] As the mobile device 405 moves along the route 406, the mobile device 405 may leave the coverage of the first antenna or enter the coverage of the second antenna. In some cases, the mobile device may be within the coverage of multiple antennas. Figure 5 As shown, mobile device 405 is within the coverage area of ​​antennas 505 , 506 , and 507 .

[0089] Virtual resource pool 509 represents available MEC nodes of MEC sites that can communicate with mobile device 405 as mobile device 405 moves along route 406. In one embodiment, virtual resource pool 509 includes available MEC nodes that can communicate with mobile device 405 within a specific time window. Thus, virtual resource pool 509 can exclude MEC nodes that can communicate with mobile device 405, but only for a significant period in the future. Excluding these MEC nodes can be advantageous because mobile device 405 may no longer be on route 406 in the future, and planning for this possibility may be a waste of resources. Furthermore, uncertainty typically increases over time, so planning for the future may produce inaccurate results.

[0090] For example, virtual resource pool 509 may include a subset of MEC nodes of MEC sites 510, 511, 512, and 513. Generally, if the MEC node has sufficient computing resources to execute a particular layer of service 409 and complete the execution before the deadline, then the MEC node may be part of virtual resource pool 509 for mobile device 405. When mobile device 405 is within the coverage area of ​​the MEC site including the MEC node, the deadline is associated with the execution of the particular layer. If the MEC node does not have sufficient computing resources or cannot complete the execution before the deadline, then the MEC node is not included as a member of virtual resource pool 509.

[0091] Figure 6 A high-level view of a MEC site 600 is shown. The high-level view of the MEC site 600 presents a view of the software framework of the MEC site 600. The high-level view of the MEC site 600 includes MEC services 609 and a MEC distributed controller 603. The MEC distributed controller 603 includes a MEC infrastructure layer 605, a MEC hosting infrastructure 607, and a MEC system orchestration function 611.

[0092] The MEC distributed controller 603 includes components for controlling the operation of the MEC site 600 and planning, scheduling, and distributing various layers of the computing offload service executed on the resources of the MEC site 600. In one embodiment, the MEC distributed controller 603 performs planning, scheduling, and distribution of various layers of the computing offload service executed on the resources of the MEC site 600 and on the resources of other MEC sites in close proximity to the MEC site 600.

[0093] The MEC infrastructure layer 605 includes information related to the configuration of the MEC site 600, including control plane information 615 for configuring the control plane of the MEC site 600; data plane information 617 for configuring the data plane of the MEC site 600; and mobile device or access node information 619 for configuring a mobile device or access node coupled to the MEC site 600. An access node may also be generally referred to as a Node B, an evolved Node B (eNB), a next generation (NG) Node B (gNB), a master eNB (MeNB), a secondary eNB (SeNB), a master gNB (MgNB), a secondary gNB (SgNB), a network controller, a control node, a base station, an access point, a transmission point (TP), a transmission reception point (TRP), a cell, a carrier, a macro cell, a femto cell, a pico cell, etc., while a mobile device may also be generally referred to as a mobile station, a mobile station, a terminal, a user, a subscriber, a workstation, a user equipment (UE), etc.

[0094] The MEC hosting infrastructure 607 includes information related to the resource configuration of the MEC site 600. In the illustrated embodiment, the MEC hosting infrastructure 607 includes MEC network functions (NFs) 621 (including, but not limited to, user plane functions (UPFs) 623), which are responsible for supporting features and capabilities that facilitate user plane operations, such as packet routing and forwarding, interconnection with data networks, policy enforcement, data buffering, etc. The MEC hosting infrastructure 607 also includes information about the resources of the MEC site 600, such as input / output (I / O) resources 625 for inputting or outputting data from the MEC site 600, storage resources 627 for storing data or information by the MEC site 600, network resources 629 for communicating by the MEC site 600, and a virtualization layer 631 for executing programs or applications in VMs by the MEC site 600 (i.e., information about the virtualization layer 631 that supports the execution of services in VMs on MEC nodes of the MEC site 600).

[0095] The MEC system orchestration function 611 accepts service task requests, verifies policies, executes plans (e.g., resource planning, priority planning, location-based planning, etc.), schedules tasks and jobs, and distributes jobs. The MEC system orchestration function 611 includes a planning function 639, a policy management function 641, and a scheduling function 643.

[0096] The planning function 639 performs resource planning, priority planning, and location-based planning. It also accepts task requests (e.g., from mobile devices). It also shares information about resource status (e.g., computing resource status), the number of available computing resources, the number of idle computing resources, the percentage of available computing resources, and the percentage of idle computing resources. In other words, the planning function 639 performs high-level planning of resources, priorities, and other information based on geographic location information, and divides services based on computing resource availability. If certain geographic location information affecting the MEC sites and MEC nodes that make up the virtual resource pool changes (e.g., a mobile device's route changes), the planning function 639 may need to repeat the high-level planning of the service to reflect the changed geographic location information.

[0097] The policy management function 641 verifies policies, such as QoS policy matching and security matching. The scheduling function 643 schedules tasks and jobs associated with services (defined by the planning function 639) and distributes the jobs to MEC nodes. Jobs can be assigned to MEC nodes based on policy constraints, priority requirements, output deadlines, and other factors. In other words, the scheduling function 643 performs low-level scheduling, dispatching tasks and jobs associated with services to MEC nodes and MEC sites. Typically, the scheduling function 643 dynamically schedules tasks and jobs associated with services based on changes in geographic location information (e.g., a mobile device encountering a traffic jam and having to slow down, an accident causing travel delays for the mobile device, etc.). This geographic location information does not change the mobile device's route, but rather changes the mobile device's position along the route over time.

[0098] MEC services 609 include services executed in MEC site 600. Figure 6 As shown, MEC site 600 supports the execution of three services (e.g., services 633, 635, and 637). However, in practice, the number of services supported by a MEC site depends on the resources of the MEC site and the scale and complexity of the services. For example, a MEC site can support the execution of a large number of smaller, less complex services, while the same MEC site can support a relatively small number of larger, more complex services.

[0099] In one embodiment, the MEC distributed controller 603 operates in a distributed manner. Each MEC site may include a MEC distributed controller, and each MEC distributed controller operates together with other MEC distributed controllers. In one embodiment, MEC distributed controllers that are relatively close to each other operate in coordination with each other, where relative proximity can be defined as a distance parameter, a travel time parameter, a time parameter, etc. Relative proximity can be changed according to environmental factors, traffic information, emergency information, etc. For example, the MEC distributed controller of the first MEC site can share information related to the execution of the service with the MEC distributed controller of the second MEC site, and the two MEC distributed controllers can perform planning, scheduling and distribution for their respective MEC nodes. As used herein, for example, the distribution of tasks and jobs can be performed in a sequential or linear manner along the route of the mobile device. The sequential distribution of tasks and jobs follows the service time of the tasks or jobs. The MEC distributed controller 603 and the MEC system orchestration function 611 are discussed in detail below.

[0100] In one embodiment, a single MEC site may have one or more MEC nodes. In the case where a MEC site includes more than one MEC node, the MEC nodes may be connected in any of a variety of ways. For example, all MEC nodes may be connected. For another example, the MEC nodes may be partially connected.

[0101] Figure 7A A first example configuration 700 of MEC node connections is shown. Figure 7A As shown, multiple MEC nodes (including but not limited to MEC nodes 705, 706, 707 and 708) are partially connected, some of which are directly connected to each other, such as MEC nodes 705 and 706, MEC nodes 705 and 707, etc., and some of which are indirectly connected to each other, such as MEC nodes 705 and 708, MEC nodes 706 and 707, etc.

[0102] Figure 7B A second example configuration 750 of MEC node connections is shown. Figure 7B As shown, multiple MEC nodes (including but not limited to MEC nodes 755, 756, 757, and 758) are partially connected, where the MEC nodes are only connected to their immediate neighbors, e.g., MEC nodes 755 and 756, MEC nodes 757 and 758, etc. In addition, each MEC node is connected to a stream 760, which provides an instruction stream, a data stream, or both an instruction stream and a data stream to the MEC node.

[0103] In one embodiment, the MEC distributed controller is decentralized, wherein each MEC site has a MEC distributed controller implementation. For example, each MEC site has a MEC system orchestration function, and the MEC system orchestration function has a decentralized planning function, a decentralized policy management function, and a decentralized scheduling function. In one embodiment, although each MEC site includes a decentralized MEC distributed controller, collaboration is performed between the MEC distributed controllers. Collaboration between the MEC distributed controllers may include sharing planning information, policy information, scheduling information, priority information, task time and deadline, geographic location information, etc.

[0104] In one embodiment, the collaboration between the MEC distributed controllers of the MEC sites depends on the geographic location of the mobile device and the route of the mobile device. For example, the MEC distributed controllers of the MEC sites on the route of the mobile device can collaborate to plan, schedule and distribute tasks associated with the execution of services that offload computing power by the mobile device. This collaboration is discussed in detail below. For another example, the degree of collaboration between the MEC distributed controllers of the MEC sites on the route of the mobile device depends on the relative proximity of the MEC sites. For example, MEC sites that are adjacent and on the route of the mobile device generally have a greater degree of collaboration than MEC sites that are not adjacent but still on the route of the mobile device.

[0105] The degree of collaboration between various MEC distributed controllers can depend on the relative proximity of different MEC sites. For example, the degree of collaboration between MEC distributed controllers at two physically close MEC sites is higher than the degree of collaboration between MEC distributed controllers at two MEC sites that are farther apart. Similarly, the degree of collaboration between MEC distributed controllers at two adjacent MEC sites located on a busy highway is higher than the degree of collaboration between MEC distributed controllers at two MEC sites located on different, unconnected highways.

[0106] Figure 8 FIG3 illustrates an MEC platform 800 that emphasizes the decentralized planning capabilities of a MEC distributed controller for MEC sites. MEC platform 800 includes multiple MEC sites (including MEC sites 805 through 808). The MEC sites within the multiple MEC sites are interconnected. Each MEC site includes multiple MEC nodes. For example, MEC site 808 includes MEC nodes 810 through 812. Although each of the multiple MEC sites is shown as having the same number of MEC nodes, different MEC sites may have different numbers of MEC nodes.

[0107] In the decentralized MEC system orchestration function 814, multiple instances of planning functions (e.g., planning functions 815 through 818) are shown performing planning operations, including resource planning, priority planning, and location-based planning. Each planning function is associated with an MEC site. For example, planning function 815 is associated with MEC site 805, planning function 816 is associated with MEC site 806, and so on. Instances of other functions in the MEC system orchestration function 814 may also be included in the decentralized MEC system orchestration function 814, including policy management functions and scheduling functions.

[0108] According to one example embodiment, the MEC framework provides a single workload management interface. This single workload management interface provides a virtual single resource interface across geographically distributed MEC sites and MEC nodes. The MEC framework application programming interface (API) can implement the single workload management interface, where conceptually, mobile devices interact with a single decentralized MEC distributed controller rather than multiple individual MEC sites to perform planning, policy management, and scheduling functions. However, multiple MEC sites can implement their own decentralized MEC distributed controllers. In one embodiment, each MEC site implements its own decentralized MEC distributed controller. In another embodiment, a subset of MEC sites implement decentralized MEC distributed controllers. For example, in a deployment with multiple closely located MEC sites, one of these MEC sites can implement a decentralized MEC distributed controller that performs planning, policy management, and scheduling functions for multiple MEC sites in a general area. The MEC framework manages tasks associated with computational offload services along the MEC platform. Furthermore, a method and apparatus for abstracting service workloads based on priority, geographic location (e.g., location, route, etc.), application QoS, account QoS, compute type, and the like are provided.

[0109] The infrastructure provided by the MEC site is virtualized and provides the following functions:

[0110] - Dynamic resource management, tracking the movement of mobile devices (e.g., routes). Provides management of resources at MEC sites and MEC nodes along the mobile device's route, enabling timely execution of tasks associated with services offloaded from the mobile device.

[0111] - Synchronize the status of adjacent MEC nodes and MEC sites, enabling the scheduling of tasks to available computing resources.

[0112] -Knowledge of different MEC node computing resources and resource types and their corresponding capabilities.

[0113] - Mapping workloads (tasks associated with the mobile device's compute offload service, as well as other mobile device tasks) to compute resources and vice versa.

[0114] Figure 9 FIG. 9 shows an MEC platform 900 that emphasizes the virtualization of the infrastructure provided by the MEC framework. The MEC platform 900 includes MEC sites (e.g., MEC sites 905 to 908), each of which includes multiple MEC nodes (e.g., MEC site 905 includes MEC nodes 910, 911, and 912). Antennas such as antennas 915, 916, and 917 provide RAN connectivity to the MEC sites for mobile devices 920. Figure 9 As shown, antenna 915 provides connection for MEC site 905, antenna 916 provides connection for MEC site 906, and antenna 917 provides connection for MEC site 907.

[0115] Virtual resource pool 925 represents resource virtualization of MEC sites and MEC nodes of MEC platform 900, such as resource groups 930 to 932. For example, resource group 930 represents resources of MEC site 905, resource group 931 represents resources of MEC site 906, and resource group 932 represents resources of MEC site 907. As shown in each resource group, each black solid circle (e.g., black circles 935 and 936) represents a single computing resource of the MEC site, such as a MEC node.

[0116] The system orchestration function of the decentralized MEC distributed controller selects one or more resources to perform at least a portion of the task associated with the computing power offloading service. For example, the system orchestration function of the decentralized MEC distributed controller selects the resource corresponding to the highlighted circle 937 in resource group 930 to perform a portion of the task on MEC site 905. Similarly, the system orchestration function of the decentralized MEC distributed controller selects the resource corresponding to the highlighted circle 938 in resource group 931 to perform a portion of the task on MEC site 906, and selects the resource corresponding to the highlighted circle 939 in resource group 932 to perform a portion of the task on MEC site 907.

[0117] In one embodiment, based on resource availability and the requirements of the task associated with the offload service, the decentralized MEC distributed controller can select zero or more resources to perform a portion of the task. For example, the decentralized MEC distributed controller may select a resource from a first resource group to perform the first portion of the task associated with the offload service. If insufficient resources are available in the resource group to perform the first portion of the task, resources from another resource group may need to be selected to perform the first portion of the task. For another example, the decentralized MEC distributed controller may select two resources from a second resource group to perform the second portion of the task associated with the offload service. The decentralized MEC distributed controller may select two resources from the second resource group (as opposed to just one resource from the first resource group) based on a variety of factors, including: the second portion of the task has greater resource requirements than the first portion of the task; the mobile device spends more time near the second resource group than the first resource group (e.g., as determined by the mobile device's route), and therefore, when near the second resource group, a larger portion of the service is expected to be performed; the first portion of the task is not allocated to any resources in the first resource group, and resources from the second resource group must be allocated to perform the first portion of the task; and so on.

[0118] Figure 10 A flow chart illustrating example operations 1000 occurring in an MEC framework workflow is provided. Operations 1000 may indicate operations occurring in an MEC framework as follows: the MEC framework receives a MEC computing task request to offload computational power for the execution of a service and deploys the jobs associated with the execution of the service onto resources at an MEC site to support service mobility and ensure an acceptable user experience.

[0119] Operations 1000 begin with the MEC framework receiving a MEC computing task request (block 1005). The MEC framework may receive a MEC computing task request from a mobile device connected to the MEC platform. The MEC computing task request may be a request to offload computing power from a single server to resources of the MEC platform. For example, the MEC computing task request may be initiated by a mobile application executing on a mobile device using a MEC API. The MEC Fluid Framework API is an example of a MEC API.

[0120] The MEC computing request can provide information for offloading computing power to the service, including the service for which computing power is being offloaded, the priority of the mobile device (or the user of the mobile device), user information (e.g., account information, priority information, QoS requirements and restrictions, etc.), mobile device information (e.g., account information, priority information, QoS requirements and restrictions, etc.), geographic location information (including current location, destination), the route of the mobile device (e.g., provided by a navigation application), etc.

[0121] An MEC node request is issued (block 1007). For example, an MEC node request may be issued to various MEC sites and MEC nodes along the mobile device's route. The MEC node request is used to verify and confirm the request by the mobile device (e.g., the user of the mobile device or the user of the mobile application) (blocks 1009 and 1011). Policy management is performed (block 1013). Policy management is performed by the policy management function of the decentralized MEC distributed controller and may, for example, match policies (e.g., QoS policies, security policies, etc.) for services, mobile devices, users, and resources of the MEC platform (block 1015). For example, policy management may include Fluid Framework policy management.

[0122] Execution planning (block 1017). For example, planning may include fluid framework planning. Planning determines an execution plan for executing the offload service on the MEC platform. For example, the execution plan specifies tasks associated with the offload server, resources to execute the tasks, and so on. Planning is performed by the planning function of the decentralized MEC distributed controller and includes, for example, resource planning (block 1019), priority planning (block 1021), and geographic location planning (block 1023). Resource planning may include determining the resources required to execute the offload service. For example, resource planning determines the total amount of resources required to execute the offload service. In another example, resource planning determines the amount of resources required to execute a portion of the offload service at each MEC site when the mobile device is connected to the MEC site. In this example, resource planning utilizes the mobile device's route as well as traffic information (e.g., traffic conditions, traffic congestion, etc.), terrain information (e.g., alternative roads or routes, etc.), and geographic information (e.g., geographic features that may affect the mobile device's connection, etc.).

[0123] Priority planning can be similar to resource planning, but requires consideration of priority information. For example, priority planning can leverage priority information to help ensure that QoS and security constraints and requirements are met. For example, resources can be tiered based on the priority of the offload service, the mobile device, or both.

[0124] Geolocation planning leverages the mobile device's geolocation information to assist with resource planning and priority planning. For example, geolocation information can help determine the resources required at each MEC site along the mobile device's route to provide sufficient performance to meet user experience expectations, QoS, and security constraints. Furthermore, geolocation information (such as traffic conditions and emergency information) can be used to adjust resource planning and priority planning. For example, unexpected traffic congestion may require the allocation of additional resources at some MEC sites to ensure sufficient resources are available for computing offload services. Conversely, unexpectedly fast traffic may cause some previously allocated resources at some MEC sites to become available for reallocation to execute other services.

[0125] Scheduling is performed (block 1025). Scheduling can be performed by the scheduling function of the decentralized MEC distributed controller. Scheduling involves dividing the tasks associated with the offload service into jobs that can be executed by the resources of the MEC site (block 1027). If the computational complexity of a task is too large to be completed within a certain timeframe, the task can be divided into multiple jobs. Scheduling also involves assigning release times and deadlines to tasks or jobs to ensure that the job begins at the appropriate release time and, therefore, completes before the deadline (block 1029). Adhering to release times and deadlines ensures that user experience, as well as QoS and security constraints and requirements, are met. Scheduling can be performed in a manner that accommodates the capacities of different MEC sites. Furthermore, scheduling can help maintain high efficiency at the MEC sites (block 1031). For example, if tasks or jobs are not scheduled to minimize communication between distant MEC sites, unnecessary communication between MEC sites may occur, potentially saturating communication links and potentially leading to poor communication performance and overall performance degradation. Similarly, an overutilized MEC site may result in excessive switching of services in and out of the MEC site's program memory, which may cause the time spent switching services to be longer than the actual execution time of the services themselves.

[0126] Deploy the scheduled tasks or jobs (block 1033). Deploying the scheduled tasks or jobs may include distributing data and information to the different MEC nodes at the MEC site. For example, the MEC nodes may be provided with information about the offload services scheduled for the MEC nodes (e.g., which portion of the offload services has been scheduled for the MEC nodes), the data to be processed by the MEC nodes when executing the offload services, expected user interactions, release times, and deadlines. In one embodiment, job deployment may include any real-time changes to the scheduled tasks or jobs. For example, an unexpected traffic jam or the sudden removal of a traffic jam (or any other unplanned stop or change in a mobile device's route) may result in changes to the scheduled tasks or jobs. Changes to the scheduled tasks or jobs may be implemented, for example, by redistributing data and information to the affected MEC nodes.

[0127] Figure 11 A flow chart illustrates example operations 1100 occurring in a mobile device when offloading service computing power to an MEC platform. Operations 1100 may indicate operations occurring in a mobile device when offloading the execution computing power of a service to an MEC platform. Rather than directly executing the service, which may require more resources than are available at the mobile device, the mobile device offloads the service computing power to the MEC platform, which provides the resources for executing the service. The MEC platform also provides planning and scheduling infrastructure to support the execution of the service.

[0128] Operations 1100 begin with a mobile device requesting an MEC computing task (block 1105). An MEC computing task can be a request to offload application computing power to an MEC platform, where the MEC platform provides resources for performing the computing power offloading service. A mobile device can request an MEC computing task by sending an MEC computing request to the MEC site to which it is currently connected. The MEC computing request can provide information for offloading computing power to the service, including the service being offloaded, the priority of the mobile device (or mobile device user), user information (e.g., account information, priority information, QoS requirements and restrictions, etc.), mobile device information (e.g., account information, priority information, QoS requirements and restrictions, etc.), geographic location information (including current location and destination), and the mobile device's route (e.g., provided by a navigation application).

[0129] Verify the request (block 1107). The verification request may include a verification request and a confirmation request. The verification request may include authenticating the mobile device (or user) account, including the account's priority, security level, and status. For example, the confirmation request may include prompting the user to confirm their desire to use the computing power offloading service.

[0130] The mobile device interacts with the MEC node and the MEC site (block 1109). As part of service execution, the mobile device (or the user of the mobile device) can provide input to the service and receive output from the service. The mobile device can also interact with the service. The mobile device receives results from the service execution (block 1111). Service execution can produce results that are provided to the mobile device upon production. Service execution can also produce results upon completion. In either case, the results are provided to the mobile device.

[0131] Figure 12 A flow diagram illustrating example operations 1200 occurring when offloading service computing power to an MEC platform is shown. Operations 1200 may be indicative of operations occurring in a decentralized MEC distributed controller as the decentralized MEC distributed controller participates in offloading service computing power to an MEC platform.

[0132] As previously mentioned, the decentralized MEC distributed controller performs operations to help ensure that the execution of computational offload services provides a good user experience while meeting QoS and security requirements and constraints. Furthermore, the decentralized MEC distributed controller helps ensure that the capacity and efficiency of MEC sites and nodes are maintained. For example, the decentralized MEC distributed controller can perform load balancing to help ensure that no particular MEC site or MEC node is overloaded, which could reduce the capacity and efficiency of the MEC platform.

[0133] Operations 1200 begin by receiving an MEC computing task request (block 1205). For example, the MEC computing task request may provide information for a computing offload service. The MEC computing task request may be received from a mobile device that is using the computing offload service. The MEC computing task request is validated (block 1207). The validation request may include a verification request and a confirmation request. The validation request may include issuing MEC node requests to MEC nodes and MEC sites along the mobile device's route to verify and confirm the mobile device. For example, the mobile device's subscription or account may be verified at the MEC node and MEC site.

[0134] The decentralized MEC distributed controller performs policy management (block 1209). Policy management can include policies for matching services, mobile devices, and MEC platform resources, such as QoS policies and security policies. The decentralized MEC distributed controller performs planning (block 1211). Planning includes resource planning, priority planning, and geolocation planning. Resource planning can include determining the resources required to execute the computing offload service. Priority planning can be similar to resource planning, but requires consideration of priority information. Geolocation planning leverages the mobile device's geolocation information to facilitate resource and priority planning.

[0135] The decentralized MEC distributed controller performs scheduling (block 1213). Scheduling also involves dividing tasks associated with the offload service into jobs. If some tasks are too computationally intensive for a single MEC node to complete within the allocated time, these jobs can be performed by resources at the MEC site. Scheduling can also include mapping tasks or jobs to the MEC node selected to execute them. Scheduling also determines the worst-case execution time for the selected MEC node. Scheduling also involves assigning release times and deadlines to tasks or jobs to ensure that the tasks or jobs begin at the appropriate release time and, therefore, complete before the deadline. Scheduling utilizes geographic location information to schedule tasks or jobs so that they complete when the mobile device is within range of the MEC site(s) with the resources to execute the job(s). Scheduling also utilizes traffic information, emergency information, terrain information, geographic information, and other information. Adherence to release times and deadlines ensures that user experience, as well as QoS and security constraints and requirements, are met. Scheduling also takes into account the existing load at the MEC site and MEC nodes. Scheduling can be performed in a manner that accommodates the capacity of different MEC sites. Additionally, scheduling can help keep MEC sites efficient.

[0136] The decentralized MEC distributed controller deploys tasks or jobs (block 1215). Tasks or jobs are deployed by the decentralized MEC distributed controller according to a schedule. Deploying scheduled tasks or jobs may include distributing data and information to different MEC nodes at the MEC site. Any changes that result in a change to the scheduled tasks or jobs may cause the decentralized MEC distributed controller to repeat the deployment of the tasks or jobs. For example, changes to the scheduled jobs may be implemented by redistributing data and information to the affected MEC nodes.

[0137] Figure 13 A flow chart illustrating example operations 1300 occurring in an MEC node performing a power offload service. Operations 1300 may indicate operations occurring in an MEC node when the MEC node performs a power offload service. The MEC node may execute a job scheduled for the MEC node.

[0138] Operations 1300 begin with an MEC node receiving task(s) or job(s) (block 1305). The MEC node receives data and information related to the task(s) or job(s) assigned to the MEC node. For example, the MEC node may be provided with information regarding the offload services scheduled for the MEC node (e.g., which portion of the offload service is scheduled for the MEC node), the data to be processed by the MEC node during execution of the offload service, expected user interactions, release times, and deadlines. Any updates to the scheduled job(s) for the MEC node may result in the MEC node receiving updated data and information. The MEC node executes the task(s) or job(s) and interacts with a mobile device (block 1307). The MEC node executes the task(s) or job(s) based on the provided release times and deadlines to ensure that the MEC node completes execution of the task(s) or job(s) before the deadline. The MEC node may interact with the mobile device. For example, the MEC node may receive data from the mobile device. The MEC node may also receive user input from the mobile device. The MEC node may also provide information or data to the mobile device.

[0139] According to one example embodiment, resource planning associated with a computing offload service is performed based on an objective function. Tasks or jobs associated with the computing offload service can be simply assigned to MEC sites and MEC nodes with sufficient resources to execute these jobs in a timely manner. However, this simplistic planning approach may result in some MEC sites and MEC nodes being overburdened while others being underutilized. This can lead to inefficiencies in the MEC platform and low capacity utilization.

[0140] In one embodiment, planning resources involves optimizing the objective function of efficiency and capacity of the MEC platform. Planning resources using the objective function helps distribute tasks or jobs associated with a service across multiple MEC sites and MEC nodes to prevent some MEC sites and MEC nodes from being overburdened.

[0141] As an illustrative example, consider the following scenario: a mobile device is moving along a route and is ready to offload the execution of a service to the MEC platform. The service consists of tasks Ti, which are assigned to appropriate resources of the MEC sites and MEC nodes of the MEC platform. The following notation is used:

[0142] nn: the number of MEC nodes in the plan;

[0143] MEC = {MN1, MN2, …, MNnn}: the set of MEC nodes under consideration, where MNi represents MEC node i;

[0144] MNCi: computing capacity of MEC node MNi;

[0145] T = {T1, T2, …, Tm}: the set of tasks planned to be executed on the MEC nodes, where m is the number of tasks considered;

[0146] Ti = {Ji,1, …, Ji, ji}: Task i contains a sequence of jobs ji. Jobs must be executed in sequence, i.e., Ji,j+1 can only start after Ji,j ends.

[0147] JCi,j: the computational requirement of task Ji,j;

[0148] JRTi,j: the release time of task Ji,j; and

[0149] Pij: Within the predicted duration of a time slot (for a specific node, as different facilities have different computing capabilities), each job in Ti must end after its release. This means that for any consecutive pair Ji,j and Ji,j+1 in Ti, JRi,j+1 >= JRi,j+ Pij.

[0150] All the symbols given above have known values ​​for planning:

[0151] JSTi,j: the actual start time of the execution of job Ji,j; and

[0152] JMNi,j: MEC node assigned to execute job Ji,j.

[0153] The example plan is as follows:

[0154] Given i Î [1, m] and j Î Ti,

[0155] (1) JRTi,j <= JSTi,j

[0156] (2) 1<=JMNi,j <=JMNi,j+1<=nn

[0157] Given i Î [1, m] and j Î Ti and JMNi,j = k, k Î [1, nn] (k: node)

[0158] (3) JSTi,j + JCi,j / MNCk <= JRTi,j + Pij

[0159] Given k Î [1, nn], i Î [1, m], j Î Ti, JMNi,j = k, t0 = Min(JSTi,j), and t1 = Max (JSTi,j + Pij)

[0160] (4) ∑ JCi,j <= MNCk * (Max ({JSTi,j + Pij}) – Min({JSTi,j}))

[0161] Where: Equations (1), (2), and (3) are constraint equations. One possible solution is to determine JST i,j and JMNi,j that satisfy the constraint equations. Among multiple solutions, the best solution that will reflect the predetermined service strategy is selected.

[0162] In one embodiment, resource planning is a dynamic programming problem. In the resource planning problem, for a given task Ti, an objective function can be defined. For example, each MEC node has an associated cost and value that can be used to determine whether the MEC node should be assigned to perform task Ti. An example cost associated with an MEC node can be computation time. An example value associated with an MEC node can be a function of geographic location, priority, computing power or capacity, and the like.

[0163] At a specific time t MEC nodes can dynamically join the virtual resource pool. For example, at a specific time t At a certain time, because the mobile device is expected to be approaching an MEC site that includes an MEC node (where the expectation that the mobile device is approaching the MEC site is determined based on the route of the mobile device), the MEC node can be added to the virtual resource pool. Similarly, an MEC node can be dropped from the virtual resource pool. For example, at a certain time t At this point, because the mobile device is expected to be leaving the MEC site that includes the MEC node (where the expectation that the mobile device is leaving the MEC site is determined based on the route of the mobile device), the MEC node can be dropped from the virtual resource pool. As used in this discussion, approaching and leaving the MEC site refers to approaching and leaving the coverage area of ​​the MEC site.

[0164] Typically, each MEC node can be in one of the following three states: idle, acquired (locked), and serving, where idle means that the MEC node is not performing a task, acquiring means that the MEC node has been assigned a task, and serving means that the MEC node is performing a task.

[0165] Therefore, in order to find a solution (i.e., planning resources or assigning tasks to MEC nodes) within a limited total computing time T (which is the total cost of planning resources), one or more MEC nodes are selected that can both execute the application (the application's tasks) and maximize the value.

[0166] An algorithmic description of an example embodiment of the solution is as follows:

[0167] E[0][T] = 0; / / / Initial state. E is the energy to be maximized.

[0168] If c[i] > T, / / / If the cost of MEC node i exceeds the total computation cost

[0169] Then E[i][T] = E[i-1][T]; / / / MEC node i is not selected.

[0170] otherwise

[0171] E[i][T] = max{E[i-1][Tc[i]+v[i]], E[i-1][T]};

[0172] / / / E[i][T] - energy of MEC node i with time T constraint,

[0173] / / / E[i-1][Tc[i]+v[i]] - shows when MEC node i-1 is selected

[0174] / / / Total available time of remaining MEC nodes minus cost: c[i]

[0175] / / / (here, the cost is E[i-1][Tc[i]]), and the total energy plus

[0176] / / / Value: v[i].

[0177] E[i-1][T] - shows the total energy when MEC node i-1 is not selected

[0178] / / / Same as the previous step.

[0179] / / / Select the two parts based on the criterion of maximizing the total energy

[0180] / / / The larger one.

[0181] In one embodiment, once an MEC node is selected to perform a task or job associated with a computational offload service, the deployment of the task or job includes setting the state of the MEC node resources selected for acquisition or locking to help ensure that these MEC nodes are not selected for other services. Not all MEC nodes selected for the computational offload service must be locked. Only those MEC nodes in close proximity to the mobile device should have their state changed. If the selected MEC node is not needed within a specified time period, the state of each selected MEC node is not changed, allowing it to be used for other services. For example, the specified time period can be specified by the operator of the MEC platform. The specified time period can also be determined based on the time required to execute the task or job, such as the worst-case execution time (WCET). After the MEC node completes execution of its assigned task or job, it is released back to the virtual resource pool. For example, the MEC node can be released back to the virtual resource pool by setting its state to idle.

[0182] Figure 14A Schematic diagram 1400 shows a mobile device 1405 and MEC nodes that, at a first time instance, are performing a job associated with a computation offload service for the mobile device 1405. At the first time instance, MEC nodes 1411, 1412, 1413, and 1414 (indicated by dashed circles) are performing a job associated with the computation offload service for the mobile device 1405 (traversing route 1406), while other MEC nodes, such as MEC nodes 1410 and 1415 (indicated by clear circles), have not been selected to perform a job associated with the computation offload service (or at least have not yet performed a job associated with the computation offload service).

[0183] MEC nodes 1411, 1412, 1413, and 1414 may be MEC nodes within a time window of the current location of mobile device 1405. MEC nodes within the time window can be expected to provide services to mobile device 1405 or will provide services to mobile device 1405 with a certain probability. The size of the time window may vary depending on factors including environmental factors, traffic information, emergency information, etc. Generally, the time window should be large enough to enable efficient scheduling of multiple MEC nodes at any one time, but the time window should not be too large, or the uncertainty associated with the mobility of mobile device 1405 may result in too many scheduled jobs and tasks having to be rescheduled.

[0184] As an alternative to the time window, the number of MEC nodes that execute the job of the mobile device 1405 can be a pre-specified value. Figure 14AIn the example, the number of MEC nodes is 4, but another number may be pre-specified. The number of MEC nodes may be related to the time window. For example, if the mobile device 1405 moves quickly, the number of MEC nodes may be larger, while if the mobile device 1405 moves slowly, the number of MEC nodes may be smaller.

[0185] Figure 14B Schematic diagram 1450 shows a mobile device 1405 and an MEC node that is executing a job associated with a power offload service for mobile device 1405 at a second time instance. The second time instance is later than the first time instance. At the second time instance, MEC nodes 1412, 1413, 1414, and 1415 are within the time window and are executing a job associated with the power offload service for mobile device 1405 (traversing route 1406), while other MEC nodes, such as MEC nodes 1410, 1411, and 1416, have not been selected to execute a job associated with the power offload service (or at least have not yet executed a job associated with the power offload service).

[0186] Figure 15 Schematic diagram 1500 is shown for scheduling tasks associated with a computing offload service to an MEC node. Figure 15 As shown, MEC nodes of MEC sites 1510 , 1512 , and 1514 are selected to perform tasks associated with the computing power offloading service for mobile device 1505 .

[0187] As previously described, the MEC platform's decentralized MEC distributed controller receives MEC computing task requests from mobile device 1505 for computing offload services and deploys the computing offload service tasks to MEC sites 1510 through 1514. In one embodiment, the decentralized MEC distributed controller receives the results of executing the computing offload service tasks at the current MEC site (e.g., MEC site 1510) and provides the results to the next MEC site (e.g., MEC site 1512). The decentralized MEC distributed controller, which controls the propagation of computing results, can help ensure that the results are provided to the next MEC site correctly and in a timely manner.

[0188] The decentralized MEC distributed controller schedules the computational MEC nodes and output MEC nodes for a task Ti. The decentralized MEC distributed controller controls the sequence of processing flows and the delivery of results between MEC nodes. Given n tasks and a total of m MEC nodes, the decentralized MEC distributed controller determines where, when, and for how long tasks should be executed to ensure deadlines (e.g., QoS constraints and requirements) are met.

[0189] like Figure 15As shown, the service period is Pi, which is greater than or equal to the WCET of the computing offloading service. Task Ti corresponds to multiple jobs, where J(i,j) corresponds to the jth job of task Ti (j=1, 2, ...). In addition, each job has a release time R(i,j) and a deadline D(i,j), where D(i,j) = R(i,j) + Pi. In general, each job requires ci resources, where ci is an integer. Figure 15 As shown, job j of task Ti has a release time R(i,j) 1520 and a deadline D(i,j) 1522. Job j (as shown in block 1524) is executed by MEC site 1510. Similarly, job j+1 of task Ti has a release time R(i,j+1) 1525 and a deadline D(i,j+1) 1527. Job j+1 (as shown in blocks 1528 and 1529) is executed by MEC site 1512.

[0190] Figure 16 Schematic diagram 1600 is shown for scheduling tasks associated with a computing offload service to MEC nodes, wherein the scheduling emphasizes resource optimization. Figure 16 As shown, MEC nodes of MEC sites 1510, 1512, and 1514 are selected to perform tasks associated with the computing offload service of mobile device 1505. When scheduling tasks or jobs, MEC system orchestration function 1605 also uses resource optimization as input. For example, the utilization of task Ti can be expressed as

[0191] ui = ci / Pi.

[0192] The task set consists of n tasks T1, T2, ..., Tn, and the total utilization can be expressed as

[0193] u_total = summation(ui) = summation(ci / Pi).

[0194] Figure 17 17 is a block diagram of a computing system 1700 that can be used to implement the devices and methods disclosed herein. For example, the computing system can be an MEC node or an MEC site. A particular device may utilize all or only a subset of the components shown, and the degree of integration may vary between devices. In addition, a device may include multiple component instances, such as multiple processing units, processors, memories, transmitters, receivers, and so on. Computing system 1700 includes a processing unit 1702. The processing unit includes a central processing unit (CPU) 1714, memory 1708, and may also include mass storage 1704 connected to a bus 1720, a video adapter 1710, and an I / O interface 1712.

[0195] Bus 1720 may be one or more of any of several bus architectures, including a memory bus or memory controller, a peripheral bus, or a video bus. CPU 1714 may include any type of electronic data processor. Memory 1708 may include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In one embodiment, memory 1708 may include ROM for use during system startup and DRAM for program and data storage during program execution.

[0196] Mass storage 1704 may include any type of non-transitory storage device for storing data, programs, and other information and making such data, programs, and other information accessible via bus 1720. Mass storage 1704 may include, for example, one or more of a solid-state drive, a hard disk drive, a magnetic disk drive, or an optical disk drive.

[0197] Video adapter 1710 and I / O interface 1712 provide interfaces for coupling external input and output devices to processing unit 1702. As shown, examples of input and output devices include a display 1718 coupled to video adapter 1710 and a mouse, keyboard, and printer 1716 coupled to I / O interface 1712. Other devices may be coupled to processing unit 1702, and additional or fewer interface cards may be utilized. For example, a serial interface such as a Universal Serial Bus (USB) (not shown) may be used to provide an interface to external devices.

[0198] Processing unit 1702 also includes one or more network interfaces 1706, which can include wired links such as Ethernet cables or wireless links for accessing nodes or different networks. Network interface 1706 allows processing unit 1702 to communicate with remote units via a network. For example, network interface 1706 can provide wireless communication via one or more transmitters / transmit antennas and one or more receivers / receive antennas. In one embodiment, processing unit 1702 is coupled to a local area network 1722 or a wide area network for processing data and communicating with remote devices such as other processing units, the Internet, or remote storage facilities.

[0199] It should be understood that one or more steps of the exemplary methods provided herein may be performed by corresponding units or modules. For example, a signal may be transmitted by a transmitting unit or transmitting module. A signal may be received by a receiving unit or receiving module. A signal may be processed by a processing unit or processing module. Each unit or module may be hardware, software, or a combination thereof. For example, one or more of these units or modules may be an integrated circuit, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0200] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope of the invention as defined by the appended claims.

Claims

1. A method implemented by a multi-access edge computing (MEC) distributed controller, the method comprising: The MEC distributed controller receives an MEC computing task request from a mobile device, wherein the MEC computing task request is used to request a computing node that supports executing a service on an MEC node controlled by the MEC distributed controller; Acquiring, by the MEC distributed controller, geographic location information associated with the mobile device; Determining, by the MEC distributed controller, an execution plan and an MEC node pool for executing the service, wherein the determination is performed based on the geographic location information associated with the mobile device; The MEC distributed controller schedules the execution plan on the MEC node pool; The execution plan scheduled by the MEC distributed controller deployment; updating, by the MEC distributed controller, the geographic location information of the mobile device according to at least one of traffic information or emergency information; The MEC distributed controller determines an updated execution plan and an updated MEC node pool according to the updated geographic location information; The MEC distributed controller schedules the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; as well as The updated scheduling execution plan is deployed by the MEC distributed controller.

2. The method of claim 1, wherein the execution plan and the MEC node pool are associated with the execution of the service for a time window or a specified number of MEC nodes.

3. The method according to any one of claims 1 to 2, wherein determining the execution plan comprises: dividing, by the MEC distributed controller, the execution of the service into a plurality of tasks, wherein each task is executable on an MEC node; as well as The MEC distributed controller selects a subset of the MEC node pool for each of the multiple tasks according to a selection function.

4. The method according to claim 3, wherein the MEC node pool is determined according to one of a user level of the mobile device or an account level of an owner of an application associated with the service.

5. The method of claim 3, wherein selecting the subset of the MEC node pool comprises: Generating, by the MEC distributed controller, for each MEC node in the MEC node pool, a cost and a value for executing each of the plurality of tasks on the MEC node; as well as The MEC distributed controller selects an MEC node from the MEC node pool for executing each of the multiple tasks, wherein the selection is performed based on the cost and the value of executing the task on the MEC node, thereby generating the subset of the MEC node pool.

6. The method according to claim 5, wherein scheduling the execution plan comprises: The MEC distributed controller assigns a release time and a deadline to the selected subset of the MEC node pool.

7. The method according to any one of claims 5 to 6, wherein deploying the scheduled execution plan comprises: The MEC distributed controller provides application data associated with the execution of the service to the selected subset of the MEC node pool, wherein the providing is performed according to the release time and the deadline. 8 . The method of claim 6 , wherein the release time comprises a required start time for the plurality of tasks, and the deadline time comprises a required end time for the plurality of tasks.

9. According to the method according to any one of claims 1 to 6, the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or a plurality of MEC nodes expected to be covered by the execution plan; and the geographic location information includes at least a route of the mobile device.

10. A multi-access edge computing (MEC) distributed controller, comprising: One or more MEC nodes, configured to execute jobs; a receiver configured to receive an MEC computing task request from a mobile device, the MEC computing task request being used to request a computing node that supports execution of a service on an MEC node controlled by the MEC distributed controller; an orchestrator operatively coupled to the receiver and the one or more MEC nodes, the orchestrator configured to: obtaining geographic location information associated with the mobile device; Determining an execution plan and an MEC node pool for executing the service, wherein the determining is performed based on the geographic location information associated with the mobile device; Scheduling the execution plan on the MEC node pool; Deploying the scheduled execution plan; updating the geographic location information of the mobile device based on at least one of traffic information or emergency information; Determining an updated execution plan and an updated MEC node pool according to the updated geographic location information; Scheduling the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; as well as A scheduled execution plan is deployed to deploy the update.

11. The MEC distributed controller according to claim 10, wherein the orchestrator is further configured to: divide the execution of the service into a plurality of tasks, wherein each task is executable on an MEC node; and select a subset of the MEC node pool for each of the plurality of tasks according to a selection function. 12 . The MEC distributed controller according to claim 11 , wherein the MEC node pool is determined according to one of a user account level of the mobile device or an account level of an owner of an application associated with the service.

13. According to the MEC distributed controller according to claim 11, the orchestrator is further configured to: generate a cost and a value for each MEC node in the MEC node pool for executing each of the multiple tasks on the MEC node; and select an MEC node from the MEC node pool for executing the task for each of the multiple tasks, the selection being performed based on the cost and the value for executing the task on the MEC node, thereby generating the subset of the MEC node pool.

14. The MEC distributed controller according to claim 13, wherein the orchestrator is further configured to assign a release time and a deadline to the selected subset of the MEC node pool.

15. The MEC distributed controller according to any one of claims 13 to 14, wherein the orchestrator is further configured to provide application data associated with the execution of the service to the selected subset of the MEC node pool, wherein the application data is provided according to the release time and the deadline.

16. The MEC distributed controller according to any one of claims 10 to 14, wherein the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or a plurality of MEC nodes that the execution plan is expected to cover; and the geographic location information includes at least a route of the mobile device.

17. A multi-access edge computing (MEC) distributed controller, comprising: Non-transitory memory, including instructions; and one or more processors in communication with the memory; wherein the one or more processors execute the instructions to cause the MEC distributed controller to: receiving an MEC computing task request from a mobile device, the MEC computing task request being used to request a computing node that supports execution of a service on an MEC node controlled by the MEC distributed controller; obtaining geographic location information associated with the mobile device; Determining an execution plan and an MEC node pool for executing the service, wherein the determining is performed based on the geographic location information associated with the mobile device; Scheduling the execution plan on the MEC node pool; Deploying the scheduled execution plan; updating the geographic location information of the mobile device based on at least one of traffic information or emergency information; Determining an updated execution plan and an updated MEC node pool according to the updated geographic location information; Scheduling the updated execution plan on the updated MEC node pool to generate an updated scheduling execution plan; as well as A scheduled execution plan is deployed to deploy the update.

18. The MEC distributed controller according to claim 17, wherein the instructions further cause the MEC distributed controller to: divide the execution of the service into a plurality of tasks, each of which is executable on an MEC node; and select a subset of the MEC node pool for each of the plurality of tasks according to a selection function.

19. The MEC distributed controller according to claim 18, wherein the MEC node pool is determined according to one of a user account level of the mobile device or an account level of an owner of an application associated with the service.

20. The MEC distributed controller according to claim 19, wherein the instructions further cause the MEC distributed controller to: generate, for each MEC node in the MEC node pool, a cost and a value for executing each of the multiple tasks on the MEC node; and select, from the MEC node pool, a MEC node for executing the task for each of the multiple tasks, wherein the selection is performed based on the cost and the value for executing the task on the MEC node, thereby generating the subset of the MEC node pool.

21. The MEC distributed controller according to claim 20, wherein the instructions further cause the MEC distributed controller to: assign a release time and a deadline to the selected subset of the MEC node pool.

22. The MEC distributed controller according to any one of claims 20 to 21, wherein the instruction further causes the MEC distributed controller to provide application data associated with the execution of the service to the selected subset of the MEC node pool, wherein the application data is provided based on the release time and the deadline.

23. The MEC distributed controller according to any one of claims 17 to 21, wherein the MEC computing task request includes at least one of the following: a service account, a mobile device user identifier, or a plurality of MEC nodes that the execution plan is expected to cover; and the geographic location information includes at least a route of the mobile device.

Images