TaskYou are required to prepare for this Assessment Item by1..docx

Task
You are required to prepare for this Assessment Item by:
1. READING the Subject outline,
2. COMPLETING Topic 2 Project Planning
3. BUILDING your PLAN up from the ProjectTitle and
Abstract in Assessment Task 1
WHAT TO DO:
1. Follow the Study Schedule and work with the Topics in
Interact as they provide a "scaffold" for your learning in this
subject.
2. Develop a detailed Capstone Project Proposal and Plan using
project management software (as listed in the Study Schedule)
and the skills you have acquired from IT Project Management to
develop a project plan with a Work Breakdown
Structure (WBS), milestones and Gantt chart. These tools may
help.
1. MicrosoftProject Pro (http://office.microsoft.com/en-
au/project/);
2. Open source tools like GanttProject
(http://www.ganttproject.biz/);
3. OpenProj(http://sourceforge.net/projects/openproj/)
4. OpenProject (https://www.openproject.org/about).
5. ProjectLibre (http://www.projectlibre.org/)
3. Begin using the 'project blog' as a tool beyond the weekly
progress reportsfor your chosen emerging technology topic:
1. The blog helps you to "think by writing" and also store your
notes, project files and links in a cloud-based service.
2. Consider sharing the site with your peers as a way to tell a
story and harness each other’s knowledge.
4. The blog is ideally updated each week with 3 or 4 entries for
documenting your project notes and as the foundation for
editing and writing the Capstone Project Report. An ideal blog
entry will have around 50-150 words (150-600 words a week).

Presentation
Project Plan Sample Format
(subject to change or modified to include systems development
projects)
1. Title: Emerging Technology and Innovation Topic
1. Project Blog ( Web address provided)
2. Weekly Progress Reports Plan (In class, Discussion Board or
Project Blog entries)
2. Rationale
1. Problem domain
2. Purpose and justification
3. Supervisor Approval
4. Research Questions
5. Conceptual or Theoretical Framework
6. Methodology
1. Analysis of sources of information (EndNote, APA
Referencing Style)
2. Research method(s)
3. Data collection or systems design methods
4. Ethical Issues
5. Compliance Requirements (Workplace, Industry or
Government regulations)
7. Project Plan
1. Deliverables (Annotated Bibliography, Journal Paper, Report,
Seminar)
2. Work breakdown structure (WBS)
3. Risk Analysis
4. Duration
5. Gantt chart

8. References
9. Appendix (if required)
Final project
Formulating Strategic Management Decisions
This final project is based on the following Harvard Business
case study:
Khachatryan, D. (2014). Amarcord Incorporated: Combating
money laundering using data analytics. Harvard Business Case
Study. Retrieved from https://hbsp.harvard.edu/tu/789925b5
Assume your client accepted your urgent business proposal to
design a data-driven approach to effectively accomplish the
goal of fraud detection in financial institutions. Data analytics
for fraud detection in financial institutions is the strategic
management vision of Amarcord Inc.’s Chief Compliance
Officer. Your work in teams is based on the average or
aggregate monthly incoming wire transfer of $500,000 for a
swimwear chain, considered highly unusual by business analysts
for that business chain. In other words, it is impossible for a
business chain of that size to earn such high monthly revenue.
After reading and analyzing the case, each team is required as
part of the final project to address the following:
Identify and address the business problem and explain the need
for a data analytic solution.
Explain the data analytic approach to tackle the business
problem.
Explain the nature and structure of the received data (i.e., the
average monthly revenue of $500,000)

and how data inconsistencies can be resolved.
To what extent is competitive intelligence and ethical standards
relevant to your analysis and solution(s)?
How does cultural diversity impact the problem identification
and or analysis of this case?
Elaborate on all the undertaken modeling and forecasting
strategies.
Emphasize and summarize key findings as well as observations
and recommend further steps that your client should undertake
in the data analysis realm which could potentially lead to
another engagement with your team.
Include how the company could work with various stakeholders
currently and in the future; include desired outcomes.
Address how the organization’s culture influenced the situation
within the case and give recommendations for culture
improvements and your team’s ideas about changes that support
innovation and ethical conduct.
Deliver your project report to provide clear and thorough
answers that both technical and non-technical audiences will
understand.
Your team’s written paper should meet the following
requirements:
Be eight to ten pages in length, plus exhibits or illustrations
Be divided into the following sections:
Identification of business problem and evaluation of the need
for a data analytic solution.
Explanation of the data analytic approach to tackle the business
problem.
Explanation of the nature and structure of the received data
(i.e., the average monthly revenue of $500,000) and how data
inconsistencies can be resolved. Do you agree or disagree with
the business analysts that the aggregate monthly revenue of
swimwear is three times higher than the industry average?
Justify your position.

Evaluation of all the modeling and forecasting strategies
undertaken as brainstorming solutions and so forth.
Summary of key findings as well as observations and
recommended further steps that your client should undertake in
the data-analytic realm, which could potentially lead to another
engagement with your team.
Deliver your project report to provide clear and thorough
answers that both technical and non-technical audiences will
understand.
Support your project with 10 to 12 peer-reviewed articles. Be
formatted according to APA.
Include a title page, introduction, conclusion, and references
page.
A Secure IoT Service Architecture With an Efficient Balance
Dynamics Based on Cloud and Edge Computing
Abstract:
The Internet of Things (IoT)-Cloud combines the IoT and cloud
computing, which not only enhances the IoT's capability but
also expands the scope of its applications. However, it exhibits
significant security and efficiency problems that must be
solved. Internal attacks account for a large fraction of the
associated security problems, however, traditional security
strategies are not capable of addressing these attacks
effectively. Moreover, as repeated/similar service requirements
become greater in number, the efficiency of IoT-Cloud services
is seriously affected. In this paper, a novel architecture that
integrates a trust evaluation mechanism and service template
with a balance dynamics based on cloud and edge computing is
proposed to overcome these problems. In this architecture, the
edge network and the edge platform are designed in such a way
as to reduce resource consumption and ensure the extensibility
of trust evaluation mechanism, respectively. To improve the

efficiency of IoT-Cloud services, the service parameter template
is established in the cloud and the service parsing template is
established in the edge platform. Moreover, the edge network
can assist the edge platform in establishing service parsing
templates based on the trust evaluation mechanism and meet
special service requirements. The experimental results illustrate
that this edge-based architecture can improve both the security
and efficiency of IoT-Cloud systems.
Published in: IEEE Internet of Things Journal ( Volume:
6 , Issue: 3 , June 2019 )
Page(s): 4831 - 4843
Date of Publication: 13 September 2018
ISSN Information:
INSPEC Accession Number: 18757966
DOI: 10.1109/JIOT.2018.2870288
Publisher: IEEE
Funding Agency:
SECTION I.Introduction
The Internet of Things (IoT) is based on a very large number of
objects/things that connect to the Internet to help humans
perceive the world and improve their quality of life [1].
However, there are many IoT characteristics, such as limited
storage and processing capacity, that can reduce the service
performance of the IoT [2]. Cloud computing can address these
limitations associated with the IoT in terms of management,
storage, computation, and processing. Moreover, cloud
computing can create more services by integrating IoT
resources. Due to these advantages, the concept of IoT-Cloud
has been proposed. This concept combines the advantages of the
IoT and cloud computing technologies to provide more and
better services [3]. However, there are still some security and
efficiency problems with IoT-Cloud that must be solved.
The IoT is vulnerable to security threats, especially internal
attacks that frequently occur in the physical device layer and

the network communication layer [4]. Unlike internal attacks,
external attacks can be resisted by traditional security
mechanisms, such as encryption, authorization, and auditing [5].
However, traditional security mechanisms cannot resist internal
attacks effectively, especially in the resource-constrained
IoT [6]. In an internal attack, the attacker is in possession of
some IoT devices and then conducts further attacks using these
captured devices [7]. The trust evaluation mechanism, which is
designed to solve internal attack issues, is an effective
supplement to the traditional security mechanism [8]. However,
many trust evaluation mechanisms in the IoT consume a lot of
resources, which has a large impact on the IoT performance and
lifetime. With increasingly many types of internal attacks
appearing, it is unlikely that the size of the trust evaluation
mechanism will be reduced.
With the increase in the number of IoT-Cloud applications,
increasingly more repeated/similar requirements are sent to the
cloud. It is inefficient for an IoT-Cloud system to address these
requirements one by one and constantly improving hardware
performance is not a long-term solution. In addition, there are
delay issues in IoT-Cloud services since the cloud is far away
from users and the IoT [9]. As failed services also reduce
efficiency, it is necessary to solve some uncertainties in the
IoT, such as device faults, network congestion, and large
environment changes. In order to avoid these situations,
monitoring, and data analysis tasks can be performed, however,
it is not advised to perform these tasks in the cloud.
To solve the above problems, an edge-based IoT-Cloud
architecture with a trust evaluation mechanism and service
template was established. Edge computing is performed at the
Internet’s edge with a lot of computing and storage nodes, such
as gateways, routers, mobile fog nodes, and edge servers, which
are close to the underlying network [10]. Edge computing also
refers to cloudlets, micro datacenters, and fog nodes, which has
advantages in the quick response to cloud services [11], [12].
The edge computing layer in this architecture is divided into

two main parts: 1) the edge network and 2) the edge platform.
The edge network is established on underlying edge nodes
(move/static powerful nodes) and is parallel to the IoT. The
edge platform is composed of edge nodes (edge servers) that lie
between the IoT and cloud, and this platform is a central hub of
the IoT-Cloud service architecture [13].
The main contributions can be summarized as follows.
1. An edge network was adopted to move a large part of the
trust evaluation mechanism out of the IoT. In the IoT, devices
perform the direct trust calculation and send exceptions to the
edge network. The edge network collects trust information from
devices and analyzes this information for the entire trust state
of the IoT.
2. Service templates were established in the cloud and on the
edge platform. The service parameter template in the cloud
stores the matching information while the service parsing
template on the edge platform stores the matching information
and parsing strategies.
3. The trust evaluation mechanism was integrated into IoT-
Cloud services via edge computing. In the process of IoT
service strategy establishment, the trust evaluation mechanism
enables the edge platform to select trusted devices in order to
generate or transfer data. Moreover, the edge network can
monitor the IoT network load with balance dynamics and assist
the edge platform in timely adjusting strategies.
This paper is organized as follows. In Section II, related work is
introduced. The basic concept of a novel architecture is
presented in Section III. Section IV presents the detailed design
of the edge network, the edge platform and the functions in the
cloud. Experiment results and analyses are reported in Section
V. The final section concludes this paper.
SECTION II.Related Work
To address internal attack issues, many trust mechanisms have
been proposed. The trust mechanism plays an important role in
many aspects, such as reliable data fusion and mining, user
privacy protection, information security enhancement, and

service assurance [14], [15].
In some cases, the IoT has both physical and social attributes.
Based on this feature, Chen et al. [16] proposed a trust
mechanism that can select effective feedback through a
similarity filtering method based on friendship, social contact,
and community of interest relationships. Moreover, to minimize
the trust convergence time and resist recommendation trust
attacks, an adaptive filtering technique is designed to find the
best means of combining direct trust and recommendation trust.
To resist attacks aimed at the recommendation trust, such as
bad-mouthing, Alshehri et al. [17] proposed a scalable trust
management solution based on IoT clustering to address
practical and pressing issues. Of course, all storage and
computation tasks are performed by physical IoT devices, which
requires greater energy consumption. Considering trust
derivation, Duan et al. [18] proposed an energy-aware trust
derivation scheme that manages overheads through adopting a
game theoretic approach in the trust derivation process.
However, this scheme only provides partial security, and it is
difficult to accurately measure the level of security.
There are many trust-based intrusion detection systems (IDSs)
in wireless sensor networks (WSNs), which are used to defend
against internal attacks. However, the efficiency of IDS is
reduced on the IoT due to the very large amount of data that is
generated during a short period. Meng et al. [19] proposed a
Bayesian-based trust management method that incorporates
traffic sampling into IDS under a hierarchical structure. Liu et
al. [20] proposed a physical IDS-to-gateway and virtual IDS-to-
gateway detection model that detects attacks against both
physical sensors and virtual sensors (VSs). In IDSs, false alarm
messages cannot be avoided and the intrusion detection
threshold is difficult to set.
To solve data error issues in WSNs, Yang et al. [21] proposed a
data error detection approach via which the cloud can quickly
detect and locate errors in large sensor data sets. Data
collection and transmission is an important part to maintain the

QoS of IoT-Cloud. To ensure trustworthy data collection,
Wang et al. [12] adopted mobile sinks to collect sensor data and
used a CTDC system to evaluate the trustworthiness of both
sensors and mobile sinks. To improve the data transfer
environment, Zhu et al. [22]proposed a trust-assisted sensor-
cloud (TASC) system that selects trusted sensors in WSNs and
trusted data centers in the cloud to constitute the data transfer
route from sensor to user. However, there are still many
problems to be solved in the data trust level, such as time
delays, data level attacks, and data integrity.
In IoT-Cloud, a very large number of connected devices and
services emerge, causing network load issues in the centralized
cloud architecture. To optimize IoT-Cloud services, Barcelo et
al. [23] defined the service distribution problem (SDP) of IoT-
Cloud as IoT-CSDP and solve this problem through linear
programming. For IoT-Cloud services, one single service cannot
meet users’ uncertain requirements. Automatic service
compositing is designed and used to realize automatic matching
of services and requirements with the goal of fulfilling users’
requirements with the least number of IoT-Cloud services. In a
multiple Cloud-based IoT application context, Baker et
al. [24] proposed an optimization algorithm to realize energy-
aware service composition.
Service optimization problems (SOPs)—problems with service
selection and service resource scheduling—are caused by the
increasing number of services and increasing variety of
requirements. Based on service domain features, Xu et
al. [25] proposed a paradigm of service domain-oriented
optimization algorithms with artificial bee colony algorithms to
solve SOPs effectively. For services in IoT-Cloud systems,
there are two issues that deserve more attention to achieve the
goal of green and sustainable development; one is that many
users require the same data from the cloud and the other is that
multiple users request data from the cloud simultaneously. To
reduce the resource cost due to these two issues, Zhu et
al. [26] proposed an MMDD scheme. In the process of IoT-

Cloud systems providing service, many applications require data
from different regions, i.e., a single virtual machine (VM) in a
particular data center needs to integrate many VSs from
different data centers. To ensure high QoS and maintain user
satisfaction, Chatterjee et al. [27] designed an optimal decision
rule for selecting the appropriate data center, which stores a
single VM to serve users.
However, existing schemes have some shortcomings in terms of
security management and service provision, such as one-
sidedness, low expandability, high resource consumption, large
delay, and inefficiency. Moreover, few studies consider the
repeated/similar service issues encountered in many fields, such
as smart transportation, healthcare, and augmented
reality [28], [29]. Edge computing may present a more
advantageous platform for solving these issues via an integrated
approach; edge computing is an affordable and sustainable
computing paradigm to provide many services [30], [31]. For
the design, the edge network can reduce the unnecessary
communication in the trust evaluation mechanism, maintain the
IoT load balance, perform special IoT services, and ensure data
transfer reliability. Moreover, the edge network is more suitable
for mobile IoT. More fine-grained or integrated service
templates are saved in the edge platform, which is flexible and
scalable to an increasing number of IoT services. Moreover,
many trust evaluation mechanisms can be established in the
edge platform, such as the device fault detection, data error
detection, and internal attack detection at the data level because
edge computing has a lower latency and can identify problems
with a smaller computational cost.
SECTION III.Preliminary
A. Trust Evaluation Mechanism
The concept of trust is based on human social relationships.
There is no precise definition for such a thing in IoT-Cloud.
Zhu et al. [22] proposed a definition in the context of wireless
communications.

The trust of a node A in a node B is the subjective expectation
of node A receiving positive outcomes from interaction with
node B in a specific context.
B. Novel Service Architecture
The service architecture of the IoT-Cloud system is divided into
three layers: 1) the data collection layer; 2) the data processing
layer; and 3) the application service layer, as shown in Fig. 1.
In this novel service architecture, the edge network lies in the
data collection layer, the edge platform is located in the data
processing layer and the application service layer, and the cloud
is a part of the application service layer.
Fig. 1.
Typical example for IoT-Cloud service.
View All
The edge network has the following primary advantages.
1. Replacing the recommendation/indirect trust.
2. Balancing the IoT load dynamically and selecting trusted
devices to perform the service by establishing the entire trust
state of the IoT.
3. Executing special user requirements, such as delay, integrity,
and precision.
The edge platform consists of four primary functions.
1. Virtualizing physical devices into virtual devices.
2. Creating the parameter template Templateparameter and the
parsing template Templateparsing in the edge platform.
3. Balancing dynamically the cloud load by providing some
service on the edge platform.
4. Cooperating with the edge network to ensure IoT reliability
at the data level.
The cloud mainly performs the following functions.
1. Parsing user requirements and finding the
related Templateparameter in the cloud, before sending the
special digital information to the target edge platforms.

