A method for supporting adaptive offloading of multiple IoT applications in edge environments

Abstract

The present invention relates to a method for supporting adaptive unloading of multiple IoT applications in an edge environment, including: constructing an application program that conforms to a general program structure that supports on-demand computing unloading; for an application program that conforms to a general program structure that supports on-demand computing unloading, extracting a program fragment flow chart through static code analysis to provide internal process information of the program for the generation of an unloading solution; analyzing the surrounding MEC environment and the application program through an unloading solution generation algorithm based on a multi-task particle swarm optimization algorithm of a genetic algorithm operator to obtain an optimal unloading solution; the application program performs computing unloading with service as the granularity according to the unloading solution, and minimizes the system overhead while satisfying the deadline constraints of each application. The method supports computing unloading of different types of applications in an MEC environment and minimizes the system overhead generated by computing unloading.

Description

Technical Field

[0001] The present invention belongs to the technical field of Internet of Things, and in particular relates to a method for supporting adaptive unloading of multiple Internet of Things applications in an edge environment. Background Art

[0002] The rapid development of the Internet of Things (IoT) and IoT devices has led to the emergence of a variety of resource-intensive IoT applications, such as face recognition, speech semantic analysis, interactive games, and augmented reality. Due to limitations in processing power, memory capacity, and battery capacity, most resource-intensive IoT applications cannot be run directly on IoT devices.

[0003] Computation offloading is an effective way to address the resource constraints of IoT devices. In particular, the proposal of mobile cloud computing (MCC) offloads all or part of the computing tasks to cloud servers that provide huge storage and computing resources. More specifically, applications are divided at a certain granularity, and then some of the computationally intensive tasks are offloaded to the cloud for execution, while other simple tasks are processed locally to reduce the response time of the application.

[0004] However, the distance between IoT devices and cloud servers is relatively far, which may cause significant execution delays. In addition, large amounts of data transmission may cause traffic congestion in the core network. To solve the above problems, mobile edge computing (MEC) is introduced. Mobile edge provides computing power and storage resources that are superior to IoT devices and is closer to IoT devices, which can significantly reduce latency.

[0005] Offloading intensive tasks to cloud servers or edge servers can indeed reduce the computing and storage pressure of IoT devices. However, the diversity of application types and the complex and changing runtime environment in MEC make it very difficult to implement computing offloading in MEC. In addition, how to solve the expensive overhead caused by computing offloading is also an issue that cannot be ignored. Specifically, there are the following challenges:

[0006] Challenge 1: Enabling mechanism. For IoT applications of various types, it is a challenge to design a universal method to decouple different types of strongly coupled monolithic applications into different functional modules and support on-demand computing offloading.

[0007] Challenge 2: Offloading decision. In MEC, computing resources are scattered across IoT devices, edge servers, and cloud servers. The performance of resources on different computing platforms varies significantly. Different applications will compete for resources during execution. In such a complex and changing network environment, how to obtain a suitable offloading strategy that minimizes monetary costs while meeting the deadline of each application is another challenge.

[0008] Most of the previous research focused on solving the computation offloading of Android applications. The development of DNN has led more people to shift their focus to how to offload DNN. However, these studies can only target specific types of applications and are not universal. Moreover, they all focus on the computation offloading problem under a single application and cannot fully utilize the distributed and changing computing resources in the MEC environment. Summary of the invention

[0009] The object of the present invention is to provide a method for supporting adaptive offloading of multiple IoT applications in an edge environment, which supports computing offloading of different types of applications in a MEC environment and minimizes the system overhead generated by computing offloading.

[0010] To achieve the above purpose, the technical solution adopted by the present invention is: a method for supporting adaptive offloading of multiple IoT applications in an edge environment, comprising:

[0011] Building applications that conform to a common program structure that supports on-demand compute offload;

[0012] For applications that conform to the general program structure that supports on-demand computing offloading, the program fragment flow chart is extracted through static code analysis to provide the program's internal process information for the generation of offloading solutions;

[0013] The optimal offloading solution is obtained by analyzing the surrounding MEC environment and applications through the offloading solution generation algorithm of the multi-task particle swarm optimization algorithm MPSO-GA based on the genetic algorithm operator;

[0014] The application offloads computations at the service granularity according to the offloading scheme, minimizing the system overhead while meeting the deadline constraints of each application.

[0015] Furthermore, a general program structure supporting on-demand computing and offloading is designed by supporting a design pattern that supports the separate deployment and execution of different types of application programs in modules. The design pattern satisfies the following requirements: each module of the application program can be independently deployed and executed on different computing nodes; the module can determine the computing node where the module or database to be called is located to ensure the validity of the call; the called module can receive the input of the calling module and return the correct execution result;

[0016] There are two types of services in applications that conform to the design pattern: one is a pure service: it uses local data and does not need to call other services; the other is a composite service: it relies on data from other services and needs to call other services; the composite service mainly includes the following properties:

[0017] (1) Key-value data Params / result: All external variables required by the called service during execution are passed in through Params, that is, there is no statement in the service to access external variables; when the service needs to modify external variables, it is passed out through result; the external variables refer to variables accessed during the service execution and defined outside the service;

[0018] (2) String seq: A string seq is maintained in the application to record a call path from the current service to the main service. To maintain the seq, the seq is passed in as a parameter when the service is called, and the name of the called service is added to the seq.

[0019] (3) Invoke function: The composite service calls other services through the Invoke function. Invoke implements two functions: a) Control forwarding: Determine whether the service is executed locally or remotely, and if it is a remote call, on which computing node to call the service; b) Data transmission: Serialize all parameters required by the called service and deserialize the returned service execution results;

[0020] (4) Call function: The service establishes a connection with the database through the Call function; the Call function determines the location of the database through the name of the database to be interacted with, and returns the connection channel for transmitting data with the database to ensure normal data interaction between the service and the database.

[0021] Furthermore, the offloading scheme generation algorithm describes the application offloading problem in the MEC environment from three aspects: network model, application model and performance model, and solves the application offloading problem through the MPSO-GA algorithm;

[0022] The network environment includes a cloud server CS, multiple edge servers ES, and multiple IoT devices DS. The MEC environment is modeled as a graph G = (N, E) including a set of computing nodes N = {n1, n2, ..., n w}, and use set E to represent the connections between them; the computing nodes use Indicates that, where ψ i Represents computing node n i The computing power of each node is assumed to be able to meet the corresponding demand; i Represents node n i The maximum number of tasks that can be executed is equal to the number of cores of the node; Indicates the use of computing node n i The computation cost per second; expressed in e i,j Indicates n i and nj The connection between them is related to the bandwidth v i,j And the minimum link delay rtt i,j Related, and Use to represent node n i and n j The transmission overhead per second between them;

[0023] Assume that there is a system that will execute for θ time during the uninstallation process; there are multiple applications A from IoT devices in the system = {a1, a2, ..., a g}, and application a i μ i Each application executes ξ in the time interval θ. i =θ / μ i times, and use dl i Indicates application a i Deadline; each application complies with the general program structure; the application is modeled as a program fragment flow chart Flow i =(D i ,S i ,P i ,Q i );

[0024] In order to calculate the application response time and money cost, a corresponding service and database offloading solution is built; Indicates application a i The deployment location of the service in; for each program fragment The execution location depends on the service The deployment location, i.e. Indicates application a i The deployment location of the database in

[0025] In application a i No. i During the execution, use Represents an execution program fragment The time when the task reaches the computing node; the time when the fragment actually starts to execute is represented by represents the waiting time of the fragment in the queue on the node, then:

[0026]

[0027] Precursor fragment Passing data to a program snippet The resulting data transfer time is as follows:

[0028]

[0029] Program snippets Occupied Node Time By its own task execution time and data transfer time between different databases during execution composition, The calculation is as follows:

[0030]

[0031]

[0032] The end moment That is, the start time plus the time at the node The occupation time is calculated as follows:

[0033]

[0034] Application i No. i The start time of the next execution is the first program fragment that executes the main service Mission arrival time The end time is the last segment of the main service Time to complete execution Then application a i No. i Response time of each execution The calculation is as follows:

[0035]

[0036] Program snippets On the compute node During execution, the usage overhead generated by occupying the node is calculated as follows:

[0037]

[0038] Program snippets During execution, the transmission overhead of incoming data and interaction with the database is calculated as follows:

[0039]

[0040] Serve The monetary cost of being called and executed once That is, the sum of the usage overhead and transmission overhead of all program fragments it contains, calculated as follows:

[0041]

[0042] Application i The money cost of executing once MC(a i ) is the sum of the monetary cost of all services multiplied by the number of times they are called, calculated as follows:

[0043]

[0044] The optimization goal of the offloading solution generation algorithm is to obtain an offloading solution for services and databases to minimize the total monetary cost under the condition that the response time of each application in the time period θ satisfies the time constraint; the formal definition of the final application offloading problem is as follows:

[0045]

[0046] Furthermore, the specific implementation method of the unloading scheme generation algorithm of the multi-task particle swarm optimization algorithm based on the genetic algorithm operator is:

[0047] The encoding strategy of the uninstallation scheme generation algorithm meets the following three principles:

[0048] Completeness: Every candidate solution in the problem space can be encoded into a corresponding coded particle;

[0049] Non-redundant: Each candidate solution in the problem space corresponds to only one encoding particle;

[0050] Survivability: Each coding particle in the coding space can correspond to a candidate solution in the problem space;

[0051] The encoding strategy uses particle Z to represent the candidate solutions for cost-driven offloading of all services and databases in the MEC environment, where the i-th particle at the t-th iteration is described as (12):

[0052]

[0053]

[0054] Where p and q represent the total amount of services and databases in the entire system respectively; in formula (13), Represents computing node n j The kth service is deployed on the i-th particle at the t-th iteration, Represents computing node n j Deploy the kq-th database to the i-th particle at the t-th iteration;

[0055] Each coding bit of a particle represents the deployment location of the corresponding service or database, which satisfies the completeness principle. Different coding particles represent different offloading schemes. A feasible solution in the problem space corresponds to only one coding particle in the coding space, so it satisfies the non-redundancy principle. However, some candidate solutions corresponding to the particles may not meet the deadline constraint, which means that the response time of some applications exceeds the time limit. Therefore, the survivability principle is not met. All particles are divided into two categories:

[0056] Feasible particle: Under the uninstallation strategy corresponding to the particle, each application meets the deadline constraint;

[0057] Infeasible particle: Under the unloading strategy corresponding to the particle, at least one execution of the application cannot meet the deadline constraint;

[0058] In order to compare different particles, the fitness function is used for measurement; particles with smaller fitness represent better candidate solutions; because some solutions may make the application response time exceed the specified deadline, they are divided into the following three cases for comparison:

[0059] Case 1: One particle is a feasible solution and the other particle is an infeasible solution. In this case, the feasible solution is selected and its fitness function is defined as:

[0060]

[0061] Case 2: Both particles are infeasible solutions; the particle with the smaller sum of the deadline time difference is selected because it is closer to the feasible solution and is more likely to become a feasible solution in subsequent evolution; its fitness function is defined as:

[0062]

[0063] Case 3: Both particles are feasible solutions; the particle with lower monetary cost is selected, and its fitness function is defined as:

[0064]

[0065] Furthermore, the implementation process of the MPSO-GA algorithm is as follows:

[0066] Step S1: Initialize the relevant parameters of the MPSO-GA algorithm, including the initial population size δ, the maximum number of iterations iters max , maximum inertia weight ε max , minimum inertia weight ε min , the starting and ending values ​​of the acceleration coefficient and Then, randomly generate the initial total;

[0067] Step S2: Calculate the fitness of each particle according to formulas (14) to (16); select the optimal solution of each particle itself, and select the particle with the best fitness as the global optimal solution in the current generation;

[0068] Step S3: Update each particle according to formula (13) and recalculate the fitness of each new particle;

[0069] Step S4: Update the personal best particle of each particle; if there is a better solution than the original particle, the global best particle will be updated;

[0070] Step S5: If the iteration stop condition is met, the algorithm ends; otherwise, return to step S3 to continue iteration.

[0071] Compared with the prior art, the present invention has the following beneficial effects: a method for supporting adaptive offloading of multiple IoT applications in an edge environment is provided, the method constructs an application that conforms to a general program structure that supports on-demand computing offloading, and extracts a program fragment flowchart for the application that conforms to this structure through static code analysis; then the program fragment flowchart and context are analyzed through an offloading scheme generation algorithm based on a multi-task particle swarm optimization algorithm of a genetic algorithm operator to obtain the optimal offloading scheme; finally, each application performs computing offloading at the granularity of service according to the offloading scheme, and minimizes the overhead while meeting the deadline constraints of each application. The method supports computing offloading of different types of applications at the granularity of service, and compared with other classic methods, it can save 2.11 to 17.51% of system costs while meeting the deadline constraints. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Figure 1 is a schematic diagram of a method implementation principle of an embodiment of the present invention;

[0073] Figure 2 is a schematic diagram of a design pattern supporting on-demand computing and offloading in an embodiment of the present invention;

[0074] Figure 3 These are two types of services included in the application in the embodiment of the present invention;

[0075] Figure 4 is a schematic diagram of application analysis in an embodiment of the present invention;

[0076] Figure 5 is a schematic diagram of a coded particle of an unloading scheme in an embodiment of the present invention;

[0077] Figure 6 is a schematic diagram of a mutation operation in an embodiment of the present invention;

[0078] Figure 7 is a schematic diagram of a crossover operation in an embodiment of the present invention;

[0079] Figure 8 is a flow chart of the implementation of the MPSO-GA algorithm in an embodiment of the present invention;

[0080] Fig. 9 is a schematic diagram of application execution in different scenarios in an embodiment of the present invention;

[0081] Fig.10 is a schematic diagram of a comparison of the response time of an application program in an embodiment of the present invention;

[0082] Fig.11 is a schematic diagram of an application scenario in an embodiment of the present invention;

[0083] Fig.12 is the system cost of different offloading strategies under different deadline constraints in a simple network environment in an embodiment of the present invention;

[0084] Fig.13 is the system cost of different offloading strategies under different deadline constraints in a complex network environment in an embodiment of the present invention. DETAILED DESCRIPTION

[0085] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0086] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

[0087] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof.

[0088] like Figure 1 As shown, this embodiment provides a method for supporting adaptive offloading of multiple IoT applications in an edge environment, including:

[0089] 1. Build applications that conform to a common program structure that supports on-demand computing offload.

[0090] 2. For applications that conform to the general program structure that supports on-demand computing offloading, extract the program fragment flow chart through static code analysis to provide the program's internal process information for the generation of the offloading solution.

[0091] 3. The surrounding MEC environment and applications are analyzed through the offloading scheme generation algorithm of the multi-task particle swarm optimization algorithm MPSO-GA based on the genetic algorithm operator to obtain the optimal offloading scheme.

[0092] 4. The application performs computation offloading at the service granularity according to the offloading scheme, minimizing the system overhead while meeting the deadline constraints of each application.

[0093] 1 Method Overview

[0094] Figure 1 The implementation principle of this method is shown. Figure 1 In the nodes, we use circles to represent different types of operation data and squares to represent algorithms. This method mainly consists of two parts: the upper part represents the offloading enabling mechanism and the lower part represents the offloading scheme generation algorithm.

[0095] The offloading enabling mechanism is the key part that enables applications to offload computing. This method designs a universal design pattern that supports on-demand computing offloading and proposes a corresponding program structure. Applications that conform to this program structure can be decoupled into multiple services, and different services can be distributed and executed on different computing nodes (including IoT devices, cloud, and edge). During the execution process, the application determines the specific computing node based on the configuration file, thereby realizing on-demand unloading of the program. In addition, the application can obtain a program fragment flow chart through static code analysis to support the generation of subsequent unloading strategies.

[0096] The offloading solution generation algorithm obtains the optimal offloading solution by analyzing the surrounding MEC environment and applications. This method formally defines the application offloading problem to be optimized by establishing a system model, an application model, and a performance model. And through the MPSO-GA algorithm, an offloading solution for services and databases is generated, so that each application minimizes the overall monetary cost while meeting the cutoff constraints.

[0097] 2 Uninstallation Mechanism

[0098] 2.1 Design Patterns

