Abstract
Driven by advanced 5G cellular systems, mobile edge computing (MEC) has emerged as a promising technology that can meet the energy efficiency and latency requirements of IoT applications. Edge service migration in the MEC environment plays an important role in ensuring user service quality and enhancing terminal computing capabilities. Application services on the edge side should be migrated from different edge servers to edge nodes closer to users, so that services follow users and ensure high-quality services. In addition, during the migration process, edge services face security challenges in an edge network environment without centralized management. To tackle this challenge, this paper innovatively proposes a blockchain-based security edge service migration framework, Falcon, which uses mobile agents different from VM and container as edge service carriers, making migration more flexible. Furthermore, we considered the dependencies between agents and designed a service migration algorithm to maximize the migration benefits and obtain better service quality. In order to ensure the migration of edge services in a safe and reliable environment, Falcon maintains an immutable alliance chain among multiple edge clouds. Finally, the experimental results show that “Falcon” has lower energy consumption and higher service quality.
1. Introduction
With the rapid development of mobile Internet and Internet of Things technologies, various new services have been continuously emerging, making mobile communication traffic experience explosive growth in the past few years. Mobile applications using cloud computing technology are becoming more and more popular, such as VR, real-time video, and 3D games [1]. This kind of emerging application brings great convenience to people’s lives, but with the gradual complexity and diversification of services, higher requirements for network bandwidth and delay have been put forward [2]. Moreover, according to IDC forecasts, by 2020, the total amount of global data will be greater than 40 zettabytes (ZB), and 45% of the data generated by the Internet of Things will be processed at the edge of the network [3, 4]. The concept of mobile edge computing (MEC) has recently become a promising technology to solve these challenges. It pushes mobile computing, network control, and storage to the edge of the network (such as base stations and access points) to facilitate mobile applications with limited resources. Implement compute-intensive and delay-sensitive applications on the device. Its core idea is to bring computing closer to users, distribute small servers or data centers that carry cloud applications across the entire network, and directly connect to entities at the edge of the network (such as micro data centers and cloudlet). Due to its proximity to the terminal equipment, MEC not only reduces the processing pressure of the cloud center but also saves the cost of high end-to-cloud bandwidth and reduces the network response delay of end-to-end edge nodes, so it can provide a higher quality of service than traditional cloud platforms [5]. MEC is considered to be an important part of the future 5G mobile network architecture. Its main purpose is to achieve efficient and seamless integration of cloud computing functions with mobile networks, and for all stakeholders (mobile operators, service providers, and mobile users), provide convenience [6]. MEC is expected to significantly reduce latency and mobile energy consumption and solve the key challenges of realizing the 5G vision.
However, one of the key challenges facing MEC is how to dynamically migrate services. Due to the limited range of a single edge cloud and the frequent movement of terminal devices (such as smart cars and personal mobile terminals) to different geographical areas, the quality of edge cloud services has declined sharply, and even service is interrupted which makes it difficult to guarantee service continuity [7]. As shown in Figure 1, the terminal user requests the services provided by edge cloud A at position 1 (such as augmented reality and Internet of Vehicles applications). When the terminal user moves to position 2, because position 2 is far away from the service radius that edge cloud A can provide, the service quality drops sharply, and even the service is interrupted. In order to ensure service quality, services need to be migrated to an edge cloud near the current user location (such as edge cloud D or edge cloud E). On the one hand, when the terminal user moves, ideally the services on the edge server should also be migrated to a new nearby server in real time. Therefore, effective dynamic service migration is essential for the normal provision of edge services in edge computing environments [8]. On the other hand, edge services are located in different edge clouds, and edge servers may belong to different participants, such as telecommunications operators, Internet companies, and home users. Therefore, there is no centralized management for different heterogeneous hardware [9, 10]. The dynamic, open, and collaborative nature of the MEC network environment makes network security issues more and more complex. Therefore, the issue of trust in service migration is also very important.
To solve this problem, Chen et al. in [11] proposed an edge cognitive computing (ECC) paradigm that combines edge computing and cognitive computing. They have established a dynamic migration platform for edge services based on mobile user behavior cognition, which can predict user behavior and better guide service migration based on traffic data and network resource environment. Literature [12] is dedicated to determining the migration strategy and communication strategy through the reinforcement learning model, so as to solve the problem of edge service migration. However, most of the abovementioned research on edge computing uses virtual machines (VMs) as the carrier of migration. The overlay of VMs can be tens or hundreds of megabytes. For delay-sensitive applications, the total migration time is relatively long [13]. Furthermore, the VM overlay is not easy to maintain which limits the application in industry and academia. In addition, these studies did not consider the migration trust of edge services in different edge clouds. Edge computing environments cause security risks when data are sent to untrusted edge servers. The complexity of the mechanism and the huge amount of calculation make it difficult to overcome.
In this paper, we innovatively propose an edge service migration framework based on the blockchain named Falcon. Worth noting, Falcon uses a more flexible and portable mobile agent as the carrier of edge services and uses blockchain technology to jointly maintain a trusted alliance chain to solve the trust problem of service migration in multiple edge clouds. Secondly, seek the migration strategy with the greatest benefit through the migration decision algorithm and guarantee higher user service quality. Finally, we deployed this framework in a computing cluster to evaluate its performance. The evaluation results show that the framework ensures the service quality of end users while ensuring the security of service migration. The contribution of this work is summarized as follows:(i)We propose a mobile agent-based edge service migration framework, Falcon, and design a migration decision algorithm to seek the migration path with the least migration cost. This framework makes the service migration more flexible and portable, with low migration cost, and ensures better service quality.(ii)In multiple heterogeneous edge environments lacking a trusted third party, we built a consortium chain network of multiple edge nodes and improved the PBFT consensus algorithm of Ethereum. There is no need to perform three stages in the checkpoint phase. The submission process significantly reduces the amount of network communication. This ensures the safety and performance of Falcon during the service migration process.(iii)We implemented a blockchain-based mobile agent dynamic service migration prototype platform and evaluated it through experiments. The results show that the proposed migration framework course meets the needs of user edge service migration, and the improved blockchain network throughput is excellent. Compared with the traditional PBFT algorithm, the performance of Falcon is encouraging.
The rest of this paper is organized as follows. Section 2 summarizes the related work. In Section 3, we describe in detail the mobile agent-based edge service migration architecture. Section 4 shows the mechanism of using blockchain technology to solve the trust problem of edge service migration. Section 5 makes a formal evaluation of the performance of the framework. The experimental results and performance evaluation of the agent-based dynamic service migration platform are discussed in Section 6. Finally, Section 7 concludes this paper.
2. Related Work
Edge service migration is an important mechanism to ensure user experience, and it has received extensive attention from industry and academia in recent years. It has been widely used to study how to overcome network latency and reduce service interruption time in edge networks. There are already some literature studies [14, 15] that have analyzed and summarized the service migration methods.
Earlier research on edge services migration focused on the migration of virtual machines (VMs) which improve QoS by optimizing the migration time to reduce service downtime. Lu et al. [16] combined remote loading and redirection to speed up service migration. By tracking historical access patterns, a load request list is generated to locate the service application for booting, and then core code is automatically prefetched and cached. It enables running VMs to switch data access to merged image files, reducing edge service migration time. Sun et al. [17] proposed an improved serial migration strategy and introduced a post-copy migration scheme into serial migration. The queuing model is established to quantify the performance indicators, and mathematical analysis is used to evaluate the performance of the model. It improves the hybrid migration strategy of serial migration strategy and parallel migration strategy and improves resource utilization and QoS. The method proposed in [18] introduced low-latency access to data or edge services by introducing a distributed cloud layer composed of cloudlets (“small clouds” with low computing power) between users and the cloud. This method uses VM to realize the common architecture for service migration. Nevertheless, the size of the virtual machine overlay can be tens of megabytes or hundreds of megabytes depending on the application, which is relatively long for latency-sensitive applications and it is unacceptable.
Some researchers use docker container migration for service migration. For example, Ma et al. [19] conducted an in-depth study on the characteristics of docker container’s hierarchical storage and proposed a migration method that uses a hierarchical storage system to reduce data synchronization overhead. But based on the checkpoint CRIU technology [20], all data in the storage layer and the entire file system are packaged and transmitted, which may worsen the condition of the edge network, especially in the case of a bad network environment, and even cause service interruption. In addition, considering the security of edge services, Tian et al. [21] proposed an authentication framework to solve the security and privacy protection in Internet of Drones (IoD), by adopting a lightweight online/offline signature design, and designed a MEC-based predictive authentication method to minimize potential authentication costs and guarantee privacy protection of the drone’s identity, location, and flying routes. Gope and Sikdar [22] considered the physical security of UAVs and proposed an effective privacy-aware authentication key agreement scheme for UAV interconnection. This solution does not need to store any key in the device to provide the required security features. These studies have solved the privacy and security of IoD in MEC. However, edge service migration is unique. Since the edge node that provides the service may be an unauthorized malicious node, there is a risk that the service is migrated to an untrusted server or user data are intercepted. The current research on the security of service migration is mostly based on information hiding and encryption technology, but as the business becomes more and more complex, the problem of the throughput of these traditional methods gradually appears.
Agent-based edge service migration is a relatively new field and needs to be studied systematically. Compared with VMs and containers, mobile agents (MA), as a program that replaces other programs to perform certain tasks, can choose when and where to move autonomously from one host to another in a complex network system [23]. When a move is triggered, the mobile agent can suspend its running process as required, then move to another place on the network to restart or continue its execution, and finally, return the result and message. Aglets mobile agents can migrate and communicate autonomously in any Java environment, so they occupy less platform resources, while VMs and containers tend to save most resources in migration services [24]. In the network, mobile agent is very suitable as the carrier of edge service migration because of its characteristics of moving between different hosts. Moreover, because agent-based service migration not only provides program runtime environment but also uses autonomous agent-based application partitioning, which reduces the management burden of edge servers and mobile terminals [25]. On the contrary, in the process of service migration based on VMs and containers, these management burdens rely heavily on the support of the underlying virtualization technology, and the agent greatly reduces this management burden. Finally, edge servers have limited bandwidth, unstable network connections, storage, and processing capabilities, and running mobile agents that take up few resources on them will be more conducive to migration services [26].
3. Mobile Agent System Architecture
In this section, we first discuss the internal details of mobile agents. And take IBM Aglets as an example to analyze the advantages of mobile agent as an edge service migration carrier [27]. Second, we introduce the system’s service collaboration mechanism.
3.1. Migration between Mobile Agents
In a dynamic heterogeneous MEC environment (such as VMs, containers, or even physical machines), using mobile agents for service migration can achieve better performance and better adaptability to changing network conditions. For example, agents can migrate between VMs, containers, and physical machines as long as the Java runtime environment is configured [28, 29]. This software execution environment has software and hardware support for agent operations. These resources can be a network computer, a grid node, or a cloud infrastructure in the edge network. Each agent is executed in a self-contained virtualization container. In Figure 2, the interaction process between mobile agents is shown. Each mobile agent system consists of two parts: mobile agent (MA) and mobile agent environment (MAE). MA is a software entity running in MAE, which can be migrated between different MAEs and interact with local services or resources to complete tasks. In our framework Falcon, MA is composed of user agent (UA) and service agent (SA). The IBM Aglets agent provides different event handling functions at different points in its life cycle. A running aglets can call the clone method to clone itself, or call the deactive method to store it on a binary storage medium [30]. Similarly, when the agent is successfully created and the onDispatching method is called, the aglets agent will be dispatched to another host to continue running according to the different parameters passed [31]. When moving, the system serializes the information carried by the agent into a standard format. Once the agent arrives at another host, it will call the onArrival method to rerun at the destination.
3.2. Agent-Based Edge Service Migration Mechanism
In the Falcon framework, edge services are provided by a group of cooperative SAs. The mobile agent runs on one platform, but can be moved to another platform. As shown in Figure 3, the agent-based service migration diagram, in addition to the service agent, there are four key service components: event decision server (EDS), resource management server (RMS), data management server (DMS), and trust management server (TMS).
Function of EDS is to collect system-wide events and functional notifications and pass them to the mobile agent to decide whether the agent needs to be migrated. The agent can register for network monitoring and security events, such as calculating the network condition by analyzing the network latency RTT and packet loss rate PacketLoss parameters of the current edge server. The agent can also prevent damage to the platform on which the agent is currently running through intrusion detection of the security event system. In addition, it can register to receive new platforms or announcement services for new platforms, thereby having better QoS. In these cases, EDS will decide to migrate to a new platform to avoid further losses if the current platform has been damaged. We will discuss the decision migration mechanism in detail in Section 3.3. EDS is essentially the trigger source for agent migration, enabling agents to better respond to changes in the edge network environment and provide users with better QoS.
Data manager server (DMS) and authorization management server (trust manager server, TMS) can, respectively, persistently store data (including service status data and user data) and secure mutual trust data between mobile agents migrated to destination hosts. Mobile agent saves the necessary service status and data in the database before migration and restores the status and progress of the job after migration to a trusted destination host. The migration destination edge node will maintain an alliance chain among multiple edge clouds to establish mutual trust, so as to ensure the secure migration of edge services among multiple edge cloud nodes.
Resource management server (RMS) is responsible for providing the required resources to agents and platforms. On the one hand, each agent functionally requires a set of resources (such as software modules, data storage, user interface, and various other functions), and the agent also has minimum requirements for each resource. On the other hand, the platform running the agent needs to have the ability to provide a certain number of resources, thereby providing a set of resources to support the function of the agent operation. Each platform can publish resources based on the QoS provided by the RMS, and an agent queries the resources and determines whether a platform can support the necessary resource conditions necessary for its operation. If the current platform cannot provide the agent with the appropriate resources, the agent must query the RMS to determine a viable platform to which it can migrate.
3.3. Service Migration Decision Algorithm Based on Mobile Agent
In this section, we will discuss in detail the migration decision algorithm based on mobile agents. As we discussed earlier, EDS issues a mobile agent migration notice, which involves factors such as the overload of the edge server currently running the agent or the deterioration of the service quality due to the movement of the end user’s location [32]. The reasons for the migration also include the following: the current platform is severely damaged or the required services cannot be provided. EDS must decide which possible platforms to migrate to. In general, the target node to which the task chooses to migrate mainly considers the following factors: network carrying capacity, processing capacity, memory space, migration experience, and subsequent node information of the current node information. But these factors are complicated, and there is a certain relationship between each factor.
In our system model, an information collection module is deployed on each edge server node to collect information on network dynamic load (), CPU computing power (), memory space (), and migration experience (). The edge nodes and links between the nodes form an undirected connection graph , where represents each edge node and E is all the set of weighted links between the nodes, and each link has a migration right Q. Therefore, combining the above factors, the migration weight Q is expressed by the following equation:
Q is the migration weight. The larger the value, the more likely the task of the current node is to move to the neighboring node. Among them, s1, s2, s3, and s4 represent the weight coefficients corresponding to the four indicators (). Due to the complex edge network environment, unstable network bandwidth and edge node failures frequently occur. In order to improve the adaptability of the migration process in the mobile cloud computing environment, we take the task weights and the network conditions of the nodes into consideration and calculate more general migration weight parameters. represents the distance between nodes, it is closely related to the network status value , and is the communication status value between and . We use the round-trip time (RTT) and packet loss rate (PacketLoss) of data packets to reflect the size of this value, which affects the reliability of data transmission. The node distance is expressed by the following formula:where is the average bandwidth of the physical node. We define the migration weight factor as shown in the following equation:
In formula (3), represents the weight update factor of the global task node between and and represents the sum of the accumulated task weights from the initial node to the current node through the migration path. represents the task weight of the current node , and represents the cloud node distance between and . The formula of redefinition of migration weight after improvement is as follows:
When multiple mobile agents perform a certain task collaboratively, there are often cooperation or functional dependencies. For example, one agent may depend on other agents in function. Due to the sharing of public information resources, collaborative processing of information, etc., some agents may need to run on the same execution environment. In other cases, due to the separation of duties and functions and exclusion, some agents may have mutually exclusive relationships. Therefore, they cannot migrate to the same information host. Taking these factors into consideration, we designed a constraint rule checking algorithm (Algorithm 1) to make the migration of a group of agents under different constraint rules, so as to determine the migration of each mobile agent to the corresponding edge node. We set a set of constraint rules R for the groups of agents that make up the edge service. Three types of constraint rules are specified in R:(1)Atomic rules: a group of agents must migrate to the same platform.(2)Dependency rule: an agent is functionally dependent on at least one of the other agents. Therefore, it must be migrated to the platform where the agent it depends on.(3)Exclusion rule: two or more agents cannot be migrated to the same platform.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In the Falcon migration system, we deploy a perception module at each node, calculate and update the collected information to the node task weight, then calculate the distance between the cloud nodes, and update the weight of the link edge in through formula (4). If the current edge node has a directly connected edge node, namely, there is a directly connected edge in , the destination host with the largest weight of the edge is added to the temporary migration plan. If there is no direct edge, use the Dijkstra shortest path algorithm in the undirected graph to obtain the migration path from the node to the destination node and put it into the temporary migration plan. In Figure 4, the edge node 1 has received the migration notification and migrated to the edge node 4. However, there is currently no directly connected edge between the two nodes and no consensus has been established. At this moment, we use the shortest path algorithm to find the path with the greatest benefit (the path is the shortest path). The nodes on this path are all safe nodes that have been verified by mutual trust. If the migration weight of the node exceeds the migration threshold , the node will move to the adjacent maximum weight node. If the migration weight of a node does not exceed the migration threshold , the leading node of the migrating node is returned, and the currently visited node is identified, then the leading node is a valid node. Calculate the migration weights of all unvisited nodes in , so continue to iterate until it migrates to the final destination address. Among the multiple optional destination hosts in the migration, according to the three types of constraint rules between a group of agents, the migration plan that does not meet the operating rules is removed from the temporary migration plan. In order to prevent the node from returning to the front node multiple times, a jump threshold is set in the algorithm. If the value returned by the same node exceeds the jump threshold, the migration task ends. The service migration decision algorithm is shown in Algorithm 2.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
4. Blockchain-Based Edge Service Migration
In this section, we focus on the features of Falcon’s blockchain-based security service migration. First, Section 4.1 introduces the security issues of mobile agents and edge services and describes the huge potential of blockchain in solving the security issues of edge services. In Section 4.2, we present blockchain technology and compare the characteristics of different types of blockchains. Next, we introduced the problem description of blockchain technology to solve service migration in Section 4.3 and made a detailed description of the system architecture. In this chapter, we show how to use the blockchain network to ensure that edge service migration is complete in the environment of mutual trust and security and introduce the role of each layer. Finally, in Section 4.4, we described the specific details of the blockchain after improving the consensus algorithm.
4.1. Blockchain-Based Edge Services Security Migration Practice
In the case of mobile agent security, Falcon should basically support confidentiality, integrity, identity verification, access control, and nonrepudiation to protect the mobile agent from the aforementioned illegal attacks. Mobile agents are intelligent, autonomous, and adaptive. Especially, the mobile agent has mobility, and its mobility is the most significant feature of the mobile agent paradigm [33, 34]. Therefore, the secure migration of mobile agents is considered one of the most important security issues. If an anonymous mobile agent is warned illegally during the migration process, it will cause many serious problems. Therefore, in the mobile agent environment, the integrity of the mobile agent should be guaranteed first. In addition to the security of mobile agent migration, the security and credibility between the hosts of the edge service migration are also critical. Edge services are located in different edge clouds. Edge servers may belong to different participants, such as telecom operators, Internet companies, and home users. Therefore, there is no centralized management for different heterogeneous hardware, and it is difficult to solve the trust problem in service migration. As a result, data are sent to untrusted edge servers, which pose a security risk.
Blockchain technology is very suitable to solve the trust problem of service migration in the MEC environment due to its inherent distribution and immutability. The blockchain is an ever-growing list of records, called blocks, formed by linking these blocks one after another protected by cryptography. It is inherently resistant to data modification [35, 36]. Once the interactive information is recorded, the data in any given block cannot be retrospectively modified without changing all subsequent blocks and the network majority colluding. Therefore, the blockchain can be used as an open and distributed operating system to achieve decentralized consensus. In the Falcon framework, it can effectively record the interactions (for example, transactions) between two individuals or agents in a verifiable and permanent way.
4.2. Blockchain
Blockchain is essentially a decentralized database. As the underlying technology of Bitcoin, it is a series of data blocks associated with cryptographic methods [37, 38]. Each data block contains a batch of Bitcoin network transaction information to verify the validity of the information (anticounterfeiting) and generate the next block [39–41]. Blockchain technology is also a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, and encryption algorithms [42].
4.3. System Overview
We improved the blockchain consensus algorithm and introduced it into Falcon as a security system verification mechanism. Multiple edge clouds jointly maintain a consortium chain network and develop a contract algorithm. When an unfamiliar edge network joins the blockchain network, the verification algorithm will be executed. As shown in Figure 5, the system framework of the entire trusted network is divided into three layers, namely, the audit layer, the edge control layer, and the user layer.
4.3.1. Public Audit Service Layer
The first layer is the public audit service layer. In this layer, all edge clouds in different geographic locations jointly maintain a tamper-proof database to store and share the interactive information of different edge clouds and mobile user information. Each edge cloud has equal rights in data management and user management. In the Falcon framework, we adopted a consortium blockchain to establish a data sharing scheme. The distributed database records public verification information of different organizations, and each member can verify the integrity of the data without requiring a trusted third party. Therefore, the whole system contains three entities: agents, users, and different edge cloud providers.(1)As a separate organization, each edge cloud provider provides data sharing services for edge nodes. These nodes can store and manage the interactive data between edge nodes. In our system, these institutions can be edge servers, routers, switches, integrated access devices (IADs), and other devices close to the terminal. In addition, each institution is considered to be a blockchain member in alliance blockchain network. In our framework, each institution is a semitrusted party. Nodes in an organization are trusted, in other words, all nodes in an edge network trust each other, but devices from other organizations are not trusted. This characteristic of the alliance chain is well in line with the situation where there is no centralized management of different heterogeneous hardware in the edge computing environment.(2)The mobile user is the owner of the data. They belong to different agencies and want to share data through these agencies.(3)Nodes are controlled by blockchain members. They run several different algorithms to maintain a common ledger that records all verification information.
4.3.2. Edge Controller Layer
The second layer is the edge control layer. This layer is composed of multiple edge clouds and edge nodes, providing end users with diversified edge services (such as real-time data processing in public safety, intelligent networked vehicles and autonomous driving, VR, industrial Internet of things, smart home, and other applications) and related data storage and management services. As shown in Figure 5, five edge clouds Org1, Org2, Org3, Org4, and Org5 distributed in different geographical locations have established mutual trust connections with each other, and each edge cloud provides different edge services for end users. A more important function is that all members jointly maintain a blockchain database that provides public audit services for end users at the user level. Finally, they manage the migration scheduling on all edge servers and clusters on the WAN. The edge service scheduler at this layer is responsible for scheduling offloading services across edge servers or clusters. The scheduling parameters include but are not limited to the following 4 items: (1) the physical location of the edge server; (2) performance data collection of edge servers and service migration decisions; (3) bandwidth and latency perceived by the terminal user; and (4) the authentication service is used to verify the identity of the edge server and the terminal user.
4.3.3. User Layer
The third layer is the end user. End users are Linux mobile devices running mobile applications on Android, iOS, Windows, or other platforms. Users register at this layer and upload the edge services and data they share and use. The migration process of edge services is transparent to end users, and mobile devices can use WiFi or LTE to access edge nodes or edge controllers.
4.3.4. Security Attributes
The Falcon framework meets the following security features:(1)Confidentiality of data: shared data are not visible to blockchain nodes. In our solution, the blockchain node maintains a blockchain database that records shared data verification information. Nodes should verify the correctness of the shared data, but they should not get real data.(2)Anonymity: data owners want to share data without disclosing their true identities because the data may contain personal privacy information. To protect user privacy, data should be shared anonymously.(3)Traceability: in some cases, when the edge service is maliciously attacked and tampered with, the manager at the edge control layer can track the true identity of the malicious user.(4)Publicly verifiable: all users can verify the integrity of the shared data without the need for a trusted third party.
4.4. PBFT Algorithm
In order to prevent malicious nodes from attacking during the service migration process in the MEC environment, and to avoid blind trust in the integrity assurance claimed by cloud operators, the blockchain network adopted by our proposed Falcon framework is based on the alliance chain. However, the traditional consortium chain mostly uses the PBFT algorithm as the basic consensus algorithm [43, 44], which uses a three-stage submission process to be divided into preprepare, prepare, and commit. As shown in Figure 6, the consensus process of the PBFT algorithm [45] in a view is mainly divided into the following steps:(1)The client initiates a consensus request to the master node of the consensus network(2)When the master node receives the request from the client, it broadcasts the request to other replica nodes through the network(3)All replica nodes need to perform a Prepare and Commit process between each other(4)All replicas need to execute the request and reply back to the client(5)Because the maximum number of Byzantine nodes in the network is f, the client needs to wait for f + 1 different nodes to return the same result before confirming that the entire network reaches a consensus
4.5. Analysis and Improvement of PBFT Algorithm
From a detailed analysis of the PBFT process, it can be seen that the existing PBFT algorithm has the following deficiencies:(1)The client only sends requests to the master node. If there are too many request messages, the master node may be overloaded and the availability will be reduced, which is not suitable for the P2P network environment of the blockchain.(2)Although the checkpoint protocol solves the recovery of certificate information to reduce memory overhead. However, the certificate is cleared after regular negotiation through the network-wide consistency process. This process is carried out in a three-stage submission process, which will cause a lot of unnecessary communication waste.(3)The PBFT algorithm does not have a relatively complete data backup and synchronization process. As time goes by, the data between different nodes are relatively large.
To sum up the three reasons, the three-phase commit protocol of PBFT requires a relatively large network transmission and communication overhead, which needs to be further optimized. We use the improved PBFT algorithm (IPBF algorithm). Make the following changes:(1)Modification of the checkpoint protocol: this paper clears the certificate based on the timestamp of the best block in the blockchain. The improvement we propose is to clear the block from the timestamp of the best block in the blockchain. The blockchain is connected in the form of a linked list according to the generation time of the block, so a certificate before a block timestamp has been verified, and the relevant status of the node has been broadcast and can be cleared. We can listen on the block addition event. When a block is added to the blockchain, the certificate before the block timestamp in the node is cleared. This clearing process does not require nodes to communicate with each other, and it can also ensure that the certificates are cleared in time, thereby reducing communication overhead. Fundamentally, it improves block throughput.(2)Change the client’s single point submission request to the master node, and broadcast the signed transaction data to the entire network. This way is more suitable for P2P environment.(3)Add data synchronization and verification process, and perform data synchronization after the master node election is completed. During synchronization, the slave node verifies the synchronization data. If the verification is passed, the new master node is officially recognized and the next consensus process begins.
5. Experiment and Result Analysis
In this section, we introduce experiments and result analysis. In the designed simulation experiment, an edge service migration experiment was performed on the Falcon framework to evaluate the effectiveness of the migration algorithm and further compare it with the service migration based on the docker container. Secondly, the improved blockchain is used to compare throughput by sending batch transactions and creating accounts and compare the experimental results with Ethereum, which has not improved the BPFT consensus algorithm.
5.1. Experimental Settings
This research is to simulate the migration framework in part of the server clusters in the China National High Performance Computing Center (Xi’an). The cluster server configuration information is shown in Table 1. The cluster includes three types of server nodes with different computing resource configurations to simulate devices with different node performance in the edge network. Among them, the type A server has the highest CPU and memory resource configuration, the type B server has the lowest CPU and memory resource configuration, and the type C server has medium CPU and memory resource configuration. We use three A and B servers and two C servers.
5.2. Experimental Design
We implemented a Falcon prototype system to simulate the migration of edge services composed of a group of mobile agents from one host to another. The framework uses IBM Aglet (Aglet, 2016) as a mobile agent development platform. Aglet is a mobile agent program written in pure Java language for building mobile agent applications. A mobile agent is an executable program that runs in a specific environment. After creation, it can be deployed, migrated, executed, and finally destroyed after the task is completed. Technically, the aglet mobile agent can be executed on any information host that supports the Java virtual machine. The aglets server (called Tahiti) [22] is installed on the remote host, and it provides the aglet execution environment for any mobile agent to reach the local machine. As mentioned in the model in the previous section, Falcon built an event decision management program (EDS), resource management program (RMS), and a data management service program (DMS), and finally , we have developed a decentralized blockchain trust management service, which has a trust authorization mechanism. Aglets can communicate with other aglets, and different agents use the message interaction method provided by the agent to communicate.
In the Falcon framework, the service migration decision is made by EDS, and a group of services is migrated through the migration decision algorithm. As shown in Table 2, 8 mobile agents A1, A2, …, …, A8 are created in a service group, and each agent belongs to a different type. These agents are assigned to corresponding information hosts that meet the requirements to provide users with edge services. We assume that these 8 agents are initially executed on the same host. Their constraint rules include the following:(1)A1, A2, and A3 are cooperative in information processing and must be migrated to the same information host(2)The function of A4 depends on A5 and A6(3)A7 and A8 are atomic operations due to security considerations and run separately (data management library service, database connection provided)
5.3. Edge Service Migration Time Comparison
In order to compare the efficiency of agent-based service migration time, we compare it with the current advanced docker container migration technology. Docker container migration is based on the user-level process checkpoint and recovery tool CRIU (Checkpoint/Restore In Userspace) [20]. We use CRIU to checkpoint the process, freeze the running container process, and then transfer the status data to the destination host for recovery. CRIU also provides a structure called action script, which allows any script to be executed before the container is selected and thawed. Therefore, we design a callback method in the action script to restore the container state. In the test equipment list in Table 1, we have 8 servers under the Type A server list, and the docker container running on each server contains video analysis and face recognition programs. The video parsing and face recognition programs were compared through the two methods of mobile agent and docker container migration, respectively. By using Wondershaper, different bandwidths for testing were adjusted to simulate different network conditions of edge services. The experimental use case is as follows:(1)Face recognition: we designed a face recognition service as an edge service, using OpenCV [46] to identify images. This service can identify the facial attributes (expressions, ages, genders, etc.) of people on pictures by calling api. Since end users are mobile users, dynamic changes in mobile computing resources are one of the factors that affect user QoS. In addition, when the user moves, the quality of service and network conditions will change, and the communication process needs to maintain ultra-high reliability.(2)Video streaming: considering different user needs, user mobility, and dynamic network environment, we have prepared video decoding services. Due to the different video definitions under different resolutions, the requirements for decoding are also different. We use three different resolution edge services, namely, high, medium, and low. When the user moves, the edge device node judges whether to perform task migration according to the service quality, and the solution of task migration. For example, when the user moves to another edge node and is not sure of long-term or short-term stay, the low-resolution video decoding task can be migrated first. In the case of long-term user stays, high-resolution services can be provided to avoid untimely migration and waste of resources.
Figure 7 shows the comparison of the decoding time of video files of different sizes in 3 resolutions. It can be seen that it takes more time to decode video with high resolution and high quality of service. This is because we provide video services with different service qualities for users in different geographical network environments in edge services. Figure 8 shows the comparison of migration time between docker container and agent-based facial recognition in edge services. Due to its lightweight and its own mobile characteristics, mobile agents are more suitable as carriers for edge service migration. By comparison, it is found that agent-based service migration has a shorter migration time than traditional container migration. And when the bandwidth reaches a certain limit, the migration time basically stabilizes.
5.4. Energy Consumption Comparison
Figures 9(a) and 9(b) compares the CPU and memory usage during service migration based on mobile agent and service migration based on docker container. It can be seen that mobile agents are more efficient than docker migration and consume less computing and memory resources. Figure 10 shows a face recognition result seen at the target node after migration. The results show that the agent-based edge service migration adopted by Falcon can make decisions based on system conditions and migrate a group of services to the new edge server, maintaining a high QoS for users.
(a)
(b)
5.5. Security Service Migration Simulation
To test Falcon’s mutual trust establishment and smart contract functions during the migration of multiple edge cloud services, we used the Ethereum platform to build a secure service migration framework. Ethereum is the best development platform for blockchain. For better performance, this article uses Truffle to test the Ethereum framework and uses Solidity language to write smart contracts to achieve trust verification of multiple edge clouds. Finally, run smart contracts on the blockchain. The process of building a smart contract in a security framework is shown in Figure 11.
We have introduced a traceability and verification module for the joining and leaving process of the edge cloud in the blockchain system of Falcon, which is compiled and deployed to the blockchain network. Then use TestRPC to simulate access to the Ethereum environment in the Eclipse platform. Finally, the various functions of the smart contract were debugged under the truffle framework to ensure the security of service migration under multiple edge clouds. Next, we create 1000 accounts and count the time spent by sending transaction requests to test the throughput of the modified blockchain. Specific steps are as follow:(1)Ethereum uses the admin.addPeer (enode) method to connect each edge cloud to form a consortium chain. After starting Ethereum on each node, create an account and address.(2)We use nodejs scripts to send http requests to the blockchain network for account creation and transaction operations. The instructions can contain parameters such as different transaction quantities and observe the resource consumption of the system under different conditions and the TPS performance of the blockchain. TPS value (transaction per second) can be expressed as follows: is the number of transactions processed by the system within the block time and is the block time. It can be seen from formula (5) that the throughput increases as the capacity of each block increases, but as the block capacity increases, the consensus time and network load will also increase. When it reaches a certain level, the throughput will decrease. As shown in Figure 12, when the number of transactions is 7000–8000, the throughput decreases. However, the overall throughput of the blockchain with the original unimproved consensus algorithm has been greatly improved, which can satisfy the mutual trust operation between multiple edge networks.(3)Due to the performance of the machine, the data obtained by only one test have a certain degree of randomness and uncertainty. Therefore, this experiment gradually increases the number of transaction requests in the http request in the test script, performs transaction processing under 1000–10000 cases, and takes the average of the two test results as the TPS performance in this case to find the average. Compare the TPS value. The test process is shown in Figure 12.
Figures 13(a) and 13(b) compare the throughput and time consumption of sending transactions and creating accounts between the EPBFT blockchain system after Falcon’s improved consensus algorithm and the unimproved system. The comparison results show that the blockchain system after the improved consensus algorithm has a higher throughput, which is 23% higher than the average throughput of the alliance chain without the improved consensus algorithm. The main reason is that we have optimized the process of clearing certificates and submitting methods after regular PBFT negotiation. The EPBFT algorithm clears the certificate based on the timestamp of the optimal block in the blockchain, which significantly improves throughput. Obviously, Falcon uses blockchain technology in an edge cloud environment that lacks centralized management of different heterogeneous hardware, which can make the migration of edge services in a dynamic, open, and collaborative MEC network environment more secure and reliable. The Falcon framework we proposed is safer in the absence of a trusted third-party environment and is more suitable for practical applications. It provides a feasible solution for other problems such as computing offloading and edge caching in the future edge computing environment.
(a)
(b)
6. Conclusion
In this work, we first proposed a blockchain-based edge service migration framework Falcon, which uses a group of cooperative mobile agents as the service migration carrier to make the service edge service migration more flexible, and designed a service migration decision-making algorithm, aiming to minimize the cost and better service quality for user service migration. Secondly, with regard to the security of service migration, we present that blockchain technology establishes mutual trust, and multiple edge clouds jointly maintain a consortium chain network to avoid trust and security between edge devices without unified management, providing reliability for edge service migration. Finally, through theoretical analysis and experimental simulation, Falcon is more efficient and has higher service quality than service migration based on docker containers and has great potential as a method for next-generation service migration.
In future work, we are interested in modeling the relationship between Falcon’s work performance, resource consumption, and parameter configuration. Furthermore, Falcon currently does not support any artificial intelligence technology to control operations in different infrastructures, thereby improving the flexibility of the system. The addition of artificial intelligence technology may be an important contribution of Falcon.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the National Key Research and Development Program of China under Grant no. 2017YFB0203003, the National Natural Science Foundation of China under Grant nos. 91630206 and 61672423, and the Science and Technology Programs of Henan Provincial Department of Transportation no. 2019J-2-5.