2. Cooperating with the edge platform to create a
new Templateparsing when there is no
corresponding Templateparsing and storing this
new Templateparameter .
3. Preferentially processing services that have more stringent
demands.
4. Storing a lot of historical data to be used for deeper data
mining and analysis.
C. Three Basic Service Scenes
There are three basic service scenes in which the user
requirements are limited to one IoT, as shown in Fig. 2. Many
mixed-service scenes where the user requirements are based on
multiple IoTs can be expressed as combinations of basic scenes,
for example smart environment applications, such as smart
transportation, healthcare [32], and augmented reality. These
smart environment applications have many users and receive a
large number of repeated/similar requirements.
Fig. 2.
Three types of service scenes. (a) Service Scene 1. (b) Service
Scene 2. (c) Service Scene 3.
View All
In Scene 1, a user requires a service from IoT-1, as shown
in Fig. 2(a). The user enters their requirement in an
application/Web, and then the application/Web sends this
requirement to Edge-1. Edge-1 digitizes this requirement and
checks whether there is a corresponding Templateparameter . If
there is a Templateparameter , the user requirement is
completed by the corresponding Templateparsing in Edge-1. If
not, Edge-1 sends the digitized requirement to the cloud. The
cloud then cooperates with Edge-1 to establish a
new Templateparsing according the specifications of the IoT,
such as its functions, limitations, and precision. Finally, the
cloud sends Templateparameter to Edge-1.