[0099] Since traditional monolithic applications cannot be split, they can only be executed on IoT devices or remote servers as a whole. In order to realize on-demand computing offloading of applications, this method proposes a design pattern that supports the separate deployment and execution of different types of applications in modules to design a general program structure that supports on-demand computing offloading. The design pattern meets the following properties:

[0100] (1) Independence: Each module of the application can be independently deployed and executed on different computing nodes.

[0101] (2) Validity: The module can determine the computing node where the module or database to be called is located to ensure the validity of the call.

[0102] (3) Correctness: The called module can receive the input of the calling module and return the correct execution result.

[0103] The present invention proposes an application design pattern to meet the above properties, such as Figure 2 As shown in the figure. This pattern regards the application as a main service composed of multiple loosely coupled, collaborative and interconnected services. Each service will not affect other services during execution to ensure that the services can be deployed and executed independently on the computing nodes. Services must call services or databases through controllers. The controller is responsible for confirming the deployment location of the service or database and supporting data transmission to ensure that the service can be carried out correctly and effectively.

[0104] 2.2 Program Structure

[0105] In this approach, we propose a program structure for applications that meets Figure 2 There are two types of services in applications that conform to the design pattern: one is a pure service: this service uses local data and does not need to call other services (such as Figure 3 (a)); the other is a composite service: it relies on data from other services and needs to call other services (such as Figure 3 (b)). The service mainly includes the following attributes:

[0106] (1) Params / result (key-value data): All external variables required by the called service during execution are passed in through Params, that is, there is no statement in the service to access external variables. When the service needs to modify external variables, it is passed out through result. Among them, external variables refer to variables that are accessed during the service execution and defined outside the service. Therefore, each service is stateless, thus ensuring the independence of the service.

[0107] (2) seq (string type): A string seq is maintained in the application to record a call path from the current service to the main service. To maintain seq, when the service is called, seq is passed in as a parameter and the name of the called service is added to seq.

[0108] (3) Invoke (function): The composite service needs to call other services through the Invoke function. Invoke needs to implement two functions: (1) Control forwarding: Determine whether the service is executed locally or remotely, and if it is a remote call, on which computing node to call the service. (2) Data transmission: Serialize all parameters required by the called service and deserialize the returned service execution results. The pseudo code of the Invoke function is shown in Algorithm 1:

[0109]

[0110] First, the calling path from the service to be called to the main service is determined through seq and serviceName, and the location address of the service execution is determined from the configuration file SP based on the calling path. SP stores the deployment locations of different services (line 2). If address is equal to Local, the service is directly executed locally through the local function and the result is returned. Note that Local here means the computing node where the service is called. (Lines 3 to 6), if address is not equal to Local, the service is called through the remote function. i 、Parameter i and seq are sent to the agent on the remote node, and the remote agent implements the service through the reflection mechanism i Make a call and return the result. (Lines 7 to 9)

[0111] (4) Call (function): The service should establish a connection with the database through the Call function. The Call function determines the location of the database through the name of the database to be interacted with, and returns the connection channel for transmitting data with the database, thereby ensuring normal data interaction between the service and the database. The details are shown in Algorithm 2:

[0112]

[0113] First, the deployment location host of the database is determined from the configuration file DP, according to DatabaseName i (Line 2), DP stores different database deployment locations. Then, through host and database, the corresponding user and password are obtained from the Account that records the database name and password (Lines 3-4). Finally, a data transmission channel is established and the channel is returned (Lines 5-6).

[0114] In summary, “Params i " and "result i" ensures the independence of the service, and the controller composed of "seq", "Invoke" and "call" ensures the validity and correctness of the service calling other services and databases during execution.

[0115] 2.3 Application Analysis

[0116] In order to provide the internal process information of the program for the subsequent generation of the uninstallation solution, it is necessary to analyze it. The present invention extracts the program fragment flow chart through static code analysis, and its implementation method is:

[0117] First, we need to determine what to uninstall, that is, the number of services and databases in the application. According to the provisions in 2.2, the database is uniquely identified by the name, and the service is uniquely identified by its call path to the main service. Secondly, we need to evaluate the uninstallation scheme. This method further divides the service into atomic program fragments and records the execution order between the fragments. Finally, this method models the application as a program fragment flow chart. Figure 4 For application analysis examples. Figure 4 The solid line represents the decomposition of the service into program fragments, the dashed line represents an execution process within the service, and the dotted line represents the actual execution process of the program fragments in the application.

[0118] The program fragment flowchart of the i-th application uses the symbol Flow i =(D i ,S i ,P i ,Q i ) indicates. Among them, Represents a collection of databases in an application and uses Represents a database The name of the Represents a collection of services in an application and uses Indicates service name, Indicates that from the service To the main service A call path of Indicates service The total number of calls. Due to the existence of service calls, each service will be divided into multiple serial code fragments during the actual execution process, namely P i It is a set that records the order in which actual program fragments are executed. The program fragments in the set can be repeated. The order in which program fragments are added to the set is the order in which they are actually executed in the application. For two adjacent fragments, this method calls the previous fragment the predecessor fragment of the next fragment. i Represents a collection of records of associations between program fragments and databases, where express During execution, the database There is interaction between them.

[0119] A code snippet is defined as a triple in, Indicates the incoming fragment The amount of data; Representation fragment The amount of tasks; Representation fragment During execution, the database The total amount of interaction data. If there is no interaction, it is set to 0. (Since the specific information prediction of program fragments is not the research content of this method, the application developer needs to provide it in json format)

[0120] This method uses static code technology to analyze the locations of invoke functions and call functions in the source code, and then obtains the program fragment flow chart of application i. i =(D i ,S i ,P i ,Q i ), and the pseudo code is shown in Algorithm 3.

[0121] Algorithm 3 takes the source code of the ith application and the service name of the main service as input to construct the corresponding program fragment flowchart. The specific steps are as follows: First, assign the information of the main service to and through Extract the corresponding statement set Corresponding to lines 31 to 32. Then, to the empty set S i Add the main service And D i , P i and Q i Set to empty, corresponding to line 33. Finally, call the getFlow() function to recursively build the program fragment flow chart, corresponding to line 34. The getFlow() function steps correspond to lines 1 to 30. and As the input of the function, they represent the service currently being analyzed and the set of statements corresponding to the service. In line 2, pId is used to record the number of the current program fragment, which is initially set to 1, and the current program fragment is join in and P i For each statement in the statement set, do the following: Get the statement The keywords in the table correspond to line 4. If the keywords contain the keyword 'invoke', the call path callSeq is used to determine whether the called service has appeared before. If so, the call count is increased by 1. If not, S is added. i , and get the corresponding statement set through the service name, corresponding to lines 5-14. Line 15, update pId, and change the current new program fragment join in and P i In line 16, for service Perform getFlow() recursion. If the statement The keyword in the keyword contains the keyword 'call'. Similarly, first determine the database Is it already in set D? i If not, add it. Then, judge Is it in set Q i If not, add it, corresponding to lines 18-29.

[0122]

[0123] 3 Uninstallation Scheme Generation Algorithm

[0124] The offloading scheme generation algorithm describes the application offloading problem in the MEC environment from three aspects: network model, application model and performance model. The network model describes the "network environment of the application"; the application model defines "multiple applications to be offloaded that conform to the program structure proposed by this method"; the performance model corresponds to the "content attempted to be optimized" (introduced in 3.1, 3.2 and 3.3 respectively); then, the problem to be solved by this method is described based on the above three models (Section 3.4); finally, the application offloading problem is solved by the MPSO-GA algorithm (Section 3.5).

[0125] 3.1 Network Model

[0126] The network environment includes a cloud server (CS), multiple edge servers (ES), and multiple IoT devices (DS). We model the MEC environment as a graph G = (N, E) including a set of computing nodes N = {n1, n2, ..., n w}, and use set E to represent the connections between them. The computing nodes use Indicates that, where ψ i Represents computing node n i The computing power is usually measured by CPU. Since the focus of this study is to find an offloading solution, we assume that the storage capacity of each node can meet the corresponding demand. i Represents node n iThe maximum number of tasks that can be executed, its value is equal to the number of cores of the node; Indicates the use of computing node n i The computation cost per second. i,j Indicates n i and n j The connection between them is related to the bandwidth v i,j And the minimum link delay rtt i,j Related, and Use to represent node n i and n j The transmission overhead per second between them.

