1. Introduction
A connection through the Internet can provide a set of computers that share resources and information. The Internet only connects people, but the IoT can connect all things or objects to the Internet [
1]. In other words, because of the widespread application of the IoT, a revolutionary change has taken place from “connecting people” to “connecting everything.” Nowadays, because of the popularity of small computing devices with sensing and communication functions, it can provide more possibilities for realizing related applications of the IoT.
In the past few years, the IoT has been widely used in various fields such as industry, agriculture, transportation, environmental monitoring, and health care. In this case, the IoT has some new features, namely large-scale connectivity, low power consumption, and wide coverage [
1]. Because of the increasing applications of the IoT, the number of IoT devices has increased dramatically. According to the research of Shao et al. [
2], it is estimated that the number of IoT devices will reach hundreds of billions in 2030.
As cellular technology is used in applications related to the IoT, it has a very important impact on the development of wide-area IoT systems [
3]. In order to adapt to unique challenges such as energy, spectrum and signaling overhead, 5G wireless networks have added new enhancements to the communications of CIoT. Especially in the case of low 5G complexity, narrowband radio technology is considered to support the large-scale deployment of low-throughput, low-power devices [
4].
As the technologies of communication become more and more mature, the diversity of application fields and communication requirements is reflected. With the continuous development of conventional technologies and the entry of existing technologies into new application areas, this environment is continuing to develop rapidly. In this case, the emergence of 5G communications represents new opportunities and challenges. The 5G communication support for a large number of devices has truly realized the vision of the global IoT. In addition, because of the focus on the integration of heterogeneous access technologies, 5G may play the role of a unified interconnection framework to promote the development of “things” and the Internet [
5]. With the CIoT, billions of IoT-enabled devices worldwide can connect to the Internet. Advanced CIoT technologies include LTE-M, NB-LTE-M, NB-IoT, and 5G [
6]. The CIoT provides the reliable connectivity required for IoT devices, the global coverage of the IoT, and low-cost hardware.
In terms of value, the CIoT market is expected to grow rapidly at a compound annual growth rate of 27.10% [
7]. Because it has great potential to transform machine-to-machine and machine-to-human communication, many technology companies are investing in the CIoT market. It is predicted that there will be more than 45 billion connected devices in the world in the future, of which 30 billion will be connected through IoT [
7].
A feasible CIoT was proposed by Dama et al. [
8], it can implement mobile edge computing (MEC) and the IoT in a dense cellular network to provide a highly flexible and reliable CIoT platform. In this study, this feasible CIoT platform was applied and named MECIoT (MEC-based CIoT). The advantages of MEC are used in MECIoT and applied in the related applications of IoT. In other words, with the characteristics of MEC, MECIoT can provide IoT-related applications with better performance, better energy efficiency, faster response time, scalability, and better localization accuracy.
Since CIoT is a distributed computing system, it can provide the applications that users need [
9]. In a distributed computing system, PUs located at different locations or at the same location can provide more resources and computing capabilities through their connections and collaborations to obtain greater advantages. However, in many cases, there may be faulty PUs in the distributed computing system, which makes the distributed computing system unable to provide highly reliable services. Therefore, reaching an agreement, such as the time stamp or the location of each PU, in a distributed computing system that may have faulty PUs is one of the core issues of fault-tolerant distributed computing [
10,
11]. With the agreement, many applications can be implemented, such as the task of locating the location of the copied files in a distributed environment [
12,
13], a two-phase commitment can be made in the distributed database system [
14,
15] and the landing task controlled by the flight control system [
16,
17]. The agreement problem has been also studied and applied extensively in diverse areas including control systems, optimization, distributed computing, and emerging areas such as robotics, blockchain, and IoT [
18,
19]. In addition, many applications of CIoT provide users with convenience. But for users, the system must provide better reliability and fluency [
20]. In order to provide a highly flexible and reliable CIoT, MECIoT is used in this research. In MECIoT, many PUs are interconnected. Even if some PUs fail, an agreement of the same value must be reached in MECIoT. This study reconsidered the agreement protocol under the assumption of PU failure in MECIoT. The proposed protocol, CIoT Agreement Protocol (CIoTAP) of MECIoT, can make all normal PUs reach an agreement with the minimum number of data exchanges and the maximum number of faulty PUs allowed. The principle of CIoTAP is to remove the influence of failed PUs by taking the majority of data exchanged with other PUs. As if the lower bound of the number of data exchanges is completed, all the influences of failed PUs are proven to be removed and then the agreement can be reached.
There are six sections in this paper.
Section 1 is an introduction to the background and motivation of this research. In
Section 2, the basic concepts of MECIoT topology and agreement problem will be explained. Then, the proposed CIoTAP will be introduced in detail in
Section 3. In
Section 4, an example will be used to illustrate the operation of CIoTAP. In
Section 5, the optimization of CIoTAP will be proved. Finally,
Section 6 is the conclusion of this research.
2. Related Work
Before solving the agreement problem of MECIoT, the MECIoT network structure needs to be defined first. Then, the basic concepts of the agreement problem will be discussed explicitly.
2.1. The Network Structure
In addition to traditional human-to-human or human–machine communication, the IoT has become a new trend [
21]. In the related applications of the IoT, low-cost sensors, actuators, and other similar devices will automatically generate, exchange and process data, and take actions based on common goals. Many applications can be provided through the IoT, such as healthcare, smart grid, traffic management, smart cities, agricultural systems [
22], environmental monitoring, etc.
The 5G has been marked as the Internet promoter of all people and everything. It is estimated that by 2021, there will be more than 28 billion connected CIoT devices (CIoT PUs), of which more than 15 billion CIoT PUs will be connected from machine to machine. This makes providing IoT communications be one of the most important tasks of 5G.
The CIoT has gradually become one of the key conversion technologies in 5G systems, which allows millions of CIoT PUs to connect to a single base station (BS) [
6]. CIoT technology is a new technology, specifically tailored for CIoT PUs. CIoT PUs are small and can run on battery power or the grid, depending on the deployment mode. They may have a GPS receiver to obtain location information, or they may use cellular signals to determine location. The main connection for these CIoT PUs is through remote cellular signals. The main purpose of this CIoT PU is sensing and reporting. because of the wide range of services and the use of cheap hardware, these CIoT PUs are densely deployed and cover many applications. CIoT with MEC is one of the most developed and popularized technologies in the 5G cellular system. It enables all CIoT PUs to connect to the Internet. The characteristics of CIoT PUs include: low power consumption, support for a longer transmission range, and have been developed to implement IoT in dense and remote areas [
21]. With the increase in deployment density of CIoT PUs and the diversification of related applications, high-reliability services in cellular networks have become increasingly challenging. In this research, the high reliability of deploying CIoT using MEC will be ensured.
In this study, the MEC-based CIoT (MECIoT) is used to provide a highly flexible and reliable CIoT platform. The physical infrastructure of MECIoT used in this study with its densely deployed CIoT PUs is shown in
Figure 1. In
Figure 1, all these CIoT PUs are connected to 5G BS. This connection is called the
Access Network. Then, all 5G BSs are connected to the MEC through the
Transport Network and send the information obtained from the CIoT PU to the MEC PU. Finally, the MEC PU is connected to the
Core Network to transmit the information processed in the MEC PU to the Cloud PU. The structure of MECIoT is shown in
Figure 2. MECIoT contains three tiers:
Access-tier,
MEC-tier, and
Cloud-tier.
The
Access-tier is constructed by CIoT PUs; each CIoT PU is responsible for sensing and reporting sensor data required by CIoT applications.
Figure 3 shows the dense deployment using CIoT PUs. All these CIoT PUs are connected to the BS through the
Access Network. Then, all BSs are connected to the
MEC-tier through the
Transport Network, so that the MEC PUs in the MEC cloud can obtain the data required to provide specific applications. The deployment of CIoT PUs can be divided into two categories: static and dynamic. In static deployment, all CIoT PUs are deployed according to the plan, and CIoT PUs do not need to have mobile capabilities, such as smart grid monitoring, bridge monitoring, and pollution monitoring applications. In dynamic deployment, all CIoT PUs are deployed in an unplanned manner, so CIoT PUs need to have the ability to move. For example, smart transportation systems must be able to grasp the dynamic status of various smart vehicles.
A set of MEC clouds are constructed as MEC-tier. Each MEC cloud is composed of a large number of MEC PUs, responsible for processing the data required by specific applications. Many Cloud PUs form a Cloud-tier, and these Cloud PUs provide cloud users with related services. In an MECIoT, through the use of a large number of CIoT PUs, various types of request data in real life are collected by CIoT PUs. Using these huge request data from all over, a wide range of application services can be provided.
On the whole, MECIoT is constructed based on MEC, where data analysis and processing are performed by the MEC-tier, rather than concentrated on the Cloud-tier. In MECIoT, computing and storage resources are managed by MEC, so MECIoT can provide more and more computing and data storage resources for connected PUs. Based on the above characteristics, MECIoT is an extremely suitable platform for providing various CIoT services and applications.
2.2. The Agreement Problem
In order to provide a reliable CIoT environment, a mechanism that allows a given set of PUs to reach agreement on common values is needed. The mechanism for reaching agreement has been named as agreement problem by Lamport et al. [
23]. In a distributed computing environment, because some PUs may fail, in order for the distributed computing to be executed correctly, a number of independent PUs are required to reach an agreement. That is, the purpose of reaching an agreement is to make the normal PUs achieve a common value.
The
agreement problem was formally defined by Meyer and Pradhan [
24] in 1911. Solving the agreement problem defined by Meyer and Pradhan is to find a protocol that can reach an agreement and use the minimum number of data exchanges to obtain the maximum number of allowable failure capabilities. Most past researches proposed various protocols to solve the agreement problem underlying various network structures and applications. All of them could not be replaced with each other because the network topology and elements of the network are different. In other words, the network structure of MECIoT is more complicated than before, the protocol of reaching agreement underlying MECIoT should be restarted. The definition of agreement issues in MECIoT is to make the normal PUs in MECIoT reach an agreement. In order to achieve the purpose of the agreement problem, each PU chooses an initial value as the start, and communicates with each other through data exchanges. If the following two conditions are met, then the PUs can reach an agreement [
24]:
In an MECIoT, it is composed of many PUs (including CIoT PUs, MEC Pus, and Cloud PUs), and some PUs may not always operate normally. If the PU can follow the protocol specification during the execution of the agreement protocol, it means that the PU is normal. Otherwise, the PU is considered to be faulty. When a PU fails, the behavior of the failed PU is unpredictable and arbitrary. Therefore, the data sent by the faulty PU can be random or arbitrary. In this research, the agreement problem of failed PUs in MECIoT will be solved.
However, in the MECIoT, the characteristics of the connected topology are very important. Therefore, to solve the agreement problem on the MECIoT, the following assumptions are made in this research:
Each PU in MECIoT, including CIoT PU, MEC PU, and Cloud PU, can be uniquely identified.
According to the research of Fisher and Lynch [
11], in a distributed computing system with
n PUs (
n ≥ 4), at most one-third of the PUs can fail, but the system will not be interrupted.
The sending PU of the data can always be identified by the receiving PU.
According to the assumptions of this research, the proposed protocol CIoTAP can use the minimum number of data exchanges and can tolerate the maximum number of allowable failure PUs, so that each normal PU can still reach an agreement under MECIoT.
3. The Proposed Protocol
In this study, agreement problem will be discussed in MECIoT, and there is no PU delay in our discussion. Therefore, when the proposed CIoTAP is executed by all PUs, each PU will receive data from other PUs within a predictable time. If the PU cannot receive the data on time, it means that the data must be affected by the failed PU.
According to the research of Fisher and Lynch [
11], in order to solve the
agreement problem, the allowable number of faulty PUs is determined by the total number of PUs in the system. In the protocol of Lamport et al. [
23], all normal PUs can reach an agreement, the condition that must be met is
n > 3
f, where
n is the total number of PUs and
f is the total number of allowable faulty PUs in the distributed system.
In this research, CIoTAP is proposed to solve the
agreement problem that PUs may fail in the MECIoT. Based on the three tiers of MECIoT, the proposed protocol CIoTAP is divided into three parts. According to the three tiers of MECIoT, the execution steps of CIoTAP are shown in
Figure 4.
In order to effectively execute CIoTAP, CIoT PUs in MECIoT are used to sense and obtain sensor data required by the specific CIoT applications. Then, the sensing data is transmitted to the corresponding MEC cloud in the MEC-tier. In CIoTAP, the MEC PU first receives the sensing data transmitted from the CIoT PU, and obtains the majority value of the received sensing data. The majority value of the received data is used as the initial value (vi) of the MEC PU to execute the function Agree ( ). When the agreement value of each MEC cloud is obtained, the value is expressed as the result of a specific service. Finally, the agreement value is transferred to the Cloud-tier by the MEC PU. In CIoTAP, the main job of Cloud PUs in the Cloud-tier is to collect the results of different specific services, and then obtain the request vector of the agreement to provide an integrated service center for various CIoT-related applications.
CIoTAP is initiated by the CIoT PUs of Access-tier to get the sensing data of the specific application service. In CIoTAP, the function Agree ( ) will be used. The function Agree ( ) includes two stages, one is the Data Collection Stage, and the other is the Data Resolution Stage. Function Agree ( ) has three parameters, namely σ, vi, and nA, where σ is the times required to perform the Data Collection Stage, vi is the initial value of PUi, and nA is the total number of PUs participating in the agreement. In order for all normal PUs to reach an agreement, each PU must collect enough exchanged data from all other PUs. In other words, the data received through the data exchanges will help the normal PU to collect enough exchanged data for the subsequent Data Resolution Stage.
The ⌊(
n − 1)/3⌋ + 1 has been proved by Fischer and Lynch in 1911 to be a necessary and sufficient number of data exchanges to solve the agreement problem, where
n is the total number of PUs in the distributed network [
11]. According to the research results of Fischer and Lynch, ⌊(
n − 1)/3⌋ + 1 times of data exchanges are the lower bound to solve the agreement problem. Therefore, when the MEC PU executes function
Agree ( ), the times of executing (σ) is ⌊(
nMj − 1)/3⌋ + 1, where
nMj is the number of MEC PUs in the MEC cloud
Ej of the
MEC-tier, and
nMj > 3. Similarly, when a Cloud PU executes the CIoTAP function
Agree ( ), the required time σ is ⌊(
nC − 1)/3⌋ + 1, where
nC is the number of Cloud PUs in the
Cloud-tier, and
nC > 3.
The data received during the
Data Collection Stage will be stored in a data structure called
data collection tree (
dc-tree), which is similar to the data structure proposed by Bar-Noy et al. [
25]. During the execution of CIoTAP, every normal PU will maintain such a
dc-tree. In the first time of the
Data Collection Stage, PU
i transmits its initial request to other PUs. In this study, it is assumed that each receiver PU can correctly identify the sender of the request. When a normal PU receives a request sent from PU
i, it will store the received value (denoted as
dc (
i)) in the root of its
dc-tree. In the second time, each PU transmits the root value of its
dc-tree to all other PUs. If PU
1 sends a request
dc (
i) to PU
2, PU
2 stores the received request (denoted as
dc (
i1)) in vertex
i1 of its
dc-tree. Similarly, if PU
2 sends a request
dc (
i1) to PU
1, the received request will be named
dc (
i12) and stored in vertex
i12 of PU
1′s
dc-tree in the third time. A request
dc (
i12…n) stored in the vertex
i12…n of the
dc-tree indicates that the request just received was sent through PU
i, PU
1… PU
n; PU
n is the latest PU that passed the request. When a request is transmitted through a PU multiple times, the name of the PU will be repeated accordingly. In order to avoid the repeated influence of faulty PUs in the
dc-tree, vertices with duplicate PU names will be deleted. In short, the root of the
dc-tree is always named
i to indicate that the storage request was sent from PU
i in the first time; the vertex of the
dc-tree is marked by a list of PU names. The PU name list contains the name of the PU through which the stored request is transmitted. An example of a
dc-tree is shown in
Figure 5.
The
Decision (
i) function is used by all normal PUs to eliminate the impact caused by the faulty PU and obtain the decision value in the
Data Resolution Stage of CIoTAP. The function
Decision (
i) will be applied to the root of the
dc-tree corresponding to each PU, and then the value
Decision (
i) will be obtained.
Figure 6 shows the proposed CIoTAP.
4. An Example of CIOTAP Executed the Proposed Protocol
In an MEC-based MECIoT, through a combination of a large number of CIoT PUs with different functions, it is possible to collect sensor data required by various application services, then a wide range of application services can be provided. For example, the MECIoT used in this study can be used in an environmental monitoring system to prevent debris flow hazards. In MECIoT, the sensing data of different CIoT PUs within the coverage of the BS in the
Access-tier is sent to the corresponding MEC cloud in the
MEC-tier, and this data is processed by the MEC PU in the specific MEC cloud. The MEC PUs in each MEC cloud collect the relevant monitoring information of different BS coverage areas, and then analyzes and judges the data collected in each MEC cloud. Finally, the status of the different coverage areas of the BS is sent to the disaster prevention center in
Cloud-tier. Figure 7 is an example of a rock flow disaster monitoring system constructed by MECIoT.
In CIoTAP, within the coverage of a specific BS in the
Access-tier, the CIoT PU obtains the sensing data of the application service and sends it to the MEC cloud of the corresponding
MEC-tier. For example, within the coverage of a specific
BS1, there are six CIoT PUs that obtain sensing data of 1, 0, 1, 1, 1, and 0, respectively.
Figure 8 is an example of the coverage area of a specific
BS1.
An example of the specific PUs in the MEC cloud
E1 performing CIoTAP is shown in
Figure 9. Each MEC PU in the MEC cloud
E1 receives the sensing data transmitted from the CIoT PUs within the coverage of the specific
BS1. When the MEC PU receives the sensing data sent by the six CIoT PUs, these data will be calculated by the MEC PU with majority value (
majority (1,0,1,1,1,0) = 1). Next, the function
Agree ( ) is executed, and this majority value (1) is used as the initial value (
vi) of the MEC PU in the MEC cloud
E1. Then, the required times of executing
Data Collection Stage (σ = ⌊(
nMj − 1)/3⌋ + 1) is calculated, and the function
Agree (σ,
vi, nMj) is executed. The initial value of each MEC PU in the MEC cloud
E1 of the
MEC-tier is shown in
Figure 9a.
In this example, there are six MEC PUs in the MEC cloud
E1, and it is assumed that the MEC PU
e14 is a faulty PU.
Figure 9a is the initial value of each MEC PU in the MEC cloud
E1. In order to obtain the agreement value, two times of data exchanges are required when executing
Agree ( ) (σ = ⌊(
nM1 − 1)/3⌋ + 1 = ⌊(6 − 1)/3⌋ + 1 = 2, where
nM1 is the number of PUs in MEC cloud
E1).
An example of the Cloud PUs in the
Cloud-tier performing CIoTAP is shown in
Figure 10. At the first round of the
Data Collection Stage, each MEC PU of MEC cloud
E1 sends the initial value to all other PUs of MEC cloud
E1, and stores the
nM1 (=6) data received from other MEC PUs at the root of each corresponding
dc-tree, as shown in
Figure 9b. In the second time, each MEC PU sends the data in the root of the corresponding
dc-tree to other MEC PUs in the MEC cloud
E1, and stores the received value in the level 2 of the
nM1 (=6) corresponding
dc-tree.
Figure 9c shows the process of MEC PU
e12 in the
Data Collection Stage, and
Figure 9d shows the process of
e16 in the
Data Collection Stage.
Subsequently, in the
Data Resolution Stage, the function
Decision ( ) is applied to the root of the
dc-tree corresponding to each MEC PU to obtain the decision value. Then, an agreement vector can be obtained by each MEC PU in the MEC cloud
E1. Among them, each element in the agreement vector represents the decision value of each MEC PU in the MEC cloud
E1. The agreement value obtained by the MEC PU in the MEC cloud
E1 can be calculated with majority value through each element in the agreement vector. After the majority value is calculated, the agreement value is obtained by MEC PUs
e12 and
e16, respectively, as shown in
Figure 9e,f. Finally, the agreement value obtained by each MEC PU in the MEC cloud in the
MEC-tier will be transferred to the
Cloud-tier.
In CIoTAP, the agreement value transmitted from the MEC PU in the MEC cloud at the
MEC-tier is received by the Cloud PU in the
Cloud-tier. All agreement values received from MEC PUs in the MEC cloud are calculated as majority value. This calculated majority value is used as the initial value of the Cloud PU when the function
Agree ( ) is executed. The initial value of each Cloud PU in the
Cloud-tier is shown in
Figure 10a. In this example, two times of data exchanges (σ = ⌊(
nC − 1)/3⌋ + 1 + 1 = ⌊(6 − 1)/3⌋ + 1 = 2, where
nC is the number of Cloud PUs in
Cloud-tier) are required when the function
Agree ( ) is executed. In this example, assume that the Cloud PU
c4 is a faulty PU, and there are six PUs in the
Cloud-tier.
At the first round of the
Data Collection Stage, each Cloud PU in the
Cloud-tier transmits its initial value to all Cloud PUs in the
Cloud-tier, and stores
nC (=6) data received from other Cloud PUs in the root of the corresponding
dc-tree. The
dc-tree of each Cloud PU in
Cloud-tier at the first time of
Data Collection Stage is shown in
Figure 10b. In the second time of
Data Collection Stage, each Cloud PU sends the data in the root of the corresponding
dc-tree established in the first time of
Data Collection Stage to other Cloud PUs in the
Cloud-tier, and stores the data that Cloud PU received in the level 2 of the
nC (=6) corresponding
dc-tree. The progress of Cloud PUs
c2 and
c6 in the
Data Collection Stage are shown in
Figure 10c,d, respectively.
Subsequently, the function
Decision ( ) is applied to the root in the
dc-tree of each Cloud PU to obtain the decision value in the
Data Resolution Stage. Each Cloud PU in the
Cloud-tier can obtain an agreement vector, and each element in the agreement vector is obtained by the function
Decision ( ). Each element is used in the agreement vector to represent the request of a specific application. The agreement vector of Cloud PUs
c2 and
c6 are shown in
Figure 10e,f respectively. In the end, the agreement is reached in MECIoT. Finally, the services of the rock flow disaster monitoring system constructed by MECIoT can be supported by each Cloud PU in the
Cloud-tier.
5. Verification of The Optimality of CIoTAP
In this section, the optimality of CIoTAP will be verified by mathematical method because the optimality is a theoretical problem. The complexity of CIoTAP will be evaluated based on the following two points, including: (1) the times of data exchange required by CIoTAP is the minimum, and (2) the maximum number of faulty PUs that can be allowed to exist when using CIoTAP to reach an agreement. Through the evaluation of these two factors, CIoTAP is proven to be the optimal solution to the agreement problem under the MECIoT framework.
Theorem 1. The times of data exchanges required to reach an agreement with CIoTAP is the minimum.
Proof. By calculating the times of data exchanges required by each tier of MECIoT, the total times of data exchange times required by CIoTAP can be obtained.
- (1)
Access-tier: In the Access-tier, each CIoT PU passes the received sensor data to the MEC-tier during the Data Collection Stage. Therefore, only one time of data exchange is required.
- (2)
MEC-tier: When CIoTAP is executed, data need to be exchanged only during the
Data Collection Stage. According to the research results of [
26] and [
27], in a distributed system composed of
n PUs, ⌊(
n − 1)/3⌋ + 1 is the minimum times of required data exchanges to send enough data to reach an agreement. Because in the
MEC-tier of MECIoT, there may be faulty MEC PUs. With reaching the agreement problem, each MEC PU in the
MEC-tier must exchange data with other MEC PUs. Therefore, the results of [
26] and [
27] can be applied to this study. In other words, there are
nMj MEC PUs in MEC cloud
Ej of
MEC-tier, and CIoTAP needs ⌊(
nMj − 1)/3⌋ + 1 data exchanges. In the
E-cloud
MEC-tier, CIoTAP must to be executed by each MEC PU in the MEC cloud, where
E is the total number of MEC clouds in the
MEC-tier of MECIoT. Therefore, the times of data exchanges for each MEC PU in all MEC clouds to perform CIoTAP depends on the number of MEC PUs in the MEC cloud.
- (3)
Cloud-tier: As in the discussion of the times of data exchanges required in the
MEC-tier. In the
Cloud-tier, the research of [
26] and [
27] can still be applied. In
Cloud-tier, there are
nC Cloud PUs in
Cloud-tier, CIoTAP needs ⌊(
nC − 1)/3⌋ + 1 times to exchange data. In other words, when there are
nC Cloud PUs in
Cloud-tier, CIoTAP will be executed by
nC Cloud PUs. At this time, each Cloud PU needs to perform ⌊(
nC − 1)/3⌋ + 1 times of data exchange first, and then the agreement is reached.
From the above description, the CIoTAP proposed in this study in MECIoT requires the minimum times of data exchanges when reaching an agreement. □
Theorem 2. In MECIoT, the number of faulty PUs that can be allowed when executing CIoTAP to reach an agreement is the maximum.
Proof. MECIoT is divided into three tiers, so the calculation of the total number of allowable faulty PUs in CIoTAP can be discussed separately through the three tiers of MECIoT.
- (1)
Access-tier: Since the number of faulty CIoT PUs in each coverage area of a specific BS in the Access-tier cannot exceed half, the majority value of the data received by all normal CIoT PUs can be calculated, and this calculated value will be the agreement value in the coverage area of a specific BS. Therefore, nBj > ⌊(nBj − 1)/2⌋ + fBj where nBj is the number of CIoT PUs and fBj is the total number of faulty CIoT PUs allowed within the coverage of a specific BSj at the Access-tier. FA is the total number of faulty CIoT PUs allowed in the Access-tier, FA = where B is the total number of coverage areas of the BSs in the Access-tier, and fBj is the total number of faulty CIoT PUs allowed in the coverage of BSj.
- (2)
MEC-tier: According to the research results of [
11] and [
27], in an
n-PUs distributed computing system, the condition to achieve the agreement problem is
f ≤ ⌊(
n − 1)/3⌋, where
f is the total number of faulty PUs allowed in the distributed computing system,
n is the total number of PUs in the distributed computing system. Since MECIoT is a distributed computing system, the research results of [
11] and [
27] can be directly applied to
MEC-tier to become
fMj ≤ ⌊(
nMj − 1)/3⌋, where
fMj is the total number of allowed faulty MEC PUs in MEC cloud
Ej and
nMj is the total number of MEC PUs in MEC cloud
Ej. Then,
FM =
, where
M is the total number of MEC clouds in the
MEC-tier of MECIoT, and
FM is the total number of allowable faulty MEC PUs in the
MEC-tier.
- (3)
Cloud-tier: The research results of Fischer and Lynch [
11] can also be directly applied to
Cloud-tier. Therefore,
fC is the total number of faulty Cloud PUs allowed in the
Cloud-tier,
fC ≤ ⌊(
nC − 1)/3⌋, where
nC is the number of Cloud PUs.
By adding the allowable number of faulty PUs in the three tiers of MECIoT, F = FA + FM + fC = + + ⌊(nC − 1)/3⌋, then the maximum number of faulty PUs allowed by CIoTAP can be obtained. In other words, F is the maximum number of faulty PUs allowed by executing CIoTAP in MECIoT to reach an agreement. □
According to Theorems 1 and 2, it is proved that executing CIoTAP in MECIoT requires the minimum number of data exchanges to reach an agreement, and can tolerate the maximum number of faulty PUs. Therefore, the optimality of CIoTAP has been proven.
6. Conclusions
As the IoT is applied in various applications, a large number of IoT PUs need to communicate through wireless networks. According to the comparison of Qi et al. [
21], among general wireless access technologies such as Bluetooth, Zigbee, WiFi, LoRa, and cellular. Cellular is the best choice to provide wireless access with quality of service (QoS) for a large number of IoT PUs [
21]. The comparisons of wireless access techniques for IoT networks are shown in
Table 1.
Because CIoT can provide security between connected PUs [
5]. In order to provide these applications with high security, a highly reliable CIoT environment is required to support these large-scale applications. In this research, a CIoT platform MECIoT that integrates MEC is proposed to improve the flexibility and reliability of the network topology. In addition, the agreement problem is one of the important issues to discuss improving the reliability of the system in a distributed system, and it has been extensively studied. The topology of the network is an important factor that affects the complexity of solving agreement problem. All past protocols may not be suitable to solve the agreement problem of the new MECIoT environment. In this research, CIoTAP is proposed to solve the agreement problem that PUs may fail in MECIoT. According to the proofs of the optimality of CIoTAP in
Section 5, CIoTAP has the following features.
(Feature of Access-tier): nBj > ⌊(nBj − 1)/2⌋ + fBj where nBj is the number of CIoT PUs, fBj is the total number of faulty CIoT PUs allowed within the coverage of BSj at the Access-tier. The condition, nBj > ⌊(nBj − 1)/2⌋ + fBj, is used to describe the number of CIoT PUs within the coverage of BSj in Access-tier.
(Feature of MEC-tier): nMj > ⌊(nMj − 1)/3⌋ + 2fMj where nMj is the number of MEC PUs, fMj is the total number of faulty MEC PUs allowed in MEC cloud Ej of MEC-tier. This feature indicates the number of MEC PUs required to execute the agreement problem in the MEC cloud Ej.
(Feature of Cloud-tier): The (Feature of Cloud-tier) is similar to the (Feature of MEC-tier) that nC > ⌊(nC − 1)/3⌋ + 2fC where nC is the number of Cloud PUs, and fC is the total number of Cloud PUs allowed in the Cloud-tier. This feature, nC > ⌊(nC − 1)/3⌋ + 2fC, is used to indicate the total number of Cloud PUs required by the Cloud-tier to achieve agreement.
The agreement problem has been extensively studied over the past two decades. Many graceful agreement protocols have been proposed with various network topologies [
10,
11,
20,
22,
23,
24,
25,
26,
27,
28]. In [
28], the network topology is Broadcasting Network (BCN); in [
11,
23], the network topology is Fully Connected Network (FCN); in [
10], the network topology is Cloud Computing environment (CC); in [
20], the network topology is the Integrated Fog Cloud IoT (IFCIoT). However, the existence of abnormal PUs in the network topology is assumed by these studies [
10,
11,
20,
22,
23,
24,
25,
26,
27,
28].
Table 2 shows a comparison of these protocols. Among them, only the CIoTAP proposed in this research can be used in a cellular network that implements mobile edge computing and IoT, so that all normal PUs can reach the agreement and provide a highly reliable CIoT platform.
In this study, with actual examples and proofs, it is shown that through the use of CIoTAP in MECIoT, disaster monitoring systems and other CIoT applications can be constructed and provide highly reliable services. MECIoT is a distributed computing system constructed by integrating MEC. Therefore, MECIoT can be widely used in the design and practice of various distributed computing systems to support user-oriented services. Because of the proofs in
Section 5, the protocol CIoTAP proposed in this study can make all normal PUs reach agreement underlying MECIoT. In order to reach an agreement, CIoTAP requires the minimum number of data exchanges and tolerates the maximum number of allowable failure PUs in MECIoT.
In addition, only considering the abnormality of the PU in the agreement problem is not enough to realize the highly reliable MECIoT. In the real world, not only PUs may be abnormal, but also the transmission media may be abnormal. Therefore, our protocol will be extended to reach an agreement in the future when abnormal transmission media or PUs are present at the same time.