In Scene 2, the required IoT-2 is closer to IoT-1. If Edge-1 has
a Templateparameter for the user’s requirement, the requirement
is completed by Edge-1. Edge-1 sends the special digital
information to Edge-2 and receives service results from Edge-2.
If Edge-1 has no Templateparameter , there are several further
steps to satisfy the user’s requirement, as shown in Fig. 2(b). In
step 1, the user sends the service requirement to Edge-1. In step
2, Edge-1 digitizes this requirement. In step 3, Edge-1 sends the
digitized requirement to the cloud because this requirement is
beyond the capability of Edge-1. In step 4, the cloud
seeks Templateparameter , sends the special digital information
to Edge-2, and informs Edge-2 to communicate with Edge-1. If
there is no Templateparameter , the cloud cooperates with Edge-
2 to establish a new Templateparsing . Finally, Edge-2
communicates with Edge-1 to send the service results to the
user. Edges periodically obtain the
latest Templateparameter from the cloud, or the updating is
triggered by the users’ service requirements.
In Scene 3, the situation is similar to Scene 2 except that Edge-
3 is far away from Edge-1. As there is no Templateparameter in
Edge-1, the requirement is completed by performing many
steps, as shown in Fig. 2(c). Starting with step 4, the following
steps have some differences from those described in Scene 2. In
step 4, the cloud seeks a Templateparameter and sends the
special digital information to Edge-3. If there is
no Templateparameter , the cloud cooperates with Edge-3 to
establish a new Templateparsing. In step 5, Edge-3
executes Templateparsing and returns the result to the cloud.
Finally, the cloud returns the service result to Edge-1.
SECTION IV.Design of the Proposed Novel Service
Architecture
A. Coverage of the Edge Network
The design of IoT in IoT-Cloud systems is usually hierarchical,
as shown in Fig. 3. Moreover, mobile IoTs are also based on
similar hierarchical architectures. It is ideal that the edge