[0127] 3.2 Application Modeling

[0128] Assume that there is a system that will execute for θ time during the offloading process. There are multiple applications A from IoT devices in the system = {a1, a2, ..., a g}, and apply a i μ i Therefore, each application executes ξ in the θ time period. i =θ / μ i times, and use dl i Indicates application a i Each application complies with the program structure proposed by this method. According to 2.3, the application is modeled as a program fragment flow chart Flow i =(D i ,S i ,P i ,Q i ).

[0129] 3.3 Performance Modeling

[0130] In order to calculate the application response time and monetary cost, a corresponding service and database offloading scheme must be specified. Indicates application a i The deployment location of the service in. For each program fragment The execution location depends on the service The deployment location, i.e. Indicates application a i The deployment location of the database in .

[0131] 3.3.1 Application Response Time

[0132] In application a i No. i During the execution, use Represents an execution program fragment The time when the task reaches the computing node. The time when the fragment actually starts to execute is expressed as represents the waiting time of the fragment in the queue on the node, then:

[0133]

[0134] Precursor fragment Passing data to a program snippet The resulting data transfer time is as follows:

[0135]

[0136] Program snippets Occupied Node Time By its own task execution time and data transfer time between different databases during execution composition, The calculation is as follows:

[0137]

[0138]

[0139] The end moment That is, the start time plus the time at the node The occupation time is calculated as follows:

[0140]

[0141] Application i No. i The start time of the next execution is the first program fragment that executes the main service Mission arrival time The end time is the last segment of the main service Time to complete execution Therefore, application a i No. i Response time of each execution The calculation is as follows:

[0142]

[0143] 3.3.2 Monetary cost of application

[0144] Program snippets On the compute node During execution, the usage overhead generated by occupying the node is calculated as follows:

[0145]

[0146] Program snippets During execution, the transmission overhead of incoming data and interaction with the database is calculated as follows:

[0147]

[0148] Serve The monetary cost of being called and executed once That is, the sum of the usage overhead and transmission overhead of all program fragments it contains, calculated as follows:

[0149]

[0150] Application i The money cost of executing once MC(a i ) is the sum of the monetary cost of all services multiplied by the number of times they are called, calculated as follows:

[0151]

[0152] 3.4 Problem Statement

[0153] The ultimate optimization goal of this method is to obtain a service and database offloading solution to minimize the total monetary cost while satisfying the time constraint for the response time of each application within the time period θ. The final formal definition of the application offloading problem is as follows:

[0154]

[0155] 3.5MPSO-GA Algorithm

[0156] For the offloading schemes SP and DP, the aim is to explore the optimal mapping from services and databases to different computing nodes, minimizing the total monetary cost while satisfying the deadline constraints of each application. Exploring the optimal mapping from services and databases to computing nodes has been proven to be an NP-hard problem. Traditional PSO has been widely used to solve continuous optimization problems, while the optimal mapping of services and databases to computing nodes is a discrete problem that requires a new encoding method. In addition, in order to avoid the premature convergence of the traditional particle swarm algorithm, a suitable particle update strategy needs to be introduced. In response to the above shortcomings of the traditional PSO algorithm, this method proposes the MPSO-GA algorithm to explore the optimal offloading strategy for multiple tasks in the MEC environment. The application offloading strategy based on MPSO-GA is described as follows.

[0157] (1) Question coding

[0158] A good coding strategy can improve the search efficiency and performance of the PSO algorithm. The coding strategy of this algorithm meets the following three principles:

[0159] Definition 1 (Completeness): Every candidate solution in the problem space can be encoded into a corresponding encoded particle.

[0160] Definition 2 (non-redundant): Each candidate solution in the problem space corresponds to only one encoding particle.

[0161] Definition 3 (Survivability): Every coding particle in the coding space can correspond to a candidate solution in the problem space.

[0162] It is difficult for conventional coding strategies to satisfy these three principles simultaneously. This method uses particle Z to represent the candidate solutions for cost-driven offloading of all services and databases in the MEC environment, where the i-th particle at the t-th iteration is described as (12):

[0163]

[0164]

[0165] Where p and q represent the total amount of services and databases in the entire system respectively. In formula (13), Represents computing node n j The kth service is deployed on the i-th particle at the t-th iteration, Represents computing node n j Deploy the kq-th database to the i-th particle at the t-th iteration.

[0166] Property 1: This coding strategy can satisfy both integrity and non-redundancy, but may not satisfy survivability.

[0167] Each encoding bit of a particle represents the deployment location of the corresponding service or database, satisfying the completeness principle. Different encoding particles represent different offloading schemes. A feasible solution in the problem space corresponds to only one encoding particle in the encoding space, thus satisfying the non-redundancy principle. However, some candidate solutions corresponding to the particles may not meet the deadline constraints, which means that the response time of some applications exceeds the time limit, thus not satisfying the survivability principle. In this method, all particles can be divided into two categories: feasible particles and infeasible particles, which are defined as follows.

[0168] Definition 4: (Feasible particle): Under the offloading strategy corresponding to the particle, each application can meet the deadline constraint.

[0169] Definition 5: (Infeasible particle): Under the offloading strategy corresponding to the particle, there is at least one execution of the application that cannot meet the deadline constraint.

[0170] (2) Fitness function

[0171] In order to compare different particles, a fitness function is needed to measure them. Generally, particles with smaller fitness represent better candidate solutions. This work seeks to obtain an offloading solution that minimizes the total monetary cost while satisfying the deadline constraints of each application. Therefore, particles with lower monetary cost can be considered better solutions. Since some solutions may cause the response time of the application to exceed the specified deadline, we divide them into the following three cases for comparison:

[0172] Case 1: One particle is a feasible solution and the other particle is an infeasible solution. In this case, the feasible solution is selected, and its fitness function is defined as:

[0173]

[0174] Case 2: Both particles are infeasible solutions. The particle with the smaller sum of the cutoff time difference is selected because it is closer to the feasible solution and is more likely to become a feasible solution in subsequent evolution. Its fitness function is defined as:

[0175]

[0176] Case 3: Both particles are feasible solutions. The particle with lower monetary cost is selected, and its fitness function is defined as:

[0177]

[0178] (3) Update strategy:

[0179] Traditional particle swarm optimization has three main parts: inertia, individual cognition, and social cognition. The iterative update of each particle is affected by its personal best position and the global best position of the current generation. Falling into the local optimum too early is a major defect of the particle swarm optimization algorithm. In order to improve the search ability of the algorithm, this method introduces the crossover operator and mutation operator of the genetic algorithm to update the particles. The iterative update of the i-th particle in the t+1th iteration is shown in formula (17):

[0180]

[0181] Among them, F u () indicates mutation operation, F g () and F p () indicates the crossover operation, ε is the inertia weight. σ p and σ g is the acceleration coefficient. φ u ,φ p and φ g is a random number in the interval [0,1].

[0182] For the inertial part, the velocity of the particle is defined as:

[0183]

[0184] Among them, M u () represents the mutation operator, and ε represents the threshold for mutation. u When it is less than ε, the mutation operation is performed. First, a position ind1 in the particle is randomly selected, and then a computing node is randomly selected to replace the computing node originally mapped on ind1. Figure 6 Depicted is the mutation operator which randomly selects position ind1 and changes the mapped compute node from 2 to 3.

[0185] Property 2: The mutation operator can change a particle from feasible to infeasible, and vice versa.

[0186] The formulas for individual cognition and social cognition in particle updating are as follows:

[0187]

[0188]

[0189] Among them, C p () indicates a crossover operation, represents the optimal historical particle of the i-th individual in the t-th iteration, gBest t represents the best historical particle among all particles in the tth iteration, σ p (σ g ) represents the threshold of individual crossover (social crossover). When the random number φ p (φ g ) is less than the threshold σ p (σ g ) when performing a crossover operation. Figure 7 Depicts an example of a crossover operation, where first the positions ind1 and ind2 in the old particle are randomly selected, and then combined with (or gBest t ) replaces the position of the old particle and finally obtains a new particle.

