International Journal of Innovative Computing, Information and Control ICIC International c!2019 ISSN 1349-4198 Volume 15, Number 2, April 2019 pp. 713–723 THE FIRST PROTOCOL OF REACHING CONSENSUS UNDER UNRELIABLE MOBILE EDGE COMPUTING PARADIGM Shu-Ching Wang1, Wei-Shu Hsiung1, Kuo-Qin Yan1,! and Yao-Te Tsai2,! 1Department of Information Management Chaoyang University of Technology 168 Gifeng E. Rd., Wufeng, Taichung 41349, Taiwan { scwang; s10714902 }@cyut.edu.tw; !Corresponding author: kqyan@cyut.edu.tw 2Department of International Business Feng Chia University 100 Wenhwa Rd., Seatwen, Taichung 40724, Taiwan !Corresponding author: yaottsai@fcu.edu.tw Received June 2018; revised October 2018 Abstract. Mobile Edge Computing (MEC) is an emerging technology that enables computing directly at the edge of the cloud computing network. Therefore, it is important that MEC is applied with reliable transmission. The problem of reaching consensus in the distributed system is one of the most important issues in designing a reliable transmission network. However, all previous protocols for the consensus problem are not suitable for an MEC paradigm. It is the first time an optimal protocol of reaching consensus is proposed for MEC paradigm. The protocol makes all fault-free nodes communicate with each other and collect the exchanged messages to decide a common value. Based on the common value, the protocol ensures all fault-free nodes reach consensus without the influence of unreliable transmission. Finally, we proved theoretically that the proposed protocol can tolerate the maximum number of faulty components and using only two rounds of message exchanges. Keywords: Internet of Things, Mobile edge computing, Cloud computing, Consensus 1. Introduction. In recent years, a new trend in computing is happening with the function of clouds being increasingly moving towards the network edges [1]. Harvesting the vast amount of the idle computation power and storage space distributed at the network edges can yield su!cient capacities for performing computation-intensive and latencycritical tasks at mobile devices. This paradigm is called MEC [2]. The success of the Internet of Things (IoT) and rich cloud services have helped create the need for edge computing, in which data processing occurs in part at the network edge, rather than completely in the cloud [3]. Edge computing could address concerns such as latency, mobile devices' limited battery life, bandwidth costs, security, and privacy [4]. To address the problem of a long latency, the cloud services should be moved to proximity of the User Equipment (UE). The MEC can be understood as a special case of the Mobile Cloud Computing (MCC). Nevertheless, in the conventional MCC, the cloud services are accessed via the Internet connection [5] while in the case of the edge computing, the computing/storage resources are supposed to be in proximity of the UEs (in sense of network topology). Hence, the MEC can o"er significantly lower latencies and jitter when compared to the MCC. DOI: 10.24507/ijicic.15.02.713 713 714 S.-C. WANG, W.-S. HSIUNG, K.-Q. YAN AND Y.-T. TSAI Even so, MEC paradigm still needs to have a higher fault tolerant ability to accomplish di"erent tasks of distributed computation. The protocol of reaching consensus is a method of improving the fault tolerant capability of distributed system. Up to now, there have none related studies involving consensus issue in the MEC paradigm. It is the first time a protocol is proposed to reach consensus underlying MEC paradigm. The consensus problem is defined by Meyer and Pradhan [6]. The solutions of consensus problem are defined as protocols, which achieve a consensus and hope to use the minimum number of rounds of message exchanges to achieve the maximum number of allowable faulty capability. In this study, the solution of consensus problem is concerned in the MEC paradigm. The definition of the problem is to make the fault-free nodes (MEC nodes) in the MEC paradigm to reach consensus. Each MEC node of MEC paradigm chooses an initial value to start with, and communicates to each other by exchanging messages. The MEC nodes are referred to make a consensus if it satisfies the following conditions [6]. Consensus: All fault-free MEC nodes agree on a common value. Validity: If the initial value of each fault-free MEC node ni is vi then all fault-free MEC nodes shall agree on the value vi. In a consensus problem, many cases are based on the assumption of node failure in a failsafe network [7]. Based on this assumption, a Transmission Medium (TM) fault is treated as a node fault, whatever the correctness of an innocent node, so an innocent node does not involve consensus. However, the definition of a consensus problem requires all faultfree nodes to reach a consensus. Therefore, the consensus problem is to be solved on the MEC paradigm within fallible TMs in this study. The proposed protocol is named Reliable Consensus of MEC paradigm (RCMEC). The RCMEC can solve the consensus problem in an MEC paradigm by using the minimum number of rounds of message exchanges (2 rounds, in fact) and increase the fault tolerance capability by allowing the maximum number of malicious faulty TMs. The remainder of this paper is arranged as follows. Section 2 illustrates the topology of MEC paradigm. Section 3 illustrates the concept of the RCMEC. For easy understanding, an example of RCMEC executed is given in Section 4. The complexity of the proposed protocol is explained in Section 5. Finally, conclusions and future works are presented in Section 6. 2. The Topology of MEC Paradigm. The term MEC was first used in 2013 to describe the implementation of services at the network edge [8]. In recent years, user demand for data rates and Quality of Service (QoS) has grown exponentially. In addition, the development of mobile user devices such as smartphones or laptops and the development of new mobile applications are rapidly advancing [9]. A novel architecture of MEC is proposed by Arif and Ejaz [10], as shown in Figure 1. There are three basic components in the architecture. 1) Edge devices include all types of mobile devices (UE) connected to the Internet. 2) Edge cloud is the less resourceful cloud deployed in each of the mobile base station. Edge cloud is responsible for traditional network tra!c control, including forwarding and filtering, as well as hosting a variety of mobile edge applications such as edge health care, smart tracking, and more. 3) Public cloud is the cloud infrastructure hosted in the Internet. The prime objectives of MEC are [10]: 1) Optimization of mobile resources by hosting compute intensive application at the edge network; 2) Optimization of the large data before sending to the cloud; 3) Enabling cloud services within the close proximity of mobile subscribers; THE FIRST PROTOCOL OF REACHING CONSENSUS 715 4) Providing context-aware services with the help of radio access network information. In order to provide a high flexible and reliable platform of IoT, a topology of MEC paradigm is redefined in this study. The topology of MEC is shown in Figure 2. There are three layers in the MEC paradigm: Sensing-layer, MEC-layer and CC-layer. The Sensing-layer is composed of sensor nodes (UEs), which is responsible for sensing the data required by the application. The MEC-layer is constructed by a set of MEC groups; each MEC group is composed of a large number of MEC servers (MEC nodes), responsible for Figure 1. The architecture of MEC proposed by Arif and Ejaz [10] Figure 2. The topology of MEC paradigm 716 S.-C. WANG, W.-S. HSIUNG, K.-Q. YAN AND Y.-T. TSAI the processing of specific information and judgments. The CC-layer is made up of many cloud nodes, which provide cloud users' services. In the MEC paradigm, through the combination of a large number of UEs, various types of requesting data in real life can be collected. These huge requesting data from all over are used, and then a wide range of application services can be provided. In MEC paradigm, data can be analyzed and processed by the MEC-layer instead of being centralized in the cloud computing. By coordinating and managing the computing and storage resources at the edge of the network, more and more connected devices and the emerging needs can be processed by the MEC. When the technological requirements and constraints of the applications are properly fulfilled, it is up to the platform designer to decide whether an endpoint should be served by the cloud computing, the MEC, or an adequate combination of the two at any given time during the service lifetime. Based on the above characteristics, the MEC can serve as a suitable platform for providing key services and applications, including connecting vehicles, smart cities, and shopping centers. In an MEC paradigm, the nodes are interconnected. Reaching consensus on a same value in a distributed system, even if certain TMs in distributed system were failed (inner damage or outer intruder), the protocols are required so that systems still can be executed fault-freely. In this study, a distributed system whose nodes are reliable during the consensus is executed in MEC paradigm; while the TMs may be fault by interference from some noise or a hijacker and results in the exchanged messages can exhibit arbitrary behavior. When all nodes reach consensus in MEC paradigm, the fault-tolerance capacity is enhanced due to the fact that each node can transmit its messages directly even if TM is fault. Actually, the symptom of a faulty TM can be classified into two types: dormant (such as crash, stuck-at, or delay) and malicious. In the event of a malicious failure, the behavior of the faulty TM is unpredictable and arbitrary. The message transmitted by the malicious faulty TM is random or arbitrary. This is the most destructive type of failure and leads to the most serious problems. That is, if the consensus problem can be resolved in the case of a malicious fault, then the consensus problem can also be resolved in other failure modes. Therefore, the consensus problem is revisited with the assumption of TM failure on malicious faults in the MEC paradigm in this study. 3. The Proposed Protocol. In this study, the consensus problem is discussed in an MEC paradigm, and there is no delay of nodes or TMs included in our discussion. Therefore, the nodes executing our new protocol should receive the messages from other nodes within a predictable period of time [11]. If the message is not received on time, the message must have been influenced by faulty components. In this research, RCMEC is used to solve the consensus problem in an MEC paradigm with malicious fallible TMs. With consideration for e!cient consensus, the UEs of Sensing-layer are used to sense the required data of a specific application. And then, a procedure of making the MEC nodes reaching a common value is applied, and the cloud node in CC-layer is used to serve the cloud services. The variables used in this study are set as follows. • Sj is a sensing area of Sensing-layer. • Ej is an MEC group of MEC-layer. • eij is a node in the MEC group Ej of MEC-layer, 1 " i " nEj where nEj is the number of MEC nodes in MEC group Ej of MEC-layer. • TM SEj is the total number of TMs between sensing area Sj of Sensing-layer and the MEC group Ej of MEC-layer. THE FIRST PROTOCOL OF REACHING CONSENSUS 717 • fSEj is the total number of allowable malicious faulty TMs between sensing area Sj of Sensing-layer and the MEC group Ej of MEC-layer. • TM Ej is the number of TMs in MEC group Ej of MEC-layer. • fEj is the total number of allowable malicious faulty TMs in MEC group Ej of MEC-layer. • TM ECj is the number of TMs between group MEC Ej of MEC-layer and the cloud nodes in CC-layer. • fECj is the total number of allowable malicious faulty TMs between group MEC Ej of MEC-layer and the cloud nodes in CC-layer. According to the previous researches [6,7,12-14], the number of allowable faulty TMs in consensus problem is determined by the total number of TMs in a distributed system. In Wang et al.'s protocol [14], the constraint is #(t$ 1)/2% $ 1 faulty TMs where t is the total number of TMs in a distributed system. Therefore, the constraints of the RCMEC as shown in the following. • (Constraint between Sensing-layer and MEC-layer): TM SEj > &(TMSEj $ 1)/2' + fSEj where TM SEj is the total number of TMs and fSEj is the total number of allowable malicious faulty TMs between sensing area Sj of Sensing-layer and the MEC group Ej of MEC-layer. This constraint specifies the number of TMs required between Sensing-layer and MEC-layer. • (Constraint of MEC-layer): TM Ej > &(TMEj $ 1)/2' + fEj where TM Ej is the number of TMs and fEj is the total number of allowable malicious faulty TMs in MEC group Ej of MEC-layer. This constraint specifies the number of TMs required in MEC group Ej of MEC-layer. • (Constraint between MEC-layer and CC-layer): TM ECj > &(TMECj $1)/2'+ fECj where TM ECj is the number of TMs and fECj is the total number of allowable malicious faulty TMs between group MEC Ej of MEC-layer and the cloud nodes in CC-layer. This constraint specifies the number of TMs required between MEC-layer and CC-layer. In this study, RCMEC is proposed to solve the consensus problem with fallible TMs underlying an MEC paradigm. The proposed protocol RCMEC is divided into three parts based on the three layers of MEC paradigm. The progression steps of RCMEC are shown in Figure 3. And, the scenario of RCMEC is shown in Figure 4. Figure 3. The progression steps of RCMEC 718 S.-C. WANG, W.-S. HSIUNG, K.-Q. YAN AND Y.-T. TSAI RCMEC 1. The requests for the application services are sent to the corresponding MEC group of MEC-layer by UEs. 2. The MEC nodes of MEC-layer execute the procedure Pcons. 3. The cloud nodes of CC-layer get the values DEC i received from the MEC nodes of MEC-layer, and take the majority of all the values DEC i's received to reach consensus. Procedure Pcons (for the node eij in the MEC group Ej of MEC-layer, 1 " i " nEj where nEj is the number of MEC nodes in MEC group Ej of MEC-layer) Step 1. The node eij receives the requests sent from UE. Step 2. The received requests are taken as the majority. Step 3. The majority value is used as the initial value (vi) of eij. Step 4. Procedure Mesgat is executed, and then the common value DEC i is obtained. Step 5. The common value DEC i is transferred to CC-layer. Procedure Mesgat (node eij with initial value vi) Message Exchange Phase: Round 1: Node eij broadcasts vi, and then receives the initial value from the other nodes in the same group, and construct vector Vi = [v1, v2, . . ., vn], 1 " i " nEj. Round 2: Node eij broadcasts Vi, receives Vk from node ekj, 1 " k " nEj. Construct a matrix MAT i (Setting the vector Vk in the k-th column, for 1 " k " nEj) Decision Making Phase: Step 1: Make MAJ k be the majority value of the k-th row of MAT i for 1" k " nEj. Step 2: Search for any MAJ k. If ((MAJ k = ¬vi), then DEC i = !; Step 3: else if ((MAJ k = ?) AND (vki = vi), then DEC i = !; else DEC i = vi. Figure 4. The proposed protocol RCMEC In this study, RCMEC is proposed to solve the consensus problem even if the faulty TMs change the transmitted messages to influence the system to achieve consensus in an MEC paradigm. There are two procedures embedded in the RCMEC: Pcons and Mesgat. Procedure Pcons is the core of RCMEC executed by the MEC nodes of MEC-layer to solve the consensus problem. There are two phases of procedure Mesgat : the message exchange phase and decision making phase. In our case, the procedure Mesgat only needs two rounds of message exchanges to solve the consensus problem. In the first round of the message exchange phase, each MEC node eij multicasts its initial value vi through TMs and then receives the initial values of other nodes as well. In the second round, each MEC node eij acts as the sender, sends the vector Vi received in the first round, and constructs a matrix [V1, V2, . . ., Vi], denoted by MAT i, 1 " i " nEj. And then, in the decision making phase, the function MAJ k is used to determine the common value DEC i by taking the majority value of the k-th row of MAT i for 1 " k " nEj. Finally, the common value DEC i will be used to reach consensus for all cloud nodes of CC-layer. 4. An Example of Executing RCMEC. Taking the tra!c control system constructed by MEC paradigm as an example to execute RCMEC is presented in Figures 5-10. The example of MEC paradigm is shown in Figure 5. Firstly, each UE senses the tra!c status. The TM between UE 12 and MEC-layer, and the TM between UE 14 and MEC-layer are THE FIRST PROTOCOL OF REACHING CONSENSUS 719 assumed in malicious fault, and the sensing data of each UE is shown in Figure 6. Then, the sensing tra!c statuses of the specific road intersection are transferred to MEC group E1 of MEC-layer. Because the TM between UE 12 and MEC-layer, and the TM between UE 14 and MEC-layer are malicious failures, the message transmitted by the MEC node Figure 5. An example of MEC paradigm UE 11 UE 12 UE 13 UE 14 UE 15 1 1 1 1 1 Figure 6. The sensing data of each connected vehicle node in the Sensing-layer Step 1: The node e1j receives the requests sent from mobile devices. Step 2: The received requests are taken as the majority. Step 3: The majority value is used as the initial value (vi) of e1j. UE 11 UE 12 UE 13 UE 14 UE 15 Majority e11 1 1 1 0 1 1 e12 1 0 1 0 1 1 e13 1 0 1 1 1 1 e14 1 0 1 0 1 1 e15 1 1 1 0 1 1 e16 1 0 1 0 1 1 e11 e12 e13 e14 e15 e16 1 1 1 1 1 1 The received requests sent from UEs and the majority The initial value of each MEC node Figure 7. The initial value of each MEC node in MEC group E 1 of MEC-layer 720 S.-C. WANG, W.-S. HSIUNG, K.-Q. YAN AND Y.-T. TSAI Step 4: Procedure Mesgat is executed. e11 e12 e13 e14 e15 e16 e11 1 1 1 1 1 1 e12 1 1 1 1 1 1 e13 1 1 1 0 1 1 e14 1 1 0 1 1 1 e15 1 1 1 1 1 0 e16 1 1 1 1 0 1 Figure 8. The vector received in the first round of MEC group E1 of MEC-layer e11 e12 e13 e14 e15 e16 DEC 11 = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 MAJ 11 of MAT 11 e11 e12 e13 e14 e15 e16 DEC 12 = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 MAJ 12 of MAT 12 e11 e12 e13 e14 e15 e16 DEC 13 = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 0 0 1 0 0 0 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 MAJ 13 of MAT 13 e11 e12 e13 e14 e15 e16 DEC 14 = 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 1 0 0 0 1 1 0 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 MAJ 14 of MAT 14 e11 e12 e13 e14 e15 e16 DEC 15 = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 1 1 1 1 1 0 0 0 1 0 0 0 1 1 1 1 1 1 MAJ 15 of MAT 15 e11 e12 e13 e14 e15 e16 DEC 16 = 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 0 1 1 1 0 0 1 0 0 0 1 1 1 1 0 1 1 1 1 1 1 1 MAJ 16 of MAT 16 Figure 9. Constructing MAT1 in the second round and MAJ1 of MAT1 as common value through the malicious damage TMs will be maliciously changed. In Figures 5-10, the messages are represented by bold and italics that indicate the messages had been maliciously modified. THE FIRST PROTOCOL OF REACHING CONSENSUS 721 Step 5: The common value is transferred to CC-layer. The cloud nodes of CC-layer get the consensus values e11 e12 e13 e14 e15 e16 Majority c1 0 1 1 1 0 1 1 c2 0 1 1 1 0 1 1 c3 1 1 1 1 0 1 1 c4 0 1 1 1 0 1 1 c5 1 1 1 1 0 1 1 Figure 10. The consensus value of each node in CC-layer The nodes of MEC-layer execute procedure Pcons. The MEC node receives the requests sent from UEs, and the received requests are taken as the majority. The majority value is used as the initial value (vi) of MEC node. The initial value of each node in MEC group E1 of MEC-layer is shown in Figure 7. Then the procedure Mesgat is executed. In the message exchange phase of the procedure Mesgat, each MEC node communicates with other nodes and itself. Then, the decision making phase will reach consensus among the nodes. In the first round of the message exchange phase, each MEC node eij broadcasts vi, and then receives the initial value from the other MEC nodes in the same group, and construct vector Vi. In this example, the TM between e13 and e14, the TM between e15 and e16 are assumed in malicious fault. Then, the vector received in the first round of MEC group E1 of MEC-layer is shown in Figure 8. In the second round of message exchange phase in procedure Mesgat, MEC node eij broadcasts Vi, and then receives the vectors broadcast by other MEC nodes, and construct MAT i. After that the decision making phase takes the majority value of MAT 1 to construct the matrix MAJ 1, and the common value DEC 1 (= 1) can be obtained for group E1's MEC nodes. The MAT 1 is constructed in the second round and MAJ 1 of MAT 1 as decision value and is shown in Figure 9. Finally, the common value of each MEC node in MEC group E1 is transferred to CC-layer. In this example, the TM between e11 and CC-layer, the TM between e15 and CC-layer are assumed in malicious fault. The cloud nodes in CC-layer receive the common value of each MEC node in MEC group E1, and the majority is taken on the received common values. The majority value is the consensus value of MEC group E1. The consensus value of each cloud node in CC-layer is shown in Figure 10. 5. The Complexity of the RCMEC Protocol. The following theorems are used to prove the complexity of RCMEC. The complexity of RCMEC is evaluated in terms of 1) the minimal number of rounds of message exchanges, and 2) the maximum number of allowable faulty components. Theorems 5.1 and 5.2 will show that the optimal solution is reached. Theorem 5.1. One round of message exchange cannot solve the consensus problem. Proof: Message exchange is necessary. A node cannot derive whether or not a disagreeable value exists in other nodes without message exchanging. Therefore, the consensus problem cannot be implemented. In addition, one round of message exchange is not 722 S.-C. WANG, W.-S. HSIUNG, K.-Q. YAN AND Y.-T. TSAI enough to solve the consensus problem. If node ni is connected with node nm by faulty TM, node ni may not know the initial value in node nm by using only one round of message exchanges. Hence, it is possible to reach a consensus by using one round of message exchanges. Theorem 5.2. The total number of allowable faulty TMs by RCMEC is optimal. Proof: The total number of allowable faulty TMs by RCMEC can be discussed by three parts of MEC paradigm. (1) TMs between Sensing-layer and MEC-layer: Since the number of faulty TMs between sensing area Sj of Sensing-layer and MEC-group Ej of MEC-layer does not exceed half, and the majority value of the sensing data can be determined. FSE is the total number of allowable faulty TMs between sensing area and MEC-group. FSE = !S j=1 fSEj where S is the total number of sensing areas in Sensing-layer and fSEj is the total number of allowable malicious faulty TMs between sensing area Sj and MEC-group Ej. In addition, fSEj " &(TMSEj $1)/2' where TM SEj is the number of TMs between sensing area Sj and MEC-group Ej. (2) TMs in MEC-layer: Since the number of faulty TMs in each MEC group Ej of MEC-layer does not exceed half, and the majority value of the MEC group can be determined, FE is the total number of allowable faulty TMs in MEC-layer. FE =!E j=1 fEj where E is the total number of MEC groups of MEC-layer and fEj is the total number of allowable malicious faulty TMs in MEC group Ej. In addition, fEj " &(TMEj $ 1)/2' where TM Ej is the number of TMs in MEC group Ej. (3) TMs between MEC-layer and CC-layer: Since the number of faulty TMs between MEC group Ej of MEC-layer and CC-layer does not exceed half, and the majority value of the consensus value can be determined, FEC is the total number of allowable faulty TMs between MEC-layer and CC-layer. FEC = !E j=1 fECj where E is the total number of MEC group in MEC-layer and fECj is the total number of allowable malicious faulty TMs between MEC group Ej and CC-layer. In addition, fECj " &(TMECj $ 1)/2' where TM ECj is the number of TMs between MEC group Ej of MEC-layer and CC-layer. In short, the maximum number of allowable faulty components by RCMEC is F = FSE + FE + FEC = !S j=1 fSEj + !E j=1 fEj + !E j=1 fECj . And, F is the maximum number of allowable faulty TMs in an MEC paradigm. 6. Conclusions. In this study, the reliable consensus problem was redefined by the RCMEC protocol in an MEC paradigm. The proposed protocol ensures that all nodes in the network can reach a consensus value to cope with the influences of the faulty TMs by using the minimum number of message exchanges, while tolerating the maximum number of faulty TMs at any time. Our protocol is the first time to visit the consensus problem under the MEC paradigm. Furthermore, only considering TM faults in the consensus problem is insu!cient for the highly reliable MEC. In the real world, not only might TMs be fault, node might be fault. Therefore, our protocol will be extended to reach consensus in a generalized case when faulty TMs or nodes exist simultaneously in the future. Acknowledgment. This work was supported in part by the Ministry of Science and Technology MOST 107-2221-E-324-005-MY3. THE FIRST PROTOCOL OF REACHING CONSENSUS 723 REFERENCES [1] M. Chiang and T. Zhang, Fog and IoT: An overview of research opportunities, IEEE Internet of Things Journal, vol.3, no.6, pp.854-864, 2016. [2] M. Patel, B. Naughton, C. Chan, N. Sprecher, S. Abeta and A. Neal, Mobile-Edge Computing Introductory Technical White Paper, Mobile-Edge Computing (MEC) Industry Initiative, 2014. [3] A. Whitmore, A. Agarwal and L. Xu, The Internet of Things – A survey of topics and trends, Information Systems Frontiers, vol.17, no.2, pp.261-274, 2015. [4] Tadapaneni, N. R. (2016). Overview and Opportunities of Edge Computing. Social Science Research Network. [5] A. R. Khan, M. Othman, S. A. Madani and S. U. Khan, A survey of mobile cloud computing application models, IEEE Communications Surveys & Tutorials, vol.16, no.1, pp.393-413, 2014. [6] F. J. Meyer and D. K. Pradhan, Consensus with dual failure modes, IEEE Trans. Parallel and Distributed Systems, vol.2, no.2, pp.214-222, 1991. [7] M. Fischer, The consensus problem in unreliable distributed systems (a brief survey), International Conference on Fundamentals of Computation Theory, vol.158, pp.127-140, 2002. [8] O. Khalid, M. U. S. Khan, S. U. Khan and A. Y. Zomaya, Omnisuggest: A ubiquitous cloud-based contextaware recommendation system for mobile social networks, IEEE Trans. Services Computing, vol.7, no.3, pp.401-414, 2014. [9] J. Jin, J. Gubbi, S. Marusic and M. Palaniswami, An information framework for creating a smart city through Internet of things, IEEE Internet of Things Journal, vol.1, no.2, pp.112-121, 2014. [10] A. Arif and A. Ejaz, A survey on mobile edge computing, Proc. of the 10th IEEE International Conference on Intelligent Systems and Control, Coimbatore, Tamilnadu, India, 2016. [11] X. Li, X. Chen and Y. Xie, Agreement of networks of discrete-time agents with mixed dynamics and time delays, Mathematical Problems in Engineering, http://dx.doi.org/10.1155/2015/957028, 2015. [12] L. Lamport, R. Shostak and M. Pease, The Byzantine generals problem, ACM Trans. Programming Languages and Systems, vol.4, no.3, pp.382-401, 1982. [13] M. J. Fischer and N. A. Lynch, A lower bound for the time to assure interactive consistency, Information Processing Letters, vol.14, no.4, pp.183-186, 1982. [14] S.-C. Wang, S.-C. Tseng and K.-Q. Yan, To achieve optimal trustworthy agreement in the unreliable mobile cloud computing environment, ICIC Express Letters, Part B: Applications, vol.8, no.6, pp.937-943, 2017. [15] W. Shi and S. Dustdar, The promise of edge computing, Computer, vol.49, no.5, pp.78-81, 2016. [16] Tina, F. (2020). A Comparison of Execution Mechanisms: Fog and Edge Cloud Computing.