network obtains high effective coverage through fewer edge
nodes in the IoT [33]. There are two means of managing edge
nodes: 1) the fixed mode and 2) the moving mode.
Fig. 3.
Typical example of IoT.
View All
For the fixed mode, edge nodes are placed in fixed positions of
isoheight. However, this mode requires a large number of edge
nodes to achieve high coverage.
For the moving mode, edge nodes have a fixed isoheight moving
range; this mode needs less edge nodes but has slightly weaker
real-time performance. Internal attacks do not occur all the
time, so the moving mode is a good choice in certain situations.
The key issue associated with this mode is determining how to
dispatch edge nodes to move and how to update the trust state
of the IoT in the edge network. As an example, there are three
isoheights and many edge nodes, such as isoheight−1:(D1,D2 ,
and D3 ), isoheight−2:(D4,D5,D6,D7,D8 , and D9 ),
and isoheight−3:(D10,D11,D12,D13,D14,D15,D16,D17,D18,D1
9,D20 , and D21 ). Every inner edge node communicates with
two outer edge nodes, such as D1with (D4 , D5 ), D2 with
(D6 , D7 ), and D4 with (D10 , D11 ). For information
interaction in the edge network, the outer edge nodes perform
interactions prior to the inner edge nodes. In these
circumstances, the inner edge nodes have more comprehensive
knowledge regarding the IoT. The information updating is
periodic or triggered by great changes, such as devices moving
across areas. The general process of information updating is
from the outside to the inside, and the inner node is used as the
information relay point between two further nodes. If there are
abnormal trust states for some devices, inner edge nodes
interact with corresponding outer edge nodes to verify and even
isolate malicious devices.

B. Physical Device Virtualization in the Edge Platform
The virtualization of physical devices is designed to solve the
problem that one physical device cannot be shared by multiple
applications. For virtualization, it is better to prepare a
corresponding virtual device in advance for every physical
device; these virtual devices are stored in the edge platform as
finer-grained resources. As an example of data sharing, when
service parsing templates need to call the physical device, the
edge platform allocates corresponding virtual device interfaces
to these service parsing templates, as shown in (1). The virtual
device sends data to service templates and changes the
parameter settings of physical devices according to relevant
requirements. The key to virtualization is standardization of the
data output format because the data format of physical devices
may be heterogeneous, as shown in (2). A virtual device
receives heterogeneous data and transforms it into a standard
data format. This data is then sent to service templates.
Standardization of the data output format is beneficial for
further data processing, such as aggregation, integration, and
extraction
Devicephysical⇒virtualization⎧ ⎩ ⎨ ⎪ ⎪ Formatdevice−1⋮ Format
device−n⇒access⇒transformationDevicevirtual⇒interface⎧ ⎩ ⎨
⎪ ⎪ Service1⋮ Servicen⎧ ⎩ ⎨ ⎪ ⎪ Device1virtual⋮ DevicenvirtualF
ormatstandard.(1)(2)
View Source
C. Trust Evaluation Mechanism
Table I shows the correspondence relationship between words
and abbreviations.
TABLE I List of Abbreviations
1) Trust Evaluation Mechanism in the IoT:
In the IoT, the main body of trust evaluation mechanism is the
direct trust Tdirect , which is calculated based on evidences
from direct communications among adjacent devices. These
evidences may include the device residual energy, the device

routing failure rate, the device communication success rate, the
device data correctness rate, the device signal strength, and the
device forwarding delay. These evidences can be further
organized into three categories: 1) the general trust evidence; 2)
the network state detection evidence; and 3) the confirmation
trust evidence. In every device, the general trust evidence is
stored in an array Arrayevidences , which is then used to
calculate Tdirect , as
Tdirect=f(xi)=∑i=1nWeighti×f(xi)⎧ ⎩ ⎨ ⎪ ⎪ ⎪ ⎪ EvnormalEvtotal
,w1×EvnormalEvtotal+w2×TEvold,0,if ∣ ∣ TEvold−EvnormalEv
total∣ ∣ <Td1if Td1<∣ ∣ TEvold−EvnormalEvtotal∣ ∣ <Td2else(
3)
View Sourcewhere, Weighti is the weight value of the i th piece
of evidence, which is set according to the importance of the i th
piece of evidence. f(xi) is the trust value of the i th piece of
evidence, whose value is between 0 and 1. n is the number of
needed pieces of evidence, which may vary in different IoT
environment. Evnormal is the normal behavior number of times
for the i th device, whereas Evtotal is the total monitoring
number of times for the ith device. Td1 and Td2 are two
thresholds for the difference value between the old trust value
and new trust state, and w1 and w2 are two weight values for
the old trust value and new trust state, whose values are set
according to the monitoring sensitivity. The smaller the values
of Td1 and Td2 are, the higher the sensitivity is. If the value
of w1 is larger, the value of f(xi) would converge quickly
to (Evnormal/Evtotal) in (3).
The network state detection evidence mainly focuses on how to
reduce device communication pressure and ensure network load
balancing dynamically, such as monitoring the routing failure
rate and the communication collision rate to dynamically adjust
the data transfer route of Templateparsing . When this type of
evidence reveals outliers, they are sent to the edge network as
exceptions.
The confirmation trust evidence refers to seriously abnormal
behaviors that directly trigger the trust state confirmation

procedure in the edge network, such as larger forwarding delays
and frequent communication requests. There are two types of
exceptions that trigger the trust state confirmation procedure:
one is that the difference value shown in (4) is greater
than Td3 (a threshold set by the manager) during the direct trust
calculation, while the other is that the confirmation trust
evidence triggers this procedure
Difference=∣ ∣ Tnewdirect−Tolddirect∣ ∣ .(4)
View Source2) Trust Evaluation Mechanism in the Edge
Network:
The edge network is parallel to the IoT and does not participate
in normal IoT data transfer. In the edge network, there is a table
in every edge node that stores some information about the
devices and trust states, which is used to ensure that the entire
IoT is credible, as shown in Table II. Time in Table II is the
time since the last trust update.
TABLE II Information About Devices and Trust States
There are a set of rules for the execution of the trust evaluation
mechanism in the edge network.
1. The edge network periodically updates and stores the trust
values of every device. The trust values of every device in the
edge network are affected by three aspects: the first aspect is
the trust values in the IoT (when the updating period arrives,
the edge network selects trust values from trusted devices and
calculates the mean trust value for every device); the second
aspect is the exceptions from the IoT (when the cumulative
amount of these exceptions reaches threshold , trust updating
and the trust confirmation procedure are triggered); and the
third aspect is the exceptions from the edge platform (when
such exceptions happen, the trust value of the corresponding
device is temporarily set to 0, and the trust confirmation
procedure is triggered).
2. In the trust confirmation procedure, the edge network
proactively detects the target device’s behavior and monitors

