[0051] The technical scheme of the present invention will be further described below in conjunction with the drawings.
[0052] The computational offloading system model proposed by the present invention is based on the traditional cellular network model, and the MEC servers are all set up on the base station (Base Station, BS). Reference figure 1 with figure 2 According to one embodiment, a mobile edge computing offloading system based on mobile agents includes: an MEC server and a mobile device (Mobile Device, MD) held by a user. The MEC server is deployed on a BS, and the MEC server consists of two Part of the composition: One is the proxy container, which is different from the container mentioned in the background. The proxy container only provides a runtime environment for MA. Because the computing resources of the MEC server are far more abundant than those of the MD, the MEC server has the ability to run many agent containers at the same time to provide services to multiple users at the same time; the second is the Resource Manager (RM), where RM maintains a resource The database records all available proxy containers in the local area network where it is located, including the geographic location, IP and physical address of the server, the identity of the container, and the active state (occupied or idle). This database will be updated in real time through periodic data exchange between RMs. With this database, RM can provide query services and respond to uninstall requests from OM and migration requests from MA.
[0053] The various applications on the user’s MD are divided into a series of modules at the time of installation. These modules can be divided into two types: local modules, that is, modules that cannot be uninstalled to the MEC server, such as sensor modules that need to collect data locally Etc.; unloadable modules are modules that can be packaged in MA and uninstalled to be executed on the MEC server. In addition, in principle, only computationally intensive modules need to be sent to reduce the burden on mobile devices, so an Offloading Manager (OM) is set up to make an offloading plan and decide which modules need to be offloaded. At the same time, this manager is also responsible for communicating with the resource manager RM on the MEC server to obtain available agent containers.
[0054] The process of calculating unloading is as image 3 As shown, including the following steps:
[0055] Step1: After the user starts the mobile APP on the MD (such as a smart phone), OM contacts the RM on the MEC server to obtain the list of available agent containers and select the appropriate target agent container.
[0056] Step2: OM makes an uninstall plan (which contains specific modules that need to be uninstalled), and then OM creates a mobile agent and encapsulates the modules that need to be uninstalled into the agent. Send an uninstall request to RM.
[0057] Step3: RM establishes a channel between MD and target agent container, and sends MA newly created by OM to the target agent container to run. MA communicates with the original APP through the channel established by RM and performs tasks.
[0058] Step4: After all the tasks of the MA are completed, the OM issues a command to end the life cycle of the MA, and the RM empties its container.
[0059] Furthermore, considering the user's mobility, the user may go out of the coverage of the current base station while the MA is performing its tasks. In order to ensure that the communication delay between MA and MD will not be too high, MA will be migrated to the MEC server closer to the user. The migration process includes:
[0060] Step5: If the MA finds that the delay is higher than the threshold during the communication with the MD, the agent will make a migration decision. MA consults RM to obtain information about other MEC servers in the LAN. The agent will select the appropriate container on the server closest to the user as the migration target according to the location information of the mobile device (OM allows MA to periodically obtain the location information from the mobile device), and then send a migration request to the RM.
[0061] Step6: RM responds to the migration request and establishes a channel for MA. The MA suspends the task being performed, adjusts its state to the migration preparation state, and prepares for migration. RM sends the agent to the target container on the target MEC server.
[0062] Step7: After the MA reaches the target container, it resumes its working state, reconnects with the MD, and continues to perform the task. Since the user may continue to move beyond the coverage of the current base station, return to Step 5, continue to monitor the communication delay between MA and MD, and decide whether to trigger migration according to conditions. After all the tasks of the MA are completed, the OM issues a command to end the life cycle of the MA, and the RM empties its container.
[0063] According to the above-mentioned uninstallation method flow, the following describes the uninstallation and migration process in conjunction with a specific example. Suppose that a user starts a certain APP on MD while connected to the Internet, and OM then communicates with the MEC server on the BS through the BS currently connected to the mobile phone, which may be called BS0 and MEC server0. OM obtains the list of available containers on this server from RM on MEC server 0, and selects one as the target container. Subsequently, OM makes an uninstall plan based on the decision tree of the application.
[0064] The application decision tree represents the relationship between all unloadable modules in the APP (mainly the relationship between the call and the called). Such as Figure 4 As shown, each node in the figure represents a module of the application program, and the top node represents the entrance of the program (ie, the main module). The child nodes of each node represent the directly called sub-modules, such as node N in the figure 1 , N 2 , N 3 Is to be N 0 The called submodule. The connection between the parent node and the child node is marked with the amount of information they interact with each other, for example, N in the figure 21 Is by N 2 The called submodule, d on the connection between the two 21 Then N 21 In the process of being called with N 2 The total amount of information interacted, including input parameters and return values.
[0065] For each module in the decision tree, OM decides whether it should be offloaded to the MEC server according to the following cost model:
[0066]
[0067] CS n =d n /B (2)
[0068] Among them, CD n Represents the time spent by module n running on MD, including the running time of n itself and all the sub-modules it calls. CS n It represents the time it takes for module n to be uninstalled to the MEC server. Since we assume that the computing power of the MEC server is much higher than that of mobile devices, the execution time of the module on the server is negligible compared with the execution time on the MD, so in the calculation CS n Only calculate the time spent on information exchange between MD and server. T n It is the time spent by the module n itself running on the MD, excluding its calling module, which can be obtained through a static program analyzer. d n Is the total amount of information exchanged between module n and the module that calls it, B is the network bandwidth that APP can use, ε n It is the collection of all sub-modules called by module n. If CD n Greater than CS n , You need to uninstall module n to the MEC server, otherwise keep it running on the MD.
[0069] Using the method described above to make an uninstall decision for a single module, OM traverses the application decision tree through depth first, determines the execution cost of each node, and makes the uninstall decision. There is a special case, when the execution cost of all child nodes of a parent node is determined, then whether this node needs to be uninstalled is also determined. If the uninstall decision is affirmative at this time, the uninstall decision of all its child nodes will be invalid, because the child module will move with the parent module. When the decision tree traversal is complete, the uninstall plan is completed.
[0070] According to the uninstall plan, OM creates MA and encapsulates the planned modules, and contacts RM to request that MA be sent to the target container. The RM allocates a channel for the MD and the target agent container, and sends the MA created by the OM to the container for operation. MA communicates with the original APP through this channel and performs tasks.
[0071] After a period of time, the user walked out of the signal coverage of BS0 in the process of accepting the computing offloading service, such as Figure 5 Shown in. MD disconnected from BS0 and switched to BS1 adjacent to it. Therefore, the communication between MA and MD needs to pass through BS1, which inevitably brings communication delay. In order not to affect the quality of service, the MA can autonomously migrate to the MEC server 1 which is closer to the MD in this case.
[0072] Specifically, if the MA finds that the delay is higher than the threshold during the communication with the MD, the agent will make a migration decision. The MA consults the RM on the current server to obtain information about other MEC servers in the local area network, and then selects a suitable container on the server closest to the user (MEC server 1) as the migration target based on the MD's location information, and then sends a migration request to the RM. The RM responds to the migration request and establishes a channel for the MA. The MA suspends the task being performed, adjusts its state to a transition state, that is, the migration preparation state, and prepares for migration. The RM sends the agent to the target container on the target MEC server 1. After the MA reaches the target container, it resumes its working state, reconnects with the MD, and continues to perform the task. After all the tasks of the MA are completed, the OM issues a command to end the life cycle of the MA, and the RM empties its container.