[0190] Property 3: A particle can change from infeasible to feasible after passing through the crossover operator, and vice versa.

[0191] (4) Mapping of particles to unloading results

[0192] For a particle, it is necessary to calculate the execution time of each application under its corresponding unloading scheme and the total monetary cost. Therefore, this method proposes an evaluation algorithm to map particles to unloading results. The idea of ​​the evaluation algorithm is to simulate the actual execution process of program fragments, calculate the start execution time and execution completion time of each program fragment, and thus calculate the response time and total monetary cost of each application under the scheduling scheme.

[0193] First, set a variable curTime to represent the current time and initialize it to 0. The input service and database offloading plans are SP and DP respectively. Use the symbol λ i Indicates the number of times the application is currently executed, with an initial value of 1. For each program fragment Define three properties and They represent the time when the task of executing the fragment arrives, the time when the fragment is completed, and the remaining execution time of the fragment. They are initialized as follows:

[0194]

[0195] Then, the response time and money cost of each application execution can be calculated by formulas (6) and (10) in 3.2.3. Algorithm 4 introduces the main steps of the evaluation algorithm:

[0196]

[0197] Algorithm 4 takes the uninstallation plan and the application flow chart as input, and finally obtains the execution time of each application and the total monetary cost of the system. The specific steps are as follows:

[0198] Step 1 (lines 2 to 10): Fill the channel. According to the offloading plan, add each program fragment to the computing node in order until there are no empty channels on the computing node (using n i .empty represents node n i The number of remaining channels, whose initial value is ω i ). The program fragment placed in the channel must satisfy the condition that the task executing the program fragment has arrived at the computing node at the current time, that is,

[0199] Step 2 (lines 12 to 18): Find the minimum time slice. First, traverse the program fragments being executed on each computing node and find the shortest remaining execution time. Assign it to the time slice slice. Then, add slice to the current time curTime, indicating that the time of length slice has passed.

[0200] Step 3 (lines 20 to 34): Calculate the remaining time of the program fragment. Subtract the time slice slice, which means the execution time is slice length. 0, indicating that the program fragment has been executed and its end time Then, the fragment is removed from the channel and the number of idle channels of the node is set to n. i .empty plus 1. If it is not the last fragment, then from P i Get the next program fragment to be executed And the time when its task arrives The time when curTime and data are passed in If the program fragment is P i If the last fragment of the program is executed and the current execution count is less than the total execution count, it means that the application program has finished executing and entered the next execution. Take the maximum value between the ideal trigger time and the current time.

[0201] Repeat the above steps until each application a i All executed i Finally, the response time of each application execution can be calculated by formulas (6) and (10): and money expenditure MC(a i ).

[0202] (5) Parameter setting

[0203] The inertia weight ε may greatly affect the search ability and convergence of the PSO algorithm. The larger the ε value, the stronger the global search ability, while the smaller the ε value, the stronger the local search ability. The classic inertia weight adjustment method is as follows:

[0204]

[0205] where ε max and ε min They represent the maximum and minimum values ​​of the initialization ε setting, iters cur and iters max They represent the current algorithm iteration number and the maximum iteration number set by initialization respectively.

[0206] However, the change of ε in the classic update strategy is only related to the number of iterations, and cannot adapt well to the nonlinear characteristics of the minimum monetary cost under multi-task. Therefore, this method designs a discrete adjustment method based on the quality of the current population particles to adjust the inertia weight ε, as shown below:

[0207]

[0208]

[0209] in Represents the i-th particle in the current t-1th iteration and the global optimal solution gBest of the t-1th iteration t-1 The difference between i is an astatistical factor, when τ j When the value is 1, it means and gBest t-1 The computing nodes mapped on the jth code are the same, otherwise the value is 0. Therefore, the search ability of the algorithm can be adaptively adjusted according to the difference between the current and global optimal particles.

[0210] In addition, the two cognitive factors σ of the algorithm p and σ g The linear increase and decrease strategy is used for setting

[24] , which is similar to formula (22). and Respectively represent the parameters σ p and σ g The initial value of the iteration, and Respectively represent the parameters σ p and σ g The final value of the iteration.

[0211] (6) MPSO-GA algorithm flow

[0212] Figure 8 The flowchart of the proposed MPSO-GA algorithm is depicted, and its implementation process is as follows:

[0213] Step 1: Initialize the relevant parameters of MPSO-GA, including the initial population size δ, the maximum number of iterations iters max , maximum inertia weight ε max , minimum inertia weight ε min , the starting and ending values ​​of the acceleration coefficient and Next, the initial population is randomly generated.

[0214] Step 2: Calculate the fitness of each particle according to equations (14) to (16). Select the optimal solution for each particle itself, and select the particle with the best fitness as the global optimal solution in the current generation.

[0215] Step 3: Update each particle according to formula (13) and recalculate the fitness of each new particle.

[0216] Step 4: Update the personal best particle of each particle. If there is a better solution than the original particle, update the global best particle.

[0217] Step 5: If the iteration stop condition is met, the algorithm ends. Otherwise, return to step S3 to continue iteration.

[0218] 4 Method Evaluation

[0219] In this section, we evaluate this method from two aspects. On the one hand, experiments in real scenarios verify the effectiveness of this method (Section 4.1). On the other hand, a large number of simulation experiments verify the superiority of the MPSO-GA algorithm in solving multi-task and multi-server offloading problems (Section 4.2).

[0220] 4.1 Validity Verification

[0221] To verify the effectiveness of the proposed method, experiments were conducted in real scenarios based on the following research questions (RQ).

[0222] RQ1 How effective is this approach in improving application performance? (Section 4.1.2)

[0223] RQ2 Is the additional execution overhead of this method within an acceptable range? (Section 4.1.3)

[0224] 4.1.1 Experimental setup

[0225] (1) Applications: We implemented three real-world applications that conform to the program structure proposed in this paper, including a license plate recognition application (LPRA), a target detection application (TDA), and a face recognition application (FRA). In addition, LPRA is an Android application, and TDA and FRA are DNN-based applications. The source code can be found in our GitHub project1.

[0226] Table 1: IoT device context in different scenarios

[0227] Scenario 1 Scenario 2 Scene 3 E1 - V=1.0MB / S RTT=70ms V=1.5MB / S RTT=40ms E2 - - V=1.0MB / S RTT=70ms C1 V=0.6MB / S RTT=100ms V=0.6MB / S RTT=100ms V=0.6MB / S RTT=100ms

[0228] (2) Network environment: Our network environment includes four computing nodes: an IoT device (D1) and three remote servers (E1, E2, and C1). As shown in Table 1, we designed three network scenarios, where scenario 1 is connected only to C1, scenario 2 is connected to E1 and C1, and scenario 3 is connected to all remote servers. Each element in Table 3 represents the data transmission rate v and the minimum link delay rtt. Smaller rtt and higher v indicate better communication capacity. We use the network simulation tool Dummynet to control the available bandwidth.

[0229] (3) Devices: We used workstations to simulate edge servers (E1 and E2) and cloud servers (C1), where E1 is equipped with a 2.5GHz, 2-core CPU and 4GB RAM, E2 is equipped with a 3.0GHz, 4-core CPU and 8GB RAM, and C1 is equipped with a 3.9GHz 8-core CPU and 16GB RAM. In addition, we used two low-performance devices as IoT devices (D1), Huawei Honor MYA-AL10 (1.4GHz, 4-core CPU and 2GB RAM) and Raspberry Pi 3B+ (1.4GHz 4-core CPU, 1GB RAM). LPRA runs on MYA-AL10. TDA and FRA run on Raspberry Pi 3B+.

[0230] (3) Comparison Methods To measure the effectiveness of our approach, we discuss three different states of the application: (i) The original application that cannot support computation offloading (hereafter referred to as OA) is executed only on the IoT device. (ii) The reconfigured application is executed locally on the IoT device (hereafter referred to as RAL), which has been reconfigured from OA to meet the program structure proposed in this paper. (iii) The reconfigured application is offloaded according to the offloading scheme generated by MPSO-GA (hereafter referred to as RAO), which can use the surrounding servers. In line with the principle of rigor, we repeated this process 20 times to avoid unnecessary errors.

[0231] 4.1.2RQ1: Performance improvements brought by this method