environment information to confirm whether the target device’s
data is unrealistic.
3. For trust values in the IoT, when the updating period arrives,
the edge node obtains trust tables from every device in its
managing scope. Every trust value in these trust tables is
compared with the corresponding final trust value, and trust
values beyond the tolerance range of the corresponding final
trust value are flagged as outliers. If there is a high fraction of
outliers in one trust table, the device is considered to be
malicious.
4. The physical device does not proactively obtain
recommendation trust from the edge network unless there is no
trusted device to transmit data or there is a new device in the
IoT. If the trust value in the physical device is not very
different from the final trust value in the edge network, the edge
network will not change the trust value in physical devices.
5. For isolating malicious devices, the edge node informs
normal devices to remove the route that has malicious devices.
The method of isolating malicious devices using the edge
network is efficient, accurate, and fast.3) Trust Evaluation
Mechanism in the Edge Platform:
The edge platform ensures data credibility at the data level. If
possible, it is more beneficial to collect every physical devices
historical trust values to be used in analyses, such as analyzing
the relationship between the device performance change curve
and the trust value curve, the effect of environment changes on
device trust value and the connection between the load and trust
state for every part of the IoT. Moreover, the edge platform has
the potential to expand further to address the increasing variety
of internal attack types.
Some hidden data attackers may behave normally but produce
incorrect data causing users to make wrong decisions. Detecting
this type of attack is difficult in the IoT because the
establishment of this detection mechanism in the IoT consumes
more resources, such as communication, computation, and
storage. However, the edge platform can use data correlations in

the IoT to address hidden data attacks.
1. Device data redundancy. For obtaining more precisely
integrated and stable data, many IoTs allocate more devices to
monitor the same parameter in a certain area. Thus, data from
different devices fluctuate within a fixed range. In the edge
platform, this data can be picked out and judgments can be
performed when the period of detection arrives, as
Tdevice={1,0,if Tdlower<Datadevice<Tdupperelse.(5)
View SourceThe upper limit, Tdupper , and the lower
limit, Tdlower , can be obtained from the underlying edge node
in this area. If data are out of range, the exception would trigger
the detection mechanism.
2. Device data gradualness. The monitored target has
directionality, which can be orderly sensed by devices in this
direction. The topology of the monitoring area is perceived by
underlying edge nodes and this topology is then sent to the edge
platform. According to the data gradualness and topology, the
edge platform can determine the ideal data model, obtain real
data from devices, and contrast this data with the ideal data
model. If there are many outliers, the corresponding physical
devices are considered malicious.
3. Some impossibilities. In monitoring areas, there are some
barriers that prevent devices from detecting the target although
they are close to the target. Thus, if a device breaks this
impossibility, it is considered malicious.
Of course, there may be many factors that cause the trust
evaluation mechanism to misjudge legitimate devices as
malicious devices, such as sudden changes in the environment,
temporary failure of devices, and attacks against the trust
evaluation mechanism. In most cases, these devices will need to
be analyzed based on their previous and future data to
determine whether they are malicious. If not, it is necessary to
perform trust recovery of these devices via the trust
confirmation procedure.
D. Service

Since the cloud connects different areas together, services in the
cloud can be divided into two categories: 1) local services and
2) remote services. In local services, users’ requirements can be
completed locally by the edge platform, whereas in remote
services, users’ requirements are completed by the cloud or both
the cloud and the edge platform. The selection of local or
remote services is determined by the resource
consumption Conresource and the total time
consumption Contotaltime , as shown in (6). There are several
judgment criteria and these are shown in Table III
Conresource=Contotaltime=Constorageresource∩Conprocessing
resource∩ConbandwidthresourceContransmissiontime+Contrans
fertime+Conprocessingtime.(6)
View Source
TABLE III Judgment Criteria
In the above, Constorageresource is the required storage
space. Conprocessingresource is the required hardware resource
that is used to process data. Conbandwidthresource is the
bandwidth required for the user service. The values of the above
three factors are 1 or 0. If the value of any factor is 0, the value
of Conresource is 0. Contransmissiontime is the time required
for data transmission, Contransfertime is the required transfer
time spent on routes among the user, cloud and IoT,
and Conprocessingtime is the time required for data processing.
To free the edge platform and cloud from addressing the same
or similar service requirements, it is better to create service
templates (Templateparameter and Templateparsing ) in the
cloud and the edge platform. Templateparameter is created in
the cloud and focuses on areas, service types, service
parameters, etc. Additionally, the edge platform
stores Templateparameter to complete local service
requirements. Another type of template in the edge platform
is Templateparsing , which corresponds
to Templateparameter . Templateparsing pays more attention to

the IoT, device, parameter setting, basic service parsing
template Templatebasicparsing ,
etc. Templateparameter consists of three parts: 1) the serial
number of Templateparameter (corresponding to the digitization
of the requirement); 2) the IDcloud (the special serial number
that corresponds to that IDedge in Templateparsing ); and 3) the
execution command (how the cloud sends IDcloud and where
the cloud sends IDcloud ). Templateparsing is composed of
three parts: 1) the IDedge ; 2) the number of strategies
(one Templateparsing may have several strategies); and 3) a
series of commands (the implementation of one strategy). The
service process is presented in Algorithm 1, and the result
processing is rendered in Algorithm 2.
Algorithm 1 Service Process
User’s Requirement
ArrayEdge−1result,Arraycloudresult , Resultintegration // Two
result sets that are in the cloud and Edge-1, respectively
Req→Edge−1 ; // User’s requirement is sent to Edge-1 in these
service scenes
Req→extraction Set(area,rangeparameter,typeparameter,⋯,types
ervice) ; // Edge-1 extracts important information from the
user’s requirement and puts it into Set
Set→digitizationArrayparameter+Resultintegration ; //Edge-1
digitizes Set into a series of numbers that correspond
to Templateparameter , and the integration manner of these
results is stored in Resultintegration
Arrayparameter→lengthLengtharray ;
for i from 1 to LengthArray do //Finding Templateparameter for
every Parameter
if Array[i]∈ Templateparameter and Conresource==1 in Edge-
1 then //Templateparameter is in Edge-1 and Edge-1 can
complete this part
Edge-1 sends IDcloud in Templateparameter to corresponding
Edges;
Edges find Templateparsing according to IDcloud and execute

it;
Edges return results to Edge-1, and Edge-1 stores these results
into ArrayEdge−1result ;
else
Send Array[i] to the cloud;
if Array[i]∈ Templateparameter in
cloud then // Templateparameter is in the cloud
if Cloud.Contotaltime>Edge1.Contotaltime and Conresource==1
of Edge-1 then //Edge-1 can independently accomplish this part
with less time
The cloud sends IDcloud in Templateparameter to
corresponding target Edges;
it;
Edge-1 updates its Templateparameter from the cloud;
else
The cloud sends IDcloud in Templateparameter to
corresponding target Edges;
it;
Edges return results to the cloud, and the cloud stores these
results into Arraycloudresult ;
end if
else //Creating new Templateparameter
The cloud checks specifications of Edges and generate a
new Templateparameter ;
The cloud sends parsing commands and Templateparameter to
target Edges and instructs Edges to construct a
new Templateparsing ;
Edges complete services through the edge network;
if Cloud.Contotaltime>Edge.Contotaltime and Conresource==1
of Edge-1 then

else
Edges return results to the cloud, and the cloud stores these
results into Arraycloudresult ;
end if
end if
end if
end for
Algorithm 2 Result Processing
ArrayEdge−1result,Arraycloudresult , Resultintegration
Service Result
if Edge-1 satisfies Resultintegration then //Edge-1 can perfect
final result processing
Calculating the transmission time of ArrayEdge−1result from
Edge-1 to the cloud, Edge1.Contransmissiontime ; //Method:
removing the common parts of two assumptions, and compare
their different parts
Calculating the transmission time of Arraycloudresult from the
cloud to Edge-1, Cloud.Contransmissiontime ;
Getting the transfer time consumption from Edge-1 to
cloud, Contransfertime ;
if Edge1.Contransmissiontime+Contransfertime<Cloud.Contrans
missiontime then //The expected time consumption in Edge-1 is
larger than in the cloud
Selecting the cloud as the platform for final result processing;
Returning the final result to Edge-1 and user;
else
Selecting Edge-1 as the platform for final result processing;
Returning the final result to user;
end if
else
Selecting the cloud as the platform for final result processing;
Returning the final result to Edge-1 and user;
end ifTheorem 1:
All time complexities in digitization,
Seeking Templateparameter and

Seeking Templateparsing are O(1) .Proof:
The digitization of requirement is correlated with the method of
establishing the table. As an example, assume that the number
of broad categories is M , and the number of subgroupings for
every broad category is a variable N . The maximum number of
lookups is (M+Nmax) , whose time complexity is O(1) . Of
course, there may be many levels, such as level(M,J,I) . In this
case, the total number of lookups is (M+J+I+Nmax), whose time
complexity is also O(1) .
The seeking of Templateparameter and Templateparsing can be
realized by converting from the number to the address of table,
whose time complexity is O(1) . To reduce the size of the data
table, tables are also built in a hierarchical manner, such
as level(A,B,C). In this case, the number of lookups
is (A+B+C) , whose time complexity is O(1) .
Next, the services of IoT-Cloud are introduced in detail from
three aspects as follows.1) Service in the Cloud and the Edge
Platform:
Requniversal⇒extraction⇒match⎧ ⎩ ⎨ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ areatypeser
vice⋮ typeparameter⇒digitizationParameterTemplateparameter⇒
distribution⎧ ⎩ ⎨ ⎪ ⎪ Edge−1⋮ Edge−n.(7)
View Source
User requirements can be divided into two categories: 1)
universal requirements Requniversal and 2) special
requirements Reqspecial . For Requniversal , there is a
corresponding Templateparameter in the cloud or the edge
platform. The execution process of Requniversal is shown
in (7). First, some important information is extracted
from Requniversal and placed into a
set Set(area , typeservice, typeparameter,…, rangeparameter ).
Second, Set is digitized as a Parameter (single service) or a set
of Parameter that are Set(parameter) (combined services).
Third, the cloud or the edge platform locates the
corresponding Templateparameter from its database.
Finally, IDcloud is sent to the corresponding edge platforms.
Every Templateparameter may have several IDcloud that

correspond to several edge platforms. This method not only
reduces the data transfer volume but also shortens the service
parsing time.
There are many notes.
1. The user requirements are from websites or Apps that have
fixed formats.
2. The cloud digitizes important information as a serial number
and seeks an appropriate Templateparameter using this serial
number. Of course, the digitization mostly occurs on the edge
platform.
3. For the distribution, it is better to select high-trust edges.
However, if there are many requirements that are in the waiting
queue, the cloud should select other trusted edges unless the
user has special demands.
4. If there are some new edges, the cloud should create or
update new Templateparameter according to the edges’
specifications.
For Reqspecial , there is no Templateparameter in the cloud or
the edge platform. After digitizing important information about
the users requirement as Parameter, the cloud finds appropriate
edges according to Parameter and the edges’ specifications. The
cloud then generates Templateparameter . Subsequently, parsing
commands and this new Templateparameter are sent to the
corresponding edges. Finally, the cloud guides the edge
platforms to establish Templateparsing . Meanwhile, the service
is finished by the edge network. If there are many edge
platforms that can meet the demands, the cloud will select
trusted edge platforms to complete this requirement. If edge
platforms can finish it, Templateparameter is stored in the cloud
and the edge platform, and Templateparsing is stored in the
edge platform.2) More Services in the Edge Platform:
In different Templateparsing , commands tend to contain a lot
of overlapping parts, so combinations of overlapping parts can
fulfill these commands. These overlapping parts are designed
as Templatebasicparsing ; these Templatebasicparsing constitute
more complex Templateparsing , as shown in (8). Moreover,

these Templatebasicparsing should be variable to address
changing service requirements
⎧ ⎩ ⎨ ⎪ ⎪ ⎪ ⎪ Templatebasic−1parsing⋮ Templatebasic−nparsing
→combinationTemplateparsing.(8)
View Source
There are several notes.
1. Since many applications can share data from one physical
device, the standard state setting of this physical device should
be based on the frequency of requirements.
2. For low-frequency requirements whose state setting norms
are lower than the standard state setting, the data volume can be
reduced to satisfy these requirements. In this manner, the
performance of the edge is guaranteed, and the service waiting
time is decreased.
3. For low-frequency requirements whose state setting norms
are high than the standard state settings, the edge network can
be utilized to perform these services.
These Templatebasicparsing and Templateparsing are stored in
the edge platform. When parsing commands from the cloud are
sent to the edge platform, the edge platform directly finishes
them using the edge network and creates Templateparsing .
When IDcloudis sent from the cloud to the edge platform, the
edge platform directly seeks the
corresponding Templateparsing to finish it.3) Service in the
Edge Network:
Edge computing takes on two important roles in IoT-Cloud
services. The first is that edge computing can maintain the
performance and QoS of the IoT. The second is that edge
computing can execute special tasks without increasing the
communication load of the IoT.
The edge network records the trust states of all devices in the
IoT and these records are used to create data transfer routes.
Moreover, in the process of creating or
updating Templateparsing , the edge network provides the trust
state of every device to the edge platform. The edge platform
creates one or more transfer routes for

every Templatebasicparsingor Templateparsing . When one
transfer route has some problems, Templateparsingadopts other
transfer routes to perform services. Through this method, the
credibility and real-time nature of data can be well guaranteed.
Since edge computing has advantages for performing IoT
functions, the edge network is employed to realize special
services, such as more-real-time services, higher priority
services, and more precise location services.
SECTION V.Evaluation
In this section, the performance of the trust evaluation
mechanism and the service time consumption are described and
discussed.
A. Parameter Settings
The simulation platform is MATLAB R2016b. The experimental
setting consists of four IoTs and one cloud, where every IoT has
an edge platform, and the cloud is located in the middle of the
four IoTs. Edge-2 and Edge-4 are closer to Edge-1, and Edge-3
is far from Edge-1. In every IoT, there are 56 devices. These
devices are randomly distributed in the IoT, and different types
of devices are placed in each IoT for some specific experiments.
Six underlying edge nodes are placed on two isoheights of every
IoT. We set the following: for general IoT services, the transfer
time from the user to the cloud is 26 ms. However, for novel
IoT-Cloud services based on edge (BOE) computing, the
transfer time from the user to the cloud is divided into two
parts: 1) the transfer time from the user to the edge (8 ms) and
2) the transfer time from the edge to the cloud (18 ms). The
transfer time between two adjacent edges is 12 ms. In the
experiment, there are four types of abnormal devices: 1)
temporary fault devices; 2) malicious behavior devices; 3)
general abnormal devices; and 4) malicious data devices. These
parameters are shown in Table IV.
TABLE IV Experimental Parameters