[0232] To measure the performance improvement of our approach, we executed the reconstructed applications (including LPRA, TDA, and FRA) in three different scenarios according to the offloading schemes obtained by MPSO-GA. The experimental results are shown in Fig. 9 shown.

[0233] According to the results, the response time of these applications is effectively reduced after computation offloading compared with OA, among which LPRA improves

[0234] 3.97-19.38%, TDA improved by 29.3-46.27%, and FRA improved by 23.4844.64%. Executing neural network models usually requires a lot of computing power, so offloading these computationally intensive tasks to higher-performance servers may bring excellent performance improvements. LPRA is a license plate recognition application based on k-means. By weighing the data transmission time and execution time of tasks in LPRA, most tasks in LPRA are more suitable for local execution, especially in poor network environments. Therefore, the performance improvement brought by computational offloading to LPRA is not significant enough.

[0235] At the same time, the performance improvement of applications varies in different network environments. In scenario 3, the surrounding network resources are richer and the communication capabilities are stronger, and the performance improvement is significantly better than other situations. In scenario 1, which is only connected to the cloud service, most tasks are still performed locally, so the performance can only be improved by 3.97-29.3%.

[0236] In general, this approach can provide performance improvements for different scenarios and applications to a certain extent.

[0237] 4.1.3RQ2: Additional execution overhead generated by this method

[0238] Compared with the original application, the proposed structure incurs additional execution overhead, which consists of three main parts: (1) External variables or results need to be packaged before and after calling the service. (2) The called service or database needs to be judged by the controller (Invoke or Call function) for execution. (3) The communication and response time generated by the interaction between the controller and the service or database. In order to measure the additional overhead, OA of different types of applications are used as benchmarks.

[0239] The difference between RAL and OA shows the additional overhead of this method. The difference between RAO and OA shows the performance improvement effect, where RAO takes the average response time under different scenarios of RQ1. The experimental results are shown in Fig.10 shown.

[0240] From the experimental results, TDA and LPRA generate more additional overhead during execution. In contrast, the overhead of FRA is negligible. An important reason for this result is that FRA has a simpler structure and contains fewer services and databases than TDA and LPRA. The additional overhead of offloading is mainly generated when calling services or databases. The more services or databases included in the application, the more additional overhead is required.

[0241] In addition, by comparing Fig.10From the two dashed lines in , we can see that the additional execution overhead is negligible compared to the average optimization time gain of computation offloading, especially for applications with more complex tasks.

[0242] In general, the additional overhead generated by this method is within an acceptable range.

[0243] 4.2 Superiority Verification

[0244] To verify the superiority of the MPSO-GA algorithm, extensive simulation experiments were conducted for the following research questions (RQ):

[0245] RQ3: In a simple network environment where different applications are executed independently, can MPSO-GA obtain the optimal offloading solution?

[0246] RQ4: When different applications compete for resources during execution and the network environment is more complex, can MPSO-GA obtain the optimal offloading solution?

[0247] It is worth noting that the parameters of MPSO-GA in the simulation experiment are initialized with δ = 100, iters max =1000,ε max =0.8,ε min =0.2, and

[0248] 4.2.1 Experimental setup

[0249] (1) Application: Same as Section 4.1, application types include LPRA, TDA, and FRA. The literature generally assumes that the task execution time is linearly related to the amount of allocated computing resources, and the relationship between data transfer time and network communication capacity is the same. Therefore, by collecting the execution time and data transfer time on devices with different performance, the computational workload and data transfer size of different program segments in the application are obtained in advance, and then calculated using least squares linear regression. In addition, each type of application needs to specify a deadline constraint to check whether the offloading scheme is feasible. The deadline constraints are set as follows.

[0250] dl1={3.1,3.4,3.8,4.2}dl2={4,5.1,6.3,7.6}dl3={2.6,3,3.5,4.2}

[0251] Among them, dl1, dl2 and dl3 are the deadlines for license plate recognition, target detection and face recognition respectively. The smaller the value, the stricter the time constraint.

[0252] Table 2 Device related configuration

[0253]

[0254]

[0255] Table 3 Network connection status

[0256]

[0257] (2) Network environment: In this section, we designed an application scenario, such as Fig.10 The cloud-edge environment in the scenario includes a total of 9 IoT devices (n1 to n9), 6 edge servers (n 10 ~n 15 ), and 1 cloud server (n 16 ). The configuration, overhead and execution of applications of different types of devices are shown in Table 2. Applications are only triggered and executed on IoT devices. The execution frequency in Table 2 indicates that different applications are automatically executed once every period of time. Each IoT device is connected to its two adjacent edge servers, and the adjacent edge servers are interconnected. All IoT devices and edge servers are connected to the cloud server, such as Fig.10 The specific network conditions and overheads between different types of computing nodes are shown in Table 2.

[0258] (3) Comparison of algorithms: In order to compare and evaluate the performance of MPSO-GA in the MEC environment, the following three methods are introduced: (i) Traditional PSO cannot be directly used for the discrete problem in this paper, so the discrete problem is converted into a continuous problem by taking the remainder, and the fitness function is the same as PSOGA. (ii) GA uses a binary problem encoding method whose dimension is equal to the number of servers, and the fitness function is the same as PSOGA. (iii) Idea: By saving the optimal solution during the experiment, it is as close to the true optimal solution as possible. In the experiment, the offloading results of the same configuration may be different. Therefore, the system overhead is measured by taking the average value of the feasible solutions through 30 repeated experiments.

[0259] 4.2.2 RQ3 Independent execution of applications under different deadline constraints

[0260] In order to ensure that there is no resource contention between applications, different types of applications are executed in different time periods. Assume that in the time period of 0 to 180 seconds, the license plate recognition application is executed on n1, n2, and n3; in the time period of 180 to 240 seconds, the target detection application is executed on n4, n5, and n6; in the time period of 240 to 360 seconds, the face recognition application is executed on n7, n8, and n9. The experimental results of different types of applications under different deadline constraints correspond to Fig.12(a), (b) and (c). The positive axis in the figure represents the system overhead of the feasible solution under the scheme, and the negative axis represents the sum of the difference between the response time of each application and the time constraint under the scheme when there is no feasible solution. The broken line represents the ratio of the algorithm to generate feasible solutions in 30 repeated experiments.

[0261] From the experimental results, by using MPSO-GA, PSO and GA, the system overhead decreases as the deadline becomes wider. This is because the meta-heuristic-based strategy tends to assign more tasks to servers with low overhead when the deadline is not strict. Fig.12 (a) and (b) show that when the deadline is the most stringent, there may be a situation where no feasible solution can be found. The results also show that the system overhead of different types of applications is different. This is because they are composed of different services, and there are various data transmissions between services. For example, TDA contains more complex services, and in order to meet the deadline, most of the tasks must be offloaded to high-performance servers, which requires more computational overhead.

[0262] Whether in terms of saving system overhead, the difference with the deadline or the proportion of feasible solutions, the effect achieved by MPSO-GA is better than that of PSO and GA. This is because MPSO-GA can adaptively adjust the search ability according to the current situation and iteratively evolve from a global perspective. However, the PSO algorithm has the problem of poor local search ability and insufficient search accuracy, which makes it difficult to find a better solution. The performance of the genetic algorithm is greatly affected by the deadline constraint because its search range is local at each iteration. In summary, compared with PSO and GA, MPSO-GA saves about 3.95% to 11.56% and 2.11% to 17.51% of system overhead, respectively.

[0263] 4.2.3 RQ4 Simultaneous execution of applications under different deadline constraints

[0264] In order to study the decision-making effect of PSOGA in a more complex network environment, each application on IoT devices n1~n9 is triggered and executed at the same time at time 0s and executed for 360s. Fig.13 As shown:

[0265] According to the experimental results, under the two most stringent time constraints, none of the three algorithms can obtain a feasible solution. Moreover, PSO and GA can only have a feasible solution under the most relaxed time constraint. Unlike RQ3, different applications compete for resources during execution, resulting in the response time of some applications failing to meet the deadline. Therefore, even under the second most stringent time constraint, there is no feasible solution. However, by comparison, it can be found that the solutions generated by MPSO-GA in these two cases can make the overall application response time closer to the time constraint.

[0266] At the same time, as the number of applications increases, the number of services and databases that need to be determined increases significantly, and the size of the problem space grows exponentially. Therefore, the difficulty of the algorithm to obtain a suitable offloading solution also increases greatly. Nevertheless, MPSO-GA is still able to obtain a feasible solution under the third strict time constraint.

[0267] This method can support the computation offloading of various applications in MEC as well as multi-task and multi-server offloading decisions. Experimental results show that this method can significantly improve the performance of applications in different scenarios, and the additional execution overhead is acceptable. In addition, through simulation comparison experiments, it is proved that this method has a greater chance of obtaining a feasible solution under stricter time constraints; and under looser time constraints, the feasible solution has the lowest overhead.

[0268] The above is only a preferred embodiment of the present invention, and does not limit the present invention in other forms. Any technician familiar with the profession may use the above disclosed technical content to change or modify it into an equivalent embodiment with equivalent changes. However, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the technical solution of the present invention still belongs to the protection scope of the technical solution of the present invention.

Claims

1. A method for supporting adaptive offloading of multiple IoT applications in an edge environment, characterized in that: include: Building applications that conform to a common program structure that supports on-demand compute offload; For applications that conform to the general program structure that supports on-demand computing offloading, the program fragment flow chart is extracted through static code analysis to provide the program's internal process information for the generation of offloading solutions; The optimal offloading solution is obtained by analyzing the surrounding MEC environment and applications through the offloading solution generation algorithm of the multi-task particle swarm optimization algorithm MPSO-GA based on the genetic algorithm operator; Applications offload computations at the service granularity according to the offloading scheme, minimizing system overhead while meeting the deadline constraints of each application; The offloading solution generation algorithm describes the application offloading problem in the MEC environment from three aspects: network model, application model and performance model, and solves the application offloading problem through the MPSO-GA algorithm; The network environment includes a cloud server CS, multiple edge servers ES, and multiple IoT devices DS. The MEC environment is modeled as a graph G = (N, E) including a set of computing nodes N = {n1, n2, ..., n w }, and use set E to represent the connections between them; the computing nodes use Indicates that, where ψ i Represents computing node n i The computing power of each node is assumed to be able to meet the corresponding demand; i Represents node n i The maximum number of tasks that can be executed is equal to the number of cores of the node; Indicates the use of computing node n i The computation cost per second; expressed in e i,j Indicates n i and n j The connection between them is related to the bandwidth v i,j And the minimum link delay rtt i,j Related, and Use to represent node n i and n j The transmission overhead per second between them; Assume that there is a system that will execute for θ time during the uninstallation process; there are multiple applications A from IoT devices in the system = {a1, a2, ..., a g }, and application a i μ i Each application executes ξ in the time interval θ. i =θ / μ i times, and use dl i Indicates application a i Deadline; each application complies with the general program structure; the application is modeled as a program fragment flow chart Flow i =(D i ,S i ,P i ,Q i ); In order to calculate the application response time and money cost, a corresponding service and database offloading solution is built; Indicates application a i The deployment location of the service in; for each program fragment The execution location depends on the service The deployment location, i.e. Indicates application a i The deployment location of the database in In application a i No. i During the execution, use Represents an execution program fragment The time when the task reaches the computing node; the time when the fragment actually starts to execute is represented by represents the waiting time of the fragment in the queue on the node, then: Precursor fragment Passing data to a program snippet The resulting data transfer time is as follows: Program snippets Occupied Node Time By its own task execution time and data transfer time between different databases during execution composition, The calculation is as follows: The end moment That is, the start time plus the time at the node The occupation time is calculated as follows: Application i No. i The start time of the next execution is the first program fragment that executes the main service Mission arrival time The end time is the last segment of the main service Time to complete execution Then application a i No. i Response time of each execution The calculation is as follows: Program snippets On the compute node During execution, the usage overhead generated by occupying the node is calculated as follows: Program snippets During execution, the transmission overhead of incoming data and interaction with the database is calculated as follows: Serve The monetary cost of being called and executed once That is, the sum of the usage overhead and transmission overhead of all program fragments it contains, calculated as follows: Application i The money cost of executing once MC(a i ) is the sum of the monetary cost of all services multiplied by the number of times they are called, calculated as follows: The optimization goal of the offloading solution generation algorithm is to obtain an offloading solution for services and databases to minimize the total monetary cost under the condition that the response time of each application in the time period θ satisfies the time constraint; the formal definition of the final application offloading problem is as follows:

2. According to claim 1, a method for supporting adaptive offloading of multiple IoT applications in an edge environment is characterized in that: A general program structure that supports on-demand computing and offloading is designed by supporting a design pattern that supports separate deployment and execution of different types of application programs in modules. The design pattern satisfies the following requirements: each module of the application program can be independently deployed and executed on different computing nodes; the module can determine the computing node where the module to be called or the database is located to ensure the validity of the call; the called module can receive the input of the calling module and return the correct execution result; There are two types of services in an application that follows this design pattern: One is a pure service: using local data without calling other services; the other is a composite service: relying on data from other services and needing to call other services; the composite service mainly includes the following properties: (1) Key-value data Params / result: All external variables required by the called service during execution are passed in through Params, that is, there is no statement in the service to access external variables; When the service needs to modify external variables, it is transmitted through the result; the external variables refer to the variables accessed during the service execution and defined outside the service; (2) String seq: A string seq is maintained in the application to record a call path from the current service to the main service. To maintain the seq, the seq is passed in as a parameter when the service is called, and the name of the called service is added to the seq. (3) Invoke function: The composite service calls other services through the Invoke function. Invoke implements two functions: a) Control forwarding: Determine whether the service is executed locally or remotely, and if it is a remote call, on which computing node to call the service; b) Data transmission: Serialize all parameters required by the called service and deserialize the returned service execution results; (4) Call function: The service establishes a connection with the database through the Call function; the Call function determines the location of the database through the name of the database to be interacted with, and returns the connection channel for transmitting data with the database to ensure normal data interaction between the service and the database.

3. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 2, characterized in that: The implementation method of the Invoke function is: First, determine the calling path from the service to be called to the main service through seq and serviceName, and determine the location address of service execution from the configuration file SP according to the calling path; SP stores the deployment locations of different services. If address is equal to Local, where Local represents the computing node where the service is called, the service is directly executed locally through the local function and the result is returned. If address is not equal to Local, the service is called through the remote function. i 、Parameter i and seq are sent to the agent on the remote node, and the remote agent implements the service through the reflection mechanism i Make a call and return the result.

4. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 2, characterized in that: The implementation method of the Call function is: First, determine the deployment location host of the database from the configuration file DP, according to DatabaseName i , DP stores different database deployment locations; then, obtains the corresponding user and password from the Account that records the database name and password through the host and database; finally, establishes a data transmission channel and returns the channel.

5. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 2, characterized in that: The method of extracting program fragment flow chart through static code analysis is: First, determine the content to be offloaded, that is, the number of services and databases in the application. Databases are uniquely identified by their names, and services are uniquely identified by their call paths to the main services. Second, evaluate the offloading schemes, further divide the services into program fragments, and record the execution order between the fragments. Finally, model the application as a program fragment flow chart. The program fragment flowchart of the i-th application uses the symbol Flow i =(D i ,S i ,P i ,Q i ) indicates that: Represents a collection of databases in an application and uses Represents a database Name of Represents a collection of services in an application and uses Indicates service name, Indicates that from the service To the main service A call path of Indicates service The total number of calls; due to the existence of service calls, each service is divided into multiple serial code fragments during the actual execution process, namely P i It is a set that records the order in which actual program fragments are executed. The program fragments in the set can be repeated. The order in which program fragments are added to the set is the order in which they are actually executed in the application. For two adjacent fragments, the previous fragment is called the predecessor fragment of the next fragment. i Represents a collection of records of associations between program fragments and databases, where express During execution, the database There is interaction between them; A code snippet is defined as a triple in, Indicates the incoming fragment The amount of data; Representation fragment The amount of tasks; Representation fragment During execution, the database The total amount of interaction data, if there is no interaction, it is set to 0; Use static code technology to analyze the locations of invoke and call functions in the source code to obtain the program fragment flow chart of application i i =(D i ,S i ,P i ,Q i ); Taking the source code of the i-th application and the service name of the main service as input, construct the corresponding program fragment flow chart, including the following steps: First, assign the main service information to and through Extract the corresponding statement set Then, to the empty set S i Add the main service And D i , P i and Q i Set to empty; finally, call the getFlow() function to recursively build the program fragment flow chart; the getFlow() function is and As the input of the function, they represent the service currently being analyzed and the set of statements corresponding to the service; pId is used to record the number of the current program fragment, which is initially set to 1, and the current program fragment join in and P i For each statement in the statement set, do the following: Get the statement Keywords in the keyword; if the keyword contains the keyword 'invoke', the call path callSeq is used to determine whether the called service has appeared before. If yes, the call count is increased by 1. If no, S is added i , and get the corresponding statement set through the service name; update pId, and the current new program fragment join in and P i In service Perform getFlow() recursion; if the statement The keyword in the keyword contains the keyword 'call'. Similarly, first determine the database Is it already in set D? i If not, add it; then, judge Is it in set Q i If not, add it.

6. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 1, characterized in that: The specific implementation method of the unloading scheme generation algorithm of the multi-task particle swarm optimization algorithm based on the genetic algorithm operator is: The encoding strategy of the uninstallation scheme generation algorithm meets the following three principles: Completeness: Every candidate solution in the problem space can be encoded into a corresponding coded particle; Non-redundant: Each candidate solution in the problem space corresponds to only one encoding particle; Survivability: Each coding particle in the coding space can correspond to a candidate solution in the problem space; The encoding strategy uses particle Z to represent the candidate solutions for cost-driven offloading of all services and databases in the MEC environment, where the i-th particle at the t-th iteration is described as (12): Where p and q represent the total amount of services and databases in the entire system respectively; in formula (13), Represents computing node n j The kth service is deployed on the i-th particle at the t-th iteration, Represents computing node n j Deploy the kq-th database to the i-th particle at the t-th iteration; Each coding bit of a particle represents the deployment location of the corresponding service or database, which satisfies the completeness principle. Different coding particles represent different offloading schemes. A feasible solution in the problem space corresponds to only one coding particle in the coding space, so it satisfies the non-redundancy principle. However, some candidate solutions corresponding to the particles may not meet the deadline constraint, which means that the response time of some applications exceeds the time limit. Therefore, the survivability principle is not met. All particles are divided into two categories: Feasible particle: Under the uninstallation strategy corresponding to the particle, each application meets the deadline constraint; Infeasible particle: Under the unloading strategy corresponding to the particle, at least one execution of the application cannot meet the deadline constraint; In order to compare different particles, the fitness function is used for measurement; particles with smaller fitness represent better candidate solutions; because some solutions may make the application response time exceed the specified deadline, they are divided into the following three cases for comparison: Case 1: One particle is a feasible solution and the other particle is an infeasible solution. In this case, the feasible solution is selected and its fitness function is defined as: Case 2: Both particles are infeasible solutions; the particle with the smaller sum of the deadline time difference is selected because it is closer to the feasible solution and is more likely to become a feasible solution in subsequent evolution; its fitness function is defined as: Case 3: Both particles are feasible solutions; the particle with lower monetary cost is selected, and its fitness function is defined as: The crossover operator and mutation operator of the genetic algorithm are introduced to update particles; the iterative update of the i-th particle in the t+1th iteration is shown in formula (17): Among them, F u () indicates mutation operation, F g () and F p () indicates the crossover operation, ε is the inertia weight; σ p and σ g is the acceleration coefficient; φ u ,φ p and φ g is a random number in the interval [0,1]; For the inertial part, the velocity of the particle is defined as: Among them, M u () represents the mutation operator, ε represents the threshold for mutation; when the random number φ u When it is less than ε, the mutation operation is performed; first, a position ind1 in the particle is randomly selected, and then a computing node is randomly selected to replace the computing node originally mapped on ind1; The formulas for individual cognition and social cognition in particle updating are as follows: Among them, C p () indicates a crossover operation, represents the optimal historical particle of the i-th individual in the t-th iteration, gBest t represents the best historical particle among all particles in the tth iteration, σ p (σ g ) represents the threshold of individual crossover; when the random number φ p (φ g ) is less than the threshold σ p (σ g ) when performing crossover operation; For a particle, the execution time and total monetary cost of each application under the corresponding uninstallation scheme are calculated; the uninstallation scheme generation algorithm maps the particle to the uninstallation result through the evaluation algorithm; the evaluation algorithm calculates the start execution time and execution completion time of each program fragment by simulating the actual execution process of the program fragment, thereby calculating the response time and total monetary cost of each application; the specific method is: First, set a variable curTime to represent the current time and initialize it to 0; input the service and database offloading solutions SP and DP respectively; use the symbol λ i Indicates the number of times the application is currently executed, with an initial value of 1; for each program fragment Define three properties and They represent the time when the task of executing the fragment arrives, the time when the fragment is completed, and the remaining execution time of the fragment respectively; they are initialized as follows: Then, the response time and money cost of each application execution are calculated by formulas (6) and (10); The unloading scheme generation algorithm uses a discrete adjustment method based on the quality of the current population particles to adjust the inertia weight ε, as shown below: in Represents the i-th particle in the current t-1th iteration and the global optimal solution gBest of the t-1th iteration t-1 The difference between i is a statistical factor, when τ j When the value is 1, it means and gBest t-1 The computing nodes mapped on the jth code are the same, otherwise the value is 0; therefore, the search ability of the algorithm can be adaptively adjusted according to the difference between the current and global optimal particles; The two cognitive factors σ of the algorithm p and σ g Use linear increase and decrease strategy for setting; and Respectively represent the parameters σ p and σ g The initial value of the iteration, and Respectively represent the parameters σ p and σ g The final value of the iteration.

7. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 6, characterized in that: The evaluation algorithm takes the uninstallation scheme and the application flow chart as input to obtain the execution time of each application and the total monetary cost of the system. The specific steps are as follows: Step 1: Fill the channel; according to the offloading plan, add each program fragment to the computing node in sequence until there is no empty channel on the computing node; where n i .empty represents node n i The number of remaining channels, whose initial value is ω i ; The program fragment placed in the channel must meet the condition that the task executing the program fragment has arrived at the computing node at the current time, that is, Step 2: Find the minimum time slice; first traverse the program fragments being executed on each computing node and find the shortest remaining execution time. Assign it to the time slice slice; then, add slice to the current time curTime, indicating that the time of length slice has passed; Step 3: Calculate the remaining time of the program fragment; Subtract the time slice slice, indicating that the execution time is slice length; when the remaining time 0, indicating that the program fragment has been executed and its end time Set to curTime; then, remove the fragment from the channel and increase the number of idle channels of the node to n i .empty plus 1; if it is not the last fragment, then from P i Get the next program fragment to be executed And the time when its task arrives The time when curTime and data are passed in The sum; if the program fragment is P i If the last fragment of the program is executed and the current execution count is less than the total execution count, it means that the application program has finished executing and entered the next execution; the first program fragment of the next execution Take the maximum value between the ideal trigger time and the current time; Repeat the above steps until each application a i All executed i Finally, the response time of each application execution is calculated by formulas (6) and (10): and money expenditure MC(a i ).

8. The method for supporting adaptive offloading of multiple IoT applications in an edge environment according to claim 6, characterized in that: The implementation process of the MPSO-GA algorithm is as follows: Step S1: Initialize the relevant parameters of the MPSO-GA algorithm, including the initial population size δ, the maximum number of iterations iters max , maximum inertia weight ε max , minimum inertia weight ε min , the starting and ending values ​​of the acceleration coefficient and Then, randomly generate the initial total; Step S2: Calculate the fitness of each particle according to formulas (14) to (16); select the optimal solution of each particle itself, and select the particle with the best fitness as the global optimal solution in the current generation; Step S3: Update each particle according to formula (13) and recalculate the fitness of each new particle; Step S4: Update the personal best particle of each particle; if there is a better solution than the original particle, the global best particle will be updated; Step S5: If the iteration stop condition is met, the algorithm ends; otherwise, return to step S3 to continue iteration.

Images