B. Service Time
In this part, the service time consists of three parts: 1) the data
transfer time; 2) the data transmission time; and 3) the data
processing time. For a clear comparison, the service time is
divided into three phases: 1) the service time from the user to
the target edge; 2) the service execution time in the IoT; and 3)
the service time from the target edge to the user.
Symbols and their corresponding names are listed in Table V,
and these symbols are used in the following formulas.
TABLE V Symbols and Their Corresponding Names
1) Service Time From the User to the Target Edge:
There are some differences between service processes of the
general IoT service and the novel IoT service BOE computing.
These differences in the service time are demonstrated by using
three basic experimental scenes and four mixed experimental
scenes, as shown in Fig. 4.
Fig. 4.
Service time from the user to the target edge. (a) Three basic
scenes. (b) Four mixed scenes.
View All
Fig. 4(a) shows that the service time of “service with parameter
template” is shorter than that of “general IoT-Cloud service” in
the basic scenes. The reason is that service with parameter
template avoids repeatedly executing the service parsing
procedure.
For general IoT-Cloud service, the service time is calculated
using (12). In the basic Scene 1, the service time of service with
parameter template is calculated using (9), which
removes Timecommand , T.TimeEdge−1cloud and T.TimecloudI
oT . In the basic Scene 2, the service time of service with
parameter template is calculated via (10), which does not
require relay via the cloud. In Scene 3, the service time of

service with parameter template is calculated via (11), which
has advantages in the process of parsing user
requirements. Timematch spends less time than Timecommand ,
and Timedigi in service with parameter template is similar
to Timeextraction of general IoT-Cloud service.
The total service time in mixed scenes is calculated through the
combination of three basic equations. Service with parameter
template has advantages in shortening total service time relative
to general IoT-Cloud service, as shown in Fig. 4(b)
TimeReqScene1=TimeReqScene2=TimeReqScene3=TimeReqge
neral=T.TimeuserEdge−1+Timedigi+TimematchT.TimeuserEdge
−1+Timedigi+Timematch+T.TimeEdge−1Edge−2T.TimeuserEdg
e−1+Timedigi+Timematch+T.TimeEdge−1cloud+T.TimecloudE
dge−3T.Timeusercloud+Timeextraction+Timecommand+T.Time
cloudIoT.(9)(10)(11)(12)
View Source2) Service Execution Time in the IoT:
The service execution time in the IoT mainly consists of two
parts: 1) the service time from edge to the target
device Timeedgetargetdevice and 2) the service time from the
target device to edge Timetargetdeviceedge , as shown in (13).
The service execution time based on the edge network is
minimal because it can more accurately locate the target device
and has shorter routes. The service execution time of “template
with trust evaluation mechanism” is shorter than that of
“template without trust evaluation mechanism” because the trust
evaluation mechanism is more likely to select high-trust devices
to transfer data and can balance the IoT load dynamically.
Moreover, the trust evaluation mechanism can
help Templateparsing create several better data transfer routes
to enhance the service stability. The fraction of low-
performance devices and the degree of network congestion have
certain influences on the service execution time, as shown
in Fig. 5. Since the edge network is located outside the IoT, the
fraction of low-performance devices and the degree of network
congestion have weaker influences on its service execution
time. Template with trust evaluation mechanism selects

appropriate data transfer routes in advance; thus, it can
effectively avoid low-performance devices, as shown in Fig.
5(a). As the fraction of low-performance devices exceeds 50%,
the time consumption obviously increases because template with
trust evaluation mechanism is more likely to select trusted
devices that are in the same level. When considering the
influence of network congestion on the service execution time,
the number of low-performance device is set to 5. The influence
of network congestion on template with trust evaluation
mechanism is slightly weaker than that on “template without
trust evaluation mechanism” originally, as shown in Fig. 5(b),
but the phenomenon begins to reverse after the fraction of busy
devices reaches 50%. The reason for this result is that template
with trust evaluation mechanism tends to select trusted devices
in the peer level to balance the network load
TimeExecutionIoT=Timeedgetargetdevice+Timetargetdeviceedg
e.(13)
View Source
Fig. 5.
Service execution time in IoT. (a) Influence from the number of
low-performance device. (b) Influence from the degree of
network congestion.
View All3) Service Time From the Target Edge to the User:
To calculate the service time from the target edge to the user,
the service data volume and location of the service data
processing center must be considered (edge or cloud). “1+x”
indicates that there is a very large amount of service data, and
“0+x ” indicates that there is a small amount of service data.
Additionally, “x+1 ” indicates that the service data processing
center lies at edge, whereas “x+0 ” indicates that the service
data processing center is situated in the cloud.
For 1+x , the service time consists of the data transmission
time, the data transfer time, and the data processing time, as
shown in (14). For 0+x , the service time is composed of the

data transfer and the data processing time, as shown in (15).
Because the data processing time is changeable, the data
transmission time and the data transfer time are the major
factors considered
Timeresult1+x=Timeresult0+x=Timetransmission+Timetransfer
+TimeprocessingTimetransfer+Timeprocessing.(14)(15)
View Source
0+1: If users’ requirements can be completed in edge, the total
service time of service with parameter template would be
shorter, as shown in Fig. 6. For the three basic scenes, service
with parameter template can obviously shorten the service time
in Scene 1 and Scene 2, as shown in Fig. 6(a), because service
with parameter template avoids relay via the cloud. The service
time of service with parameter template in Scene 3 is almost
equal to that of general IoT-Cloud service. For the four mixed
scenes, the total service time of service with parameter template
is shorter than that of general IoT-Cloud service because Scene
1 or Scene 2 is in the mixed scenes, as shown in Fig. 6(b).
Fig. 6.
Service time from the target edge to the user (0 + 1). (a) Basic
scene. (b) Mixed scenes.
View All
0+0: In this situation, the service time of service with parameter
template is almost the same as that of general IoT-Cloud
service. It should not be ignored that edge has certain
pretreatment capabilities and can independently perform part of
mixed services. Moreover, with improving edge performance,
this situation is becoming rarer.
1+1: When the volume of service data influences the total
service time, we perform several experiments to measure the
degree of this influence. This part is related to Algorithm 2. For
the basic Scenes 1 and 2, it is a better choice to select Edge-1 as
the data processing center, as shown in Fig. 7. If the cloud is
the data processing center, there would be additional costs in

the transfer time since the cloud is a relay point. For the basic
Scene 3, if the data volume difference between Edge-3 and
Edge-1 (Edge-3 has more data) has less time
consumption Timetransmission than T.TimeEdge−1cloud , it
would be a better choice that selecting Edge-1 as the data
processing center. This method derives from “Remove the
common parts of two assumptions, and compare their different
parts.” For mixed scenes, we select two mixed scenes in the
experiment, as shown in Fig. 7(c) and (d). The data volume of
the result in the cloud is set as Volumecloud (more data) and
the data volume of result in the edge as Volumeedge ;
otherwise, Edge-1 is the better selection. Only when the data
volume difference
between Volumecloud and Volumeedgeexceeds the threshold
value [the intersection points in Fig. 7(c) and (d)], the data
processing center is the cloud. The threshold value represents
that the time consumption of different parts whose two
assumptions are the same. Mixed Scene 2 + 3 has fewer
advantages than mixed Scene 1+3 in selecting edge as the data
processing center, since the threshold in mixed Scene 2+3 is
smaller than that in mixed Scene 1+3. Other mixed scenes
change the threshold value through adjusting the slope of
“Additional cost in the transmission time (Edge).” The higher
the transmission rate is, the more likely it is that edge is
selected.
Fig. 7.
Service time from the target edge to the user (1 + 1). (a) Basic
Scene 1. (b) Basic Scene 2. (c) Mixed Scene 1 + 3. (d) Mixed
Scene 2 + 3.
View All
1+0: When the service data processing center must be in the
cloud, the service times of both service with parameter template
and general IoT-Cloud services are almost equal. However, with
enhanced edge performance, edge can address more service

requirements in the future.
Note: For some mixed scenes in this novel architecture, their
basic scenes can quickly perform the next service when
completing part of the service.
C. Trust Evaluation Mechanism Performance
In the IoT, there are four types of abnormal devices: 1)
temporary fault devices; 2) malicious behavior devices; 3)
general abnormal devices; and 4) malicious data devices. The
change in the trust value of an abnormal device is measured
after it is detected, as shown in Fig. 8. There are three types of
trust evaluation mechanisms that are used for comparison: 1)
BOE; 2) based on cluster head (BOCH); and 3) general
combined trust (GCT, consisting of direct trust,
recommendation trust or indirect trust). The difference between
the BOE and BOCH trust mechanisms is that the latter belongs
to the IoT and may have multihop distances to the outermost
devices. In the trust evaluation mechanism, there should be
periodic trust updating to ensure the latest network trust state,
and this trust updating period was set to 50.
Fig. 8.
Trust value changes of abnormal devices. Trust value changes
of the (a) temporary fault device, (b) malicious behavior device,
(c) general abnormal device, and (d) malicious data device.
View All
In this experiment, the “mean trust value” is calculated based on
the trust values from all other devices that have interactions
with the abnormal device except for the abnormal discovery
device. The first discovery device performs a trust evaluation of
the abnormal device and generates the “trust value of the
device.” The trust updating in the edge network is triggered by
three types of events: 1) periodic trust updating; 2)
accumulation value exception; and 3) command from the edge
platform. In GCT and BOCH, the discovery device first requests

recommendation values from adjacent devices or cluster heads
when an abnormality is detected. The discovery device then
calculates the final trust value of the abnormal device using
rules, such as basing the calculation on weight.
The temporary fault device returns to normal after a short time
(ten time slots); the trust value change of this device is shown
in Fig. 8(a). “Trust value in the edge network” has no changes
due to fewer exceptions from the IoT. However, the “mean trust
value (BOE)” decreases because the discovery devices update
the trust value of the abnormal device through the direct trust.
In GCT, the discovery device finds and updates the trust value
of the abnormal device, but the mean trust value is greater
because other adjacent devices have not yet detected this
abnormal device. BOCH is similar to GCT except for featuring
a longer delay.
When the accumulation of exceptions exceeds a threshold, the
edge network updates and confirms the trust value of the
abnormal device, as shown in Fig. 8(b). For GCT and BOCH,
the trust value of the abnormal device is approximately 0.4 (no
trust); thus, discovery devices no longer communicate with this
abnormal device. When the trust updating period arrives, the
abnormal device is regarded as a malicious device, and its trust
value is set to 0 throughout the entire IoT.
For the general abnormal device, the execution process of BOE
is similar to that in the malicious behavior detection, as shown
in Fig. 8(c). The general abnormal device still has a higher trust
value, so it can be selected to transfer data. When the trust
updating period arrives, the final trust is calculated.
The malicious data device behaves normally but generates
incorrect data to cause the user to make incorrect decisions; the
trust value change of this device is shown in Fig. 8(d). This
abnormality is difficult to detect unless there are some data
analyses at a higher level. Because it is preferable to not
perform a large amount of data analyses in the IoT, GCT, and
BOCH have few advantages for the detection of malicious data
devices. The edge network is located out of the IoT and can thus

perform these analyses at a higher level without affecting IoT
performance.
The network resource consumption is an important factor in
estimating the performance of trust evaluation mechanism.
Because BOE is out of the IoT, it consumes less communication
resources than other schemes, as shown in Fig. 9. Moreover,
BOE can perform malicious device detection at the data level,
so the trust updating period can be extended to reduce the IoT
resource consumption. For BOCH, its communication resource
consumption is determined by the cluster depth and cluster
member number (a larger depth and more cluster members
require more communication resource consumption). For GCT,
its communication resource consumption is associated with
executing recommendations or indirect trust calculations, which
is influenced by the number of adjacent devices.
Fig. 9.
IoT communication resource consumption.
View All
SECTION VI.Conclusion
The IoT-Cloud system combines IoT and cloud computing and
has gradually become a research hotspot. However, there are
some security and efficiency problems that must be solved in
IoT-Cloud application services. Aiming at overcoming internal
attacks and repeated/similar service requirements, a novel IoT-
Cloud architecture is designed based on edge computing, in
which the trust evaluation mechanism ensures the IoT’s security
and assists the service template in solving service efficiency
problems. The edge computing layer is composed of two parts:
1) the edge network and 2) the edge platform. The edge network
builds on underlying edge nodes that spread over the IoT, which
are responsible for ensuring the IoT’s security and performing
special tasks. The edge platform consists of a set of powerful
edge nodes (edge servers), which perform well at parsing users’
requirements through service templates with a balance

dynamics. Extensive experimental results show that this novel
architecture can greatly improve IoT-Cloud systems service
efficiency and ensure data trustworthiness.
However, for the entire IoT-Cloud system, there is still much
work to be done. Future work will seek to perfect the
architecture and solve other issues through this architecture and
edge computing, such as the IoT service pricing, the service
scheduling, and the service access points setting.

TaskYou are required to prepare for this Assessment Item by1..docx

More Related Content

Similar to TaskYou are required to prepare for this Assessment Item by1..docx (20)

More from bradburgess22840 (20)

Recently uploaded (20)

TaskYou are required to prepare for this Assessment Item by1..docx