Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
J Grid Computinghttps://doi.org/10.1007/s10723-019-09485-z
Cloud-Based Multi-Agent Cooperation for IoT DevicesUsing Workflow-Nets
Yehia Kotb · Ismaeel Al Ridhawi ·Moayad Aloqaily ·Thar Baker ·Yaser Jararweh ·Hissam Tawfik
Received: 9 November 2018 / Accepted: 31 May 2019© Springer Nature B.V. 2019
Abstract Most Internet of Things (IoT)-based servicerequests require excessive computation which exceedsan IoT device’s capabilities. Cloud-based solutionswere introduced to outsource most of the compu-tation to the data center. The integration of multi-agent IoT systems with cloud computing technologymakes it possible to provide faster, more efficientand real-time solutions. Multi-agent cooperation fordistributed systems such as fog-based cloud comput-ing has gained popularity in contemporary research
Y. KotbDepartment of Computer Science, University of WesternOntario, London, ON, Canadae-mail: [email protected]
I. Al RidhawiSchool of Electrical Engineering and Computer Science,University of Ottawa, Ottawa, ON, Canadae-mail: [email protected]
M. Aloqaily (�)Gnowit Inc., 7 Bayview Road, Ottawa, ON,K1Y2C5, Canadae-mail: [email protected]
T. BakerLiverpool John Moores University, Liverpool, UKe-mail: [email protected]
Y. JararwehJordan University of Science and Technology, Irbid, Jordane-mail: [email protected]
H. TawfikLeeds Beckett University, Leeds, UKe-mail: [email protected]
areas such as service composition and IoT robotic sys-tems. Enhanced cloud computing performance gainsand fog site load distribution are direct achievementsof such cooperation. In this article, we propose aworkflow-net based framework for agent cooperationto enable collaboration among fog computing devicesand form a cooperative IoT service delivery system.A cooperation operator is used to find the topol-ogy and structure of the resulting cooperative set offog computing agents. The operator shifts the prob-lem defined as a set of workflow-nets into algebraicrepresentations to provide a mechanism for solvingthe optimization problem mathematically. IoT deviceresource and collaboration capabilities are propertieswhich are considered in the selection process of thecooperating IoT agents from different fog computingsites. Experimental results in the form of simulationand implementation show that the cooperation pro-cess increases the number of achieved tasks and isperformed in a timely manner.
Keywords Cloud computing · Fog computing ·Petri-net · Workflow-net · Internet of things · Agentcooperation
1 Introduction
IoT devices, both stationary and mobile, providesimple and complex services, especially, in cloudcomputing and big data applications. For instance,
(2019) 17:625–650
/ Published online: 26 June 2019
Y. Kotb et al.
high levels of performance, accuracy, and robust-ness are achieved using IoT robotic devices inreal-time applications such as manufacturing. How-ever, in more advanced IoT-based scenarios suchas ‘search-and-rescue’ [1], complex service compo-sition [2] and exploring new land and water ter-rains [3], pre-programmed IoT robotic devices maynot be able to achieve the requested service due totheir hardware and software limitations. The inte-gration of IoT device communication using tradi-tional and advanced networks (i.e. smart grid net-works [4]) with parallel distributed systems has madeit possible to achieve new complex tasks such aslong-distance medical surgeries and other specializedcases.
Although grid networks integrate communicationand node resources, due to the limitations of mobilenode resources such as computation and storage, IoT sys-tems have moved towards more advanced and emer-ging technologies such as cloud computing and big data[5]. Cloud computing is a data driven technology thatenables storage, computing, analysis, networking, andvisualization of very large data at cloud computingdata centers. Such technology allowed for the designof multi-agent distributed systems that can achievecomplex tasks with high performance levels [6].
Cloud computing has brought great advances, butcloud-based systems have moved away from the tra-ditional centralized approach towards a more sus-tainable and robust distributed scheme as well asenhancing the grid with cloud computing [7]. Fogcomputing has revolutionized traditional cloud com-puting architectures to assure that cloud computingrelated tasks are performed at different fog comput-ing sites [8, 9]. Offloading cloud computing relatedtasks to fog computing devices in a distributed fash-ion not only balances the load among cloud and fogcomputing sites, but can also support service taskachievement with reduced latency and improved ser-vice quality [10]. Fog computing is not an alternativeto cloud computing, but rather provides support. Itwas introduced to solve delay issues for time sensi-tive applications. Fog computing is an intermediatelayer between IoT devices and the cloud datacenter.It extends the traditional cloud computing paradigmtowards the underlying networks by providing lim-ited resources to clients. By bringing the network andcloud computing resources closer to the network edge,substantial amounts of requests can be processed near
the IoT devices instead of sending data all the way tothe cloud datacenter.
Parallel distributed systems incorporate advantagesover traditional systems in terms of performance,design simplicity and task achievement that is deemedimpossible using a single process [11–14]. Coopera-tion is defined as the process of merging and managingresources and capabilities such as sensing, knowledgeand computation power to reach an objective. Theobjective is achieved by having cooperating fog com-puting entities negotiate for IoT device resources andperform task planning and scheduling.
In this article, we address the problem of multi-fogIoT agent cooperation for enhanced task achievement.For instance, if a particular is requested from a set ofIoT devices in one area (i.e. fog computing site), suchthat a fog’s IoT devices’ capabilities are insufficient ormay consume excessive energy and time to perform,then adopting a collaborative approach which relieson other IoT devices in cooperative fog computingsites may achieve the requested service in accordancewith the quality and energy restrictions. An extensionto Petri-nets [15], known as Workflow-nets [16, 17]is used to establish a framework for cooperating fogcomputing IoT agents [18] to achieve tasks by merg-ing and managing the available IoT device capabilitiesfrom different fog computing sites.
The cooperating partners are selected from differ-ent fog computing sites based on the task coveragethey maintain in which properties such as device capa-bilities and whether device agents can collaborativelyachieve the required task on time are considered.The presented work fits well within multi-objectivemulti-device scenarios such as IoT robotic systemsthat may require usage of IoT robot device capa-bilities which are not available in their surroundingenvironment, but rather may be available at differ-ent locations. For instance, assume that a set ofcollaborative IoT drones are available in a certainlocation and are capable of communicating with fogdevices available at a certain fog computing site asdepicted in Fig. 1. Assuming that the drones areincapable of completing the task due to a resourceconstraint such as the lack of computing capabili-ties or the lack of power availability. The fog deter-mines that another IoT device (or set of devices)at other collaborative fog computing sites are ableand willing to cooperate with the drones to achievethe requested service. Therefore, the new cooperating
626
Cloud-Based Multi-Agent Cooperation for IoT Devices
Cloud Layer
Fog LayerFog
Nodes
FogNodes
IoT DeviceLayer
Fig. 1 Merging and managing IoT device capabilities at different fog computing sites to accomplish a task efficiently
agents will negotiate for resources, then perform taskplanning and scheduling to complete the requestedservice in a timely and more efficient manner. Thisis achieved by constructing, merging, and managingworkflow-nets. Workflow-nets have been a favorablechoice and are adopted in research areas undergoingintense study such as enhanced cloud service com-position [19, 20], agent cooperation for task achieve-ment [21], and vehicular service management [22].
This work relies on a cooperation operator intro-duced in [23, 24] that formulates the topology andstructure for a set of cooperating fog computing sites andIoT device agents. The cooperative operator turns thecomposition problem defined as a set of Workflow-nets into algebraic representations to solve and opti-mize the problem mathematically. The presented workextends the work introduced in [23] to provide a solu-tion for fog and cloud computing systems targetingareas of IoT agent cooperation to produce enhancedcomposed services (both simple and complex) in atimely manner. We show through mathematical proofsand experimental results that the proposed coopera-tive solution is applicable to fog-based systems withlimited node resources. To clarify the fog-based coop-erative solution incorporated in this paper for thereader, a realistic IoT-based cooperation applicationscenario is integrated, which focuses on multi-robot(i.e. IoT multi-device) task achievement. Hence, theliterature review and experimental evaluation sectionswill focus on IoT-based robotic issues and solutions.
To this end, related work is surveyed in Section 2.Section 3 illustrates the methodology of the pro-posed framework and the agent cooperation algorithm.Section 4 briefly summarizes the cooperative opera-tor and its properties. Section 5 presents experimentalevaluation results in support of the framework throughsimulation and implementation tests. Section 6 con-cludes the paper and outlines potential future work.
2 Related Literature
Cooperation is defined as the process of merging andmanaging resources and capabilities, such as com-putational power, of different entities to reach anobjective. The objective is achieved by having coop-erating entities negotiate for resources and performtask planning and scheduling. Cooperation among dif-ferent entities is widely common in many differentengineering disciplines, such as robotics, wireless sen-sor networks [25, 26], and vehicular communication[27–32]. Advances in both IoT devices and networktechnologies have made it possible for mobile and sta-tionary devices such as robots to perform collaborativetasks in various environments [33]. Moreover, today’sadvanced wireless technologies such as 5G have madeconnectivity to cloud computing services easier, toallow for significantly enhanced IoT system capabili-ties [34] as well as data management and congestionmitigation in densely crowded environments [35, 36].
627
Y. Kotb et al.
Cloud providers collaboration for the purpose ofservice discovery and management has been discussedin [37]. Solutions such as hybrid cloud and adap-tive scheduling for heterogeneous workloads haveimpacted the performability of workflow applicationsin cloud environments [38, 39]. On the other hand,Fog node collaboration for the purpose of fulfillingrequests and services sent from IoT nodes to the fogcomputing layer and improving fog computing perfor-mance is considered in [40, 41]. The proposed solutionassumes that if a fog computing node can accept IoTnode requests based on its current load, then it willprocess the requests. Otherwise, it would offload therequests to other fog computing nodes or the clouddatacenter, to achieve what they call “load sharing”.Two modes of fog computing interactions are adapted:centralized and distributed. In centralized, within eachfog computing domain, a node is selected to act as acentral authority to control the interactions among thefog computing nodes in the domain. Fog computingnodes within a single domain report their estimated’time to process’ IoT node requests to the central fogcomputing node. The central node then announces theestimated processing times to neighboring fog com-puting nodes. Fog computing nodes compare thosetimings against pre-calculated thresholds. If a fogcomputing node is capable of processing this request,then the task is offloaded to the capable fog computingnode. Otherwise, the request is forwarded to the clouddatacenter. In the latter mode of fog computing nodeinteraction (i.e. distributed), fog computing nodes canonly collaborate with neighboring nodes using a uni-versal protocol. Each fog computing node maintainsa reachability table using the estimated task process-ing times it receives from neighboring fog computingnodes. Similar to the central mode solution, a fogcomputing node will select the best neighbor that iscapable of processing the request with the smallestestimated processing time, plus half of the roundtriplatency.
The authors in [42] introduced a communica-tion framework for Autonomous Underwater Vehi-cles (AUVs) which expands the computational anddata resources that are available to a team of AUVsby including public cloud computing resources. Aresource provisioning engine is designed to offloadsome of the AUVs’ tasks to the cloud datacenter.AUV workload is shared between local and cloudcomputing resources based on communication cost,
computation cost, and battery capacity. The aim ofthe solution is to increase the lifetime of such power-limited IoT devices. Additionally, with the availabil-ity of more sophisticated cloud computing resources,high accuracy is also achievable. The focus of theirwork is on resource-provisioning to allocate tasksbetween the cloud and local resources based on theobjective of minimizing execution time or the priceof the execution. The required set of tasks to beperformed are represented using a Directed AcyclicGraph (DAG), with tasks denoted by nodes in thegraph. Directed edges indicate the information flowfrom one task to another. Nodes on the same levelof the graph are executed in parallel, whereas nodesin consecutive levels are executed sequentially. Sim-ulations using MATLAB were conducted to show theimprovement in task accuracy.
Wang et al. [43] proposed a hierarchical auction-based mechanism for autonomous cloud computingrobotic system negotiations within an ad hoc networksetting. The solution provides fast and efficient accessto cloud computing resources under a constrainedbandwidth using firm real-time (FRM) communica-tion. The solution assigns a role to each node availablein the network to manage the limited communicationcapability of an ad hoc robot-to-robot (R2R) network.A proxy node is chosen to be responsible for dis-tributing the resources in the cloud according to theauction results. Clients are the robots requiring cloudcomputing resources. Relay nodes are robots capa-ble of maintaining connectivity for the R2R network.Relay nodes are responsible for selecting winningclients in the latest auction round. All robots com-pete for the transmission opportunity through relaynodes. Node priorities are considered when allocat-ing network resources. The objective of the game is tomaximize the total transmission rate for the network.Simulation results show that the proposed algorithmoutperforms the greedy and the Hungarian algorithms.
In [44], the authors proposed a peer reciprocallearning system for robots to cooperatively accom-plish a complex task and help each other learn better.The cooperating robots communicate their individ-ual decisions and collected information to formulatemutual decisions and robotic motions. A mutual learn-ing method is proposed allowing robots to learn fromeach other by exchanging their neural network learn-ing function weights. The authors claim that simula-tion results have shown that robots can learn from each
628
Cloud-Based Multi-Agent Cooperation for IoT Devices
other and build general concepts from limited train-ing. Moreover, a real-time experiment was developedto demonstrate the effectiveness of the proposed robotlearning system in achieving complex tasks.
In [45], the authors consider the issue of deploy-ing a team of robots to accomplish a task whilemaintaining an ad-hoc network that supports the datatransmission requirements necessary for task fulfill-ment. A solution is presented that considers estimationof point-to-point channels using pathloss and Gaus-sian process models to identify reliable point-to-pointcommunication links. Moreover, data routing tech-niques are considered in determining suitable end-to-end communication routes. Motion planning is alsoconsidered to determine robot trajectories for motioncontrol to ensure the survival of the communicationnetwork. Experimental evaluations were conductedto show that multi-robot navigation is possible withcontinuous end-to-end connectivity.
The authors in [46] proposed a neural dynamicsapproach used for complete area coverage naviga-tion conducted by multi-robots. The neural networkis used to model the work environment and thenguide a swarm of robots through navigation. Eachmobile robot considers other robots as moving obsta-cles. Robot paths are autonomously generated fromthe neural activity landscape of the neural network andprevious robot positions. Experiments were conductedon cleaning robots to showcase the effectiveness of therobot navigation technique.
The project proposed in [47], is an open-sourcedatabase available in the cloud, providing services forIoT robotic systems. IoT robotic devices from differ-ent locations in the globe can access and update thisinformation. IoT Robotic systems can learn from otherrobots’ experiences, behaviors and operating environ-ments. The project’s collected data focuses mainly ontarget recognition, navigation and intelligent servicesperformed by robots. The architecture is composed ofthree layers: robot clients, cloud computing engine,and cloud computing database. Tasks involving com-putation are transferred to the cloud computing engineusing a unified data format. The cloud computingengine interacts with the database layer to finalizethe results to be sent back to the robot client. Somerobot applications may not require access to the cloudcomputing engine but rather can access the cloudcomputing database directly for model matching. The
requested data is returned back to the robot to com-plete the specific task.
Table 1 provides a summary of some coopera-tive IoT systems in the literature highlighting theiradvantages and disadvantages.
In this article we introduce a workflow-net basedframework for agent cooperation of IoT devices. Theframework provides an algorithm to verify similaritiesamong agent capabilities discovered from differentfog computing sites connected to the cloud in orderto determine the possibility of IoT device coopera-tion with respect to a desired task. The intended taskis either not achievable given the available devicecapabilities in the environment or would require theuse of a great portion of their resources if traditionalnon-cloud-based solutions are adopted. Our work dif-ferentiates from the literature through the introductionof a cooperation operator that formulates the topologyand structure for the set of cooperating agents. Thecooperative operator turns the task composition prob-lem defined as a set of Workflow-nets into algebraicrepresentations to solve and optimize the problemmathematically. We consider robots as an example ofcollaborative IoT devices, to provide a more realisticscenario that is reader friendly. It is important to notehere, that, the considered cooperative solution is notrestricted to robots only, but can also be applied to anyIoT device that has either sensing, computational, orstorage capabilities.
3 The Cooperative Framework
Cooperation between two or more agents is frequentlyrequired to achieve a common goal, and it is onlyconsidered successful if the desired goal is attained.In the literature, resource sharing and cooperation areoften used interchangeably, though there is a clear dis-tinction between them. With resource sharing, agentstry to schedule their behavior by postponing certainactions so resources are accessible by all agents atdifferent times. This makes resource sharing sim-ply a scheduling problem, regardless of whether it isachieved through central or distributed scheduling byagents communicating to negotiate resource access.Cooperation, however, refers to agents contributing bynot only sharing resources equitably, but also by com-bining their actions so a common goal is realized. We
629
Y. Kotb et al.
Table1
Com
pari
ngdi
ffer
entc
oope
rativ
eap
proa
ches
for
IoT
syst
ems
App
licat
ion
Obj
ectiv
eSo
lutio
nA
dapt
edFa
ctor
sC
onsi
dere
dA
dvan
tage
sD
isad
vant
ages
Und
erw
ater
sens
ors
[23]
Dec
reas
een
ergy
cons
umpt
ion
Sens
orno
des
forw
ard
data
pack
ets
ina
mul
ti-ho
pfa
shio
nw
itha
virt
ual
pipe
line.
Nod
esou
tsid
eth
epi
pelin
edo
not
forw
ard
data
pack
ets
toav
oid
netw
ork
floo
ding
.
Num
ber
ofho
ps,
num
bero
fnei
gh-
bors
.
Ene
rgy-
effi
cien
t,re
duct
ion
inpa
cket
dela
y.
Incr
ease
dnu
mbe
rsof
tran
smitt
edpa
cket
s.
Indu
stri
alse
nsor
s[2
5]A
ccur
ate
sens
ing
and
repo
rtin
gTw
oph
ases
:in
the
firs
tpha
se,e
ach
node
shar
esits
info
rma-
tion
with
all
othe
rno
des.
Inth
ese
cond
phas
e,ea
chno
defo
rms
aco
oper
ativ
eda
tapa
cket
and
send
sit
toth
eB
S.
TD
MA
-bas
edM
AC
prot
ocol
,m
ajor
ityru
lesc
hem
efo
rde
cisi
onm
akin
g
Info
rmat
ion
isre
laye
dby
neig
hbou
ring
node
s,he
lps
cons
erve
pow
erfo
ren
ergy
-lim
ited
node
s.
Net
wor
ktr
affi
cfl
oodi
ng.
Roa
dve
hicl
es[2
6]Sa
fedr
ivin
gan
dla
nech
angi
ngA
vehi
cle
driv
ing
and
lane
chan
ging
mod
elis
prop
osed
topl
antr
ajec
tori
esfo
rve
hicl
esin
the
vici
nity
oftr
affi
csi
gnal
sin
adva
nce,
byex
tend
ing
the
Inte
llige
ntD
rive
rM
odel
(ID
M)
Sign
alcy
cle
stat
e,di
stan
ceto
traf
-fi
csi
gnal
s,ad
ja-
cent
vehi
cles
.
Red
uced
vehi
cle
stop
-pi
ngfr
eque
ncy
and
trav
eltim
e,im
prov
edro
adtr
affi
cth
roug
h-pu
t.
Incr
ease
dnu
m-
bers
oftr
ansm
it-te
dpa
cket
s.
Smar
troa
dve
hi-
cles
[27]
Del
iver
cont
i-nu
ous
clou
dse
rvic
esto
smar
tveh
icle
user
s
Clu
ster
sar
ees
tabl
ishe
dus
ing
am
ovem
enta
ndse
rvic
ede
scri
p-tio
nsi
mila
rity
tech
niqu
e.O
ptim
alus
erse
rvic
ese
lect
ion
isac
hiev
edby
atr
uste
d-th
ird-
part
y(T
TP)
sele
ctio
nm
etho
d.
Serv
ice
sim
ilari
ty,
rela
tive
velo
city
,no
delin
klif
etiti
me
node
link
dist
ance
,de
lay,
serv
ice
cost
,pr
ivac
y.
Impr
oved
QoS
and
QoE
,gua
rant
eed
ser-
vice
deliv
ery,
redu
ced
serv
ice
cost
.
Incr
ease
dpa
cket
over
head
.
Und
erw
ater
vehi
cles
[33]
Incr
ease
node
lifet
ime
Two
poly
nom
ial-
time
heur
istic
sar
ein
trod
uced
toso
lve
the
reso
urce
-allo
catio
npr
oble
m.
Com
mun
icat
ion
cost
,co
mpu
tatio
nco
st,
batte
ryca
paci
ty.
Red
uced
exec
utio
nde
lay.
Cos
tis
only
redu
ced
ifth
etr
aditi
onal
clou
dsc
hem
eis
used
.
630
Cloud-Based Multi-Agent Cooperation for IoT Devices
Table1
(con
tinue
d)
App
licat
ion
Obj
ectiv
eSo
lutio
nA
dapt
edFa
ctor
sC
onsi
dere
dA
dvan
tage
sD
isad
vant
ages
Var
ious
robo
ticde
vice
s[4
0]
Max
imiz
eto
tal
tran
smis
sion
rate
Ahi
erar
chic
alau
ctio
n-ba
sed
mec
hani
smis
used
.A
prox
yno
deis
chos
ento
bere
spon
sibl
eof
dist
ribu
ting
the
reso
urce
sin
the
clou
dac
cord
ing
toth
eau
ctio
nre
sults
.Rel
ayno
des
are
resp
onsi
ble
ofse
lect
ing
win
ning
clie
nts
inth
ela
test
auct
ion
roun
d.
Rea
l-tim
ew
irel
ess
mul
ti-ho
ppr
otoc
ol(R
T-W
MP)
,no
depr
iori
ties.
Red
uced
reso
urce
usag
e,re
duce
dla
tenc
y.
Solu
tion
does
not
cons
ider
dyna
mic
netw
ork
topo
logy
chan
ges.
Lea
rnin
gla
ndro
bots
[42]
Enh
ance
robo
tle
arni
ngth
roug
hco
oper
atio
n
The
solu
tion
isba
sed
onth
epe
er-a
ssis
ted
lear
ning
theo
ryan
dre
cipr
ocal
lear
ning
stra
tegy
.Im
age
info
rmat
ion,
indi
vidu
alro
bot
deci
sion
s.
Incr
ease
dac
cura
cyro
botic
mov
emen
ts.
Solu
tion
islim
ited
tosi
mpl
esc
enar
ios.
Mob
ilero
bots
[43]
End
-to-
end
node
conn
ectiv
ityT
heso
lutio
nco
nsid
ers
estim
atio
nof
poin
t-to
-poi
ntch
anne
lsus
ing
path
loss
and
Gau
ssia
npr
oces
sm
odel
sto
iden
tify
relia
-bl
epo
int-
to-p
oint
com
mun
icat
ion
links
.
Sign
alst
reng
th,
node
velo
city
.C
ontin
uous
and
stab
leen
d-to
-end
node
conn
ectiv
ity.
Exc
essi
vetim
efo
rpl
anni
ng.
Cle
anin
gro
bots
[44]
Com
plet
ear
eaco
vera
geA
neur
alne
twor
kap
proa
chis
used
tom
odel
the
wor
ken
viro
n-m
enta
ndth
engu
ide
asw
arm
ofro
bots
thro
ugh
navi
gatio
n.N
ode
posi
tion,
cove
-ra
gepa
ttern
,ta
skal
loca
tion
prot
ocol
.
Loa
dba
lanc
ing
amon
gno
des.
Incr
ease
inov
er-
all
pow
erco
n-su
mpt
ion.
631
Y. Kotb et al.
adopted this definition of cooperation to develop thecooperative fog computing framework in this article.
To meet a pre-defined objective, a cooperativemodel that incorporates a set of IoT agents and theircapabilities must be defined. Workflow-net, which isan extension to the well-known Petri-net [15, 16, 48],is a preferred solution to cooperative scenarios thatneed to be handled concurrently [49, 50].
3.1 Preliminaries
Petri-net resembles a set of actions taken in sequenceor parallel to achieve a task. Hence, a directed graph isused that incorporates both transitions t and places p.Places resemble conditions that must be satisfied forthe transitions which resemble actions to be executed.As such, a place either comes before or after a transi-tion, in which usually, the first place is not preceded bya transition, and a transition does not proceed the lastplace. A token which represents activities performedby transitions reside in places. Thus, a place not with-holding tokens disables any transition connected to it.A transition is therefore enabled if an only if there areplaces (with residing tokens) connected to it as input.A transition that is enabled will execute (or fire) result-ing in the removal of one or more tokens from its inputplaces towards its output places. For a more elaboratedescription both textually and visually, the reader isencouraged to look at [10, 19, 51–54].
According to the definition stated above, a Petri-netis thus a tuple:
N =< P,T,F,W > (1)
where P is a set of places defining the net. Thoseplaces can be seen as preconditions to events or postconditions and results to event occurrences. T is a setof transitions representing event occurrences. F is a setthat defines the topology of the net. W is a vector ofweights for the arcs defined in F.
P = {p1, p2, . . . , pn} (2)
and n is the number of places in N. We define the setof transitions T to be:
T = {t1, t2, . . . , tm} (3)
and m is the number of transitions in N.
Figure 2 provides an example of a petri-net withseven places and four transitions. Four of the placesare marked such that T0 and T3 are enabled. When T0
is fired, the token in P0 is consumed and two tokensare produced in P1 and P2, resulting in T1 and T2 beingenabled and so forth.
F represents the connectivity between T and P.Mathematically it is represented as the cross productof the set of transitions times the places union the crossproduct of the places times the transitions:
F = (T × P) ∪ (P × T) (4)
Equation 4 describes the topology of the petri-net.It shows that transitions are connected to places andplaces are connected to transitions. It also shows thattransitions cannot be directly connected to transitionsand places cannot be directly connected to places,since the cross product is between the transition setand the place set or between the place set and thetransition set.
W is a set of integer numbers representing theweights of every f ∈ F. This weight defines the num-ber of tokens required for a transition t ∈ T to beactivated through an input place p ∈ P. The distribu-tion of tokens in the net places is called marking. Atany point of time τ we have token distribution Mτ thatis represented as follows:
Mτ =n⋃
i=1
‖p‖τ , p ∈ P, at time τ (5)
Equation 5 shows the distribution of tokens over thepetri-net at time τ . n is the number of places and ‖p‖τ
is the number of tokens in place p at time τ .Another important vector is the firing vector. It is a
vector that represents a transition that is enabled andready to fire based on the current marking of the net.Mathematically, the firing vector F→ is represented asfollows:
F→ =
n×m⋃
i=1
M(p) − W(p, t), p ∈ P, t ∈ T, p × t �∈ ∅
(6)
In other words, for every arc between a place p
and a transition t (where p is an input to t), p would
632
Cloud-Based Multi-Agent Cooperation for IoT Devices
Fig. 2 A graphical example of a petri-net
contribute in enabling t if and only if the marking ofp is greater than or equal to the weight of the arcbetween p and t . Once the transition is enabled it caneventually fire and therefore it is being added to thefiring vector.
F→ is often represented as a matrix � with dimen-
sions n × m. The rows are the places and the columnsare the transitions. �(i, j) = 0 if and only if pi × tj ∪tj × pi = ∅, �(i, j) = 1 if and only if tj × pi �= ∅and �(i, j) = −1 if and only if pi × tj �= ∅. Now ifwe have a place p and a transition t such that p ∈ •t
and p ∈ t• then this matrix has to be separated intotwo matrices, namely, �+ which holds only the rela-tionship tj × pi �= ∅ and �
− which holds only therelationship pi × tj �= ∅.
3.2 Agents and Agent Capabilities
An agent multi-cloud service composition problemhas been presented in [55]. However, the problemof cooperation involves multi-agents that decide tocooperate together based on their inner capabilities toachieve the required task is more complex task. Thistask is a set of actions defined as:
� = {λ1, λ2, . . . , λ‖�‖} (7)
The set of agents are represented as follows:
A = {a1, a2, . . . , a‖A‖} (8)
where ‖A‖ is the length of the set of agents A. Wealso have a universal set of capabilities Ω . This Ω isdomain and application specific and is represented as:
Ω = {ω1, ω2, . . . , ω‖Ω‖} (9)
For every agent a ∈ A, there is a set of capabilitiesΩa ∈ Ω . This Ωa determines what the agent a canor cannot do. For two or more agents ai, aj , . . . , ak
to be able to cooperate, they need to achieve what isdefined to be task coverage. That is the ability to per-form the required task. We define the task coverage tobe:
∀λ ∈ �, ∃ω ∈ Ωai∪ Ωaj
∪ . . . ∪ Ωak‖ω ≡ λ (10)
where the task is considered not covered if and only if:
∃λ ∈ �, ‖∀ω ∈ Ωai∪ Ωaj
∪ . . . ∪ Ωak‖ω �≡ λ (11)
3.3 Homogenity and Heterogenity of Agents
The concept of homogenity is applied for two or moreagents to replace each other with respect to performingsome task. Heterogenity is the opposite of homo-geneity. Mathematically, we model homogenity to be:
�k ∩ Ωai≡ �k ∩ Ωaj
(12)
633
Y. Kotb et al.
If (12) applies then ai and aj can replace each otherto perform a certain task defined by �k . This can beexpressed as:
∀ω ∈ Ωai, ω ∈ �k, ω ∈ Ωaj
(13)
On the contrary, heterogenity is expressed asfollows:
∃ω ∈ Ωai, ω ∈ �k‖ω �∈ Ωaj
(14)
Similarity is a subset of homogenity. Two agentsare considered similar if and only if:
∃ω ∈ Ωai, ω ∈ �k‖ω ∈ Ωaj
(15)
where ai and aj are similar with respect to perform-ing action ω but not necessarily all actions in �k Wedefine agent polymorphism to be the ability for agentsto replace one another given certain tasks. This meansthat agent polymorphism is achieved when two ormore agents have similarities among each other.
It is worth noting that the proposed frameworkis applicable for both homogeneous and heteroge-neous agents. For homogeneous agents, the selectionis achieved based on availability or lower cost, and forheterogeneous agents, the selection is achieved basedon the capability matrix.
3.4 Representing Cooperation Using Workflows
In order to achieve cooperation among IoT deviceagents that belong to different fog computing sites, thetask to be performed must be taken into consideration.The design of the cooperative workflow depends onthe diversity of tasks to be performed.
Aalst defined how a workflow can be modeledusing petri-nets[16, 48]. We use Aalst’s definitionof workflows to achieve cooperation among differentagents belonging to different fog computing sites afterwe determine polymorphism and similarities amongthis set of agents. We do this by proposing a cooper-ation algebra technique that mathematically modelsthe building process of the cooperative workflow fromits original basic agent capabilities. As will be seenlater in this paper, we propose different mathemati-cal operators that convert the cooperation process intoa logical equation. This logical equation is translatedinto a workflow defined by Aalst. A few theorems
are proposed to prove the correctness of the resultantworkflow and the mathematical properties of thoseoperators. An overall algorithm is being illustrated forthe whole cooperation process.
IoT devices share their capabilities to achieve acooperative plan. Unlike web service compositionapproaches [56, 57], we assume that compatibilityis assured when agents share their capabilities. Inweb service composition, the objective is composedand compatible services at design time, while ourapproach for cooperating agents will determine thebest way to share capabilities to execute a coopera-tive plan at minimal cost. Unlike other work in theliterature, our proposed solution is a composition planthat integrates the device capabilities of different fogcomputing sites, as depicted in Fig. 3. Fog computingnodes advertise their connected IoT device capabil-ities through the cloud, and nodes that are assignedtasks that require composition of cooperative agentcapabilities first develop a composition plan in theform of task assignments. A set of workflow-nets arethen composed to represent the composition plan, andthe optimal workflow solution is adapted. Results arestored in the cloud datacenter to be used for futurecomposition requests.
In the literature, the definition of soundness variesfrom Aalst [17] to Kindler [58]. Aalst clearly statesthat every sub-workflow that is building the overallworkflow has to be sound in order for the whole work-flow to be sound. Kindler, on the other hand, arguesthat it is important for the overall workflow to havetheir tokens be able to reach the output overall placefor it to be sound even if we have sub-workflows thatare not really sound. In this paper, we are adopting thedefinition of Aalst to the soundness of the workflow.
A Workflow-net is a subclass of petri-nets, suchthat, it has one input place and one output place. Sobasically, a workflow has one input gate to the systemand one exit gate out of the system. A workflow mustbe sound by definition and by design and that is whythe proof of soundness for any proposed workflow iscrucial. Aalst defined a petri-net to be a workflow ifand only if the following applies [58]:
1. ∃i ∈ ℵ, •i = ∅,2. ∃o ∈ ℵ, o• = ∅ and3. If ∃t ∈ Tℵ, •t = o, t• = i then ℵ becomes
strongly connected.
634
Cloud-Based Multi-Agent Cooperation for IoT Devices
IoT Device Layer
Composition Layer
Composed Workflow-net
Fog Layer
FogNodes
FogNodes
P2
T1
P3
P1
P7 P8
P4
P5
P6
T2
T3
T4
T5T6
Virtual Nodes
Fig. 3 Integration of IoT device capabilities to complete a task through the composition of workflow-nets
In other words, there is a single input i to workflowℵ and a single output o to workflow ℵ. If the out-put o is connected to the input i with a feedback loopusing transition t , any place in the workflow becomesreachable from any other place in the same work-flow. Reachability from place a to place b is definedas having a sequence of transitions that will make b
reachable from a and is denoted as b ∈ [a〉.We assume that there is a set of basic and prim-
itive actions or capabilities of agents that cannot bedivided or fragmented into any smaller actions. If anagent ai from the set of cooperating agents A ={a1, a2, . . . , an} has plan dj from the set of plansD = {d1, d2, . . . , dk}, it can perform the plan aloneonly if it meets any time constraints and the followingequation holds:
∀ω ∈ dj : ω ∈ Ω(ai), (16)
where ω is an action, and
Ω(ai) = {WFnet1, WFnet2, . . . , WFnetl} (17)
where Ω(ai) is the action capability set of agent ai ,WFneti are workflow nets, and dj = {ωo(∪ωk)
∗}, suchthat ωo �= ∅ is a starting action and (ωk)
∗ is a set ofactions that follow (which could be the empty set ∅).
Agent ak is a candidate for cooperation with agentai if and only if
∀ω ∈ �j : �j = dj − ω(ai) , ω ∈ Ω(ak), (18)
where �j is the difference between the capabilitiesrequired to achieve plan dj , and the capabilities ofagent ai . A more relaxed condition would be
∀Ω(ak|) ∪ Ω(ai) ≡ �j (19)
We divide workflow into units. Units are the small-est partition of a workflow which is basically onetransition, the inputs to this transition and the out-puts from this transition. Mathematically a unit ui isdescribed as follows:
ui = (P × ti , ti , ti × P) (20)
P × ti is the set of input places to ti and is denoted•ti and ti × P is the set of output places from ti and isdenoted ti•.
Two units ui and uj are considered identical if andonly if:
ti ≡ tj and P× ti ≡ P× tj and ti ×P ≡ tj ×P (21)
635
Y. Kotb et al.
In other words, the action ti does the same actionthat tj does, the input set •ti is the same as the inputset •tj and the output set ti• is the same as the outputset tj•. If we relax the condition by taking the outputcondition out, this would yield similar units. Two unitsui and uj are similar if and only if:
ti ≡ tj and P × ti ≡ P × tj (22)
This means that all identical units are similar but notall similar units are identical.
We can proceed by induction to propose the con-cept of composition. We define a composition to bea set of units connected together. In this case, havingtwo compositions ci and cj , such that ci is a subset ofcj when the following equation holds:
ci ⊆ cj ↔ ∀ui ∈ ci, ∃uj incj : |ui and uj are identical.
(23)
The identity of compositions are identified as fol-lows: ci and cj are considered identical if and only if:
ci ⊆ cj and cj ⊆ ci (24)
and they are similar if and only if
ci ⊂ cj and ci �= ∅ (25)
For two units ui and uj ( or two compositions ci
and cj ) to cooperate, we need a communication chan-nel ζ . ζ could be a single transition with input •ζ =ti• and output ζ• = •tj . This is the simplest form ofζ , however, ζ could be a whole workflow-net.
Algorithm 1 shows how a cooperative framework isconstructed out of separate workflows. The complex-ity of the algorithm is O(w)×O(c)×O(a) where w isthe number of cooperating workflows, c is the averagenumber capabilities per workflow, and a is the aver-age number of actions in the plan, which approximatesto O(n3). For some related complexity discussions onthe soundness problem of workflow-nets, the reader isencouraged to refer to [59]. The optimization of theproposed algorithm out of the scope of this paper.
It is worth noting that similarity and identity makecooperation much easier since it increases homogene-ity in the swarm of agents, and therefore, selectionand plan creation is easier since many alternatives areavailable.
Algorithm 1 Calculate � and D.
Require: A plan P|P = (Pi θ Pj )+ and θ ∈
{∧, ∨, →} and + means one or more times.Require: R‖R = {r1, r2, . . . , rn} and n is the number
of agents.Require: Ω‖Ω = {ω1, ω2, . . . , ωn} and ωi is the set
of capabilities of agent ri .Ensure: , The cooperative framework.for all ri ∈ R do
for all rj ∈ R doif ωi ∩ ωj �= ∅ then
S = S ∪ (ri, rj )
end ifif ∃P ∈ P‖P �∈ S then
TERMINATEend if
end forend forfor all si ∈ S do
for all Pj ∈ P doif Pj ∈ si then
for all rk ∈ S doG(k) = G(k) ∪ rk(P )
end forend if
end forend forfor all gi ∈ G do
for all pj ∈ gi doif pj ∈ gi ∧ pj �∈ then
= ∪ pj
end ifConnect pj to pj−1
end forend for
4 The Cooperative Operator
In order to represent cooperation mathematically, wepropose a cooperative operator ⊗. This operator joinstwo or more workflows and produces a cooperativeworkflow based on identical and similar units compos-ing those workflows. If WFnetk = WFneti ⊗ WFnetj ,then the following properties must apply:
1. WFneti and WFnetj are sound,2. ∀ ζ ∈ WFneti ⊗ WFnetj , ζ is sound, and3. •ik = ∅, ok• = ∅.
636
Cloud-Based Multi-Agent Cooperation for IoT Devices
The cooperative operator preserves the property ofsoundness, and is associative, non-commutative andnon-distributive. Having workflow x and workflow y,the incident matrix of the cooperation is shaped asfollows:
�⊗ =[�x ζ
ζ �y
]
That is if and only if Px ∩Py = ∅ and Tx ∩Ty = ∅. Inother words, the cooperation incident matrix is validonly in cases where x and y are disjoint. If theyare joint, then the common places and transitions arewritten once. The dimension of �⊗ is calculated asfollows:
‖�‖ = (‖Px‖+‖Py‖+‖Pζ ‖)×(‖Tx‖+‖Ty‖+‖Tζ ‖)(26)
4.1 The ∧ Operator
The and operator ∧ joins incident matrices of itspredicates. Two workflows are joined as follows:
ℵ1 ∧ ℵ2 → ∃t0∃p0∃te, pe‖p0 = •t0 and t0 = •iℵ1
and t0 = •iℵ2and pe = te • and oℵ1 = •pe and oℵ2 = •pe (27)
In other words, the two workflows work in parallelwith a single input place and a single output place. Inthis case, ζ is an incident matrix that binds ℵ1 andℵ2 with a single input and output as an ∧ operation.Figure 4 depicts an example of the behavior of the ∧operator on two workflows.
We propose the following theorem:
Theorem 1 Having two workflows ℵx and ℵy , if ℵx issound and ℵy are sound, then, ℵx ∧ ℵy is also sound.
Proof ∵ ℵx ∧ ℵy =< Px ∪ Py ∪ {p0, pe},Tx ∪ Ty ∪{t0, te1, te2} > and t0 = p0• and pe = te1• and pe =te2• and te1 = oalephx • and te2 = oℵx •.
∴ ∀M0,M0 = Mτ (iℵx ).∵ ℵx is sound,∴ ∀Mτ (iℵx ) = Mτ2(oℵx ).∴ Mτ2(oℵx ) = Mτ2(pe)
∴ for ℵy :∀M0,M0 = Mτ (iℵy ).∵ ℵy is sound,∴ ∀Mτ (iℵy ) = Mτ2(oℵy ).∴ Mτ2(oℵy ) = Mτ2(pe).∴ ℵx ∧ ℵy is sound.
4.2 The ∨ Operator
The or operator ∨ also joins the incident matrices ofits predicates. Two workflows are joined as follows:
ℵ1 ∨ ℵ2 → ∃t01∃t02∃p0∃te, pe‖p0 = •t01 and t01
= •iℵ1 and p0 = •t02 and t02 = •iℵ2
and pe = te • and oℵ1 = •pe and oℵ2 = •pe (28)
Contrary to the ∧ operator, in the ∨ operator, eitherone of the two workflows will work at a time. The twoworkflows share the same input and output places. Inthis case, ζ is an incident matrix that binds ℵ1 and ℵ2
with a single input and a single output as an ∨ oper-ation. Figure 5 depicts an example of the behavior ofthe ∨ operator on two workflows.
We propose the following theorem:
Theorem 2 Having two workflows ℵx and ℵy , if ℵx
and ℵy are sound, then ℵx ∨ ℵy is also sound.
Proof Since ℵx ∨ ℵy =< Px ∪ Py ∪ {p0, pe},Tx ∪Ty ∪ {t0, t1, te1, te2} > and t0 = p0• and t1 = p0•and pe = te1• and pe = te2• and te1 = oalephx • andte2 = oℵx •.
∴ ∀M0,M0 = Mτ (iℵx ) or M0 = Mτ (iℵx ).∵ ℵx and ℵy are sound,∴ if ∃Mτ (iℵx ) → Mτ (iℵx ) = Mτ2(oℵx ).∴ if ∃Mτ2(oℵx ) → Mτ2(oℵx ) = Mτ2(oℵy ).∴ if ∃Mτ (iℵx ) → Mτ (iℵx ) = Mτ2(pe).∴ if ∃Mτ (iℵy ) → Mτ (iℵy ) = Mτ2(pe).∴, ℵx ∨ ℵy is sound.
4.3 The → Operator
The implication operator → joins workflows as fol-lows:
(ℵ1 → ℵ2) → ∃tm‖tm = oℵ1 • and tm = •iℵ2 (29)
In other words, using the → yields in one of thetwo workflows being selected at a time. The two work-flows share the same input and output places. In thiscase ζ is an incident matrix that binds ℵ1 and ℵ2 witha single input and output as an → operation. Figure 6depicts an example of the behavior of the → operatoron two workflows.
We propose the following theorem:
Theorem 3 Having two workflows ℵx and ℵy , if ℵx
and ℵy are sound then, ℵx → ℵy is also sound.
637
Y. Kotb et al.
P2
P1
P0 P5
T0
T1
T2
P3
P4 T3
P1
T1
P3 P2
T2
P4and
Results in:
Fig. 4 An example of the behavior of the ∧ operator on two workflows
Proof ∵ ℵx and ℵy are sound,∵ ℵx → ℵy =< Px ∪ PyTx ∪ Ty ∪ {tm} > and
tm = oℵx • and tm = •iℵy .∴ ∀M0,M0 = Mτ (oℵx ).∴ Mτ (oℵx ),M0 = Mτ (iℵy ).∴ Mτ (iℵy ) = Mτ oℵy ).∴ ℵx → ℵy is sound.
Certain properties hold for the cooperation oper-ator, nameley, non-commutativity, associativity andnon-distributivity.
4.4 Commutativity
We propose the following theorem:
Theorem 4 Having two workflows ℵx and ℵy , ℵx ⊗ℵy �≡ ℵy ⊗ ℵx .
Proof For ℵx to cooperate with ℵy , Ωℵx ∪ Ωℵy = �.If ℵx �≡ ℵy , ∴ Ωℵx − Ωℵy �= Ωℵy − Ωℵx .In other words, �−Ωℵx �= �−Ωℵy . ∴ ζxy �= ζyx .∴ ℵx ⊗ ℵy �≡ ℵy ⊗ ℵx .
T4
T5
P2
P1
P0
T2
T3
P3
P4
P1
T2
P3 P2
T3
P4or
Results in:
T0
T1
P5
Fig. 5 An example of the behavior of the ∨ operator on two workflows
638
Cloud-Based Multi-Agent Cooperation for IoT Devices
T2
P1
T1
P2
P0
T0
P1 P2
T2
P3Implies
Results in:
T0
P0 P3
Fig. 6 An example of the behavior of the → operator on two workflows
4.5 Associativity
We propose the following theorem:
Theorem 5 Having three workflows ℵx , ℵy and ℵz,(ℵx ⊗ ℵy) ⊗ ℵz ≡ ℵx ⊗ (ℵy ⊗ ℵz).
Proof For (ℵx ⊗ ℵy) ⊗ ℵz, the resultant workflow is
ℵxy = < Pℵx ∪ Pℵy ∪ Pζxy ,Tℵx ∪ Tℵy
∪Tζxy ,Fℵx ∪Fℵy ∪Fζxy ,Wℵx ∪Wℵy ∪Wζxy> (30)
Now, ℵxy ⊗ ℵz gives:ℵxyz =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζxyz , Tℵx ∪ Tℵy ∪
Tℵz ∪ Tζxyz ,
Fℵy ∪ Fℵz ∪ Fζxyz ,Wℵx ∪ Wℵy ∪ Wζxyz ∪ Wζxyz >
Now, for ℵx ⊗ (ℵy ⊗ ℵz), the resultant workflow isℵyx =< Pℵy ∪ Pℵz ∪ Pζyz , Tℵy ∪ Tℵz ∪
Tζyz,Fℵy ∪Fℵz∪Fζyz ,Wℵy ∪Wℵz∪Wζyz>
Now, ℵx ⊗ ℵyz gives:ℵxyz =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζxyz ,Tℵx ∪ Tℵy ∪
Tℵz ∪ Tζxyz ,
Fℵx ∪ Fℵy ∪ Fℵz ∪ Fζxyz ,Wℵx ∪ Wℵy ∪ Wζxyz ∪Wζxyz >
∴, having three workflows ℵx , ℵy and ℵz, (ℵx ⊗ℵy) ⊗ ℵz ≡ ℵx ⊗ (ℵy ⊗ ℵz).
4.6 Distributivity Over the ∧ Operator
We propose the following theorem:
Theorem 6 Having three workflows ℵx , ℵy and ℵz,(ℵx ⊗ (ℵy ∧ ℵz)) ≡ (ℵx ⊗ ℵy) ∧ (ℵx ⊗ ℵz)).
Proof For (ℵx ∧ ℵy) ⊗ ℵz, the resultant workflow isℵx∧y =< Pℵx ∪ Pℵy ∪ {p0, pe},Tℵx ∪ Tℵy ∪
{t0, te},Fℵx ∪ Fℵy ,Wℵx ∪ Wℵy >
which makes ℵx∧y ⊗ ℵz as follows:ℵ(x∧y)z =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζ(x∧y)z
∪{p0, pe},Tℵx ∪ Tℵy ∪ Tℵz ∪ Tζ(x∧y)z
∪ {t0, te},Fℵx ∪ Fℵy ∪ Fℵz ∪ Fζ(x∧y)z
,Wℵx ∪ Wℵy ,Wℵz ∪Wζ(x∧y)z
>
Now, for (ℵx ⊗ ℵy) ∧ (ℵx ⊗ ℵz)), the resultantworkflow is :
ℵxy =< Pℵx ∪Pℵy ∪Pζxy ,Tℵx ∪Tℵy ∪Tζxy ,Fℵx ∪Fℵy ∪ Fζxy ,Wℵx ∪ Wℵy ∪ Wζxy >
ℵxz =< Pℵx ∪Pℵz ∪Pζxz ,Tℵx ∪Tℵz ∪Tζxz ,Fℵx ∪Fℵz ∪ Fζxz ,Wℵx ∪ Wℵz ∪ Wζxz >
ℵxy∧xz =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζxy ∪ Pζxz ∪{p0, pe},Tℵx ∪ Tℵy ∪ Tℵz ∪ Tζxy ∪ Tζxz ∪ {t0, te},
Fℵx ∪Fℵy ∪Fℵz ∪Fζxy ∪Fζxz ,Wℵx ∪Wℵy ∪Wℵz ∪Wζxy ∪ Wζxy >
From the previous derivation, the difference is in ζ .Since the ∧ operator only joins the two workflows
through joining the two input places and two outputplaces, ∴ ζ(x∧y)z ≡ ζxy ∪ ζxz from the separabilitycriteria.
∴ (ℵx ⊗ (ℵy ∧ℵz)) ≡ (ℵx ⊗ℵy)∧ (ℵx ⊗ℵz)).
4.7 Distributivity Over the ∨ Operator
We propose the following theorem:
Theorem 7 Having three workflows ℵx , ℵy and ℵz,(ℵx ⊗ (ℵy ∨ ℵz)) ≡ (ℵx ⊗ ℵy) ∨ (ℵx ⊗ ℵz)).
639
Y. Kotb et al.
Proof For (ℵx ∧ ℵy) ⊗ ℵz, The resultant workflow isℵx∨y =< Pℵx ∪ Pℵy ∪ {p0, pe},Tℵx ∪ Tℵy ∪
{t01, t02, te1, te2},Fℵx ∪ Fℵy ,Wℵx ∪ Wℵy >,which makes ℵx∨y ⊗ ℵz as follows:ℵ(x∨y)z =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζ(x∨y)z
∪{p0, pe},Tℵx ∪Tℵy ∪Tℵz ∪Tζ(x∨y)z
∪{t01, t02, te1, te2},Fℵx ∪ Fℵy ∪ Fℵz ∪ Fζ(x∨y)z
,Wℵx ∪ Wℵy ,Wℵz ∪Wζ(x∨y)z
>
Now for (ℵx ⊗ ℵy) ∨ (ℵx ⊗ ℵz)), the resultantworkflow is:
ℵxy =< Pℵx ∪Pℵy ∪Pζxy ,Tℵx ∪Tℵy ∪Tζxy ,Fℵx ∪Fℵy ∪ Fζxy ,Wℵx ∪ Wℵy ∪ Wζxy >
ℵxz =< Pℵx ∪Pℵz ∪Pζxz ,Tℵx ∪Tℵz ∪Tζxz ,Fℵx ∪Fℵz ∪ Fζxz ,Wℵx ∪ Wℵz ∪ Wζxz >
ℵxy∨xz =< Pℵx ∪ Pℵy ∪ Pℵz ∪ Pζxy ∪Pζxz ∪ {p0, pe},Tℵx ∪ Tℵy ∪ Tℵz ∪ Tζxy ∪ Tζxz ∪{t01, t02, te1, te2}, Fℵx ∪Fℵy ∪Fℵz ∪Fζxy ∪Fζxz ,Wℵx ∪Wℵy ∪ Wℵz ∪ Wζxy ∪ Wζxy >
From the previous derivation, the difference is in ζ .Since the ∧ operator only joins the two workflows
through joining the two input places and two outputplaces, ∴, ζ(x∨y)z ≡ ζxy ∪ ζxz from the separabilitycriteria.
∴, (ℵx ⊗ (ℵy ∨ℵz)) ≡ (ℵx ⊗ℵy)∨ (ℵx ⊗ℵz)).
Now that we have discussed the cooperative oper-ator and all its properties, we shift our focus on thescalability of the proposed framework.
4.8 Scalability of the Framework
The scalability of the proposed framework can beproven as shown through the following theorem:
Theorem 8 Having many workflows ℵx, ℵy, . . . , ℵz,if ℵx, ℵy, . . . , ℵz are sound then ℵx ⊗ ℵy ⊗ · · · ⊗ ℵz
is also sound.
We prove this theorem by induction.
Proof Base case: From Theorems 1,2,11: ℵx ⊗ ℵy issound if ℵx, ℵy are sound.
Hypothesis : Assume that ℵx ⊗ ℵy ⊗ · · · ⊗ ℵz issound.
Induction step : we need to prove that ℵx ⊗ ℵy ⊗· · · ⊗ ℵz ⊗ ℵz+1 is also sound.
From the hypothesis, ℵx ⊗ℵy ⊗· · ·⊗zℵz is a soundworkflow.
If ⊗z ≡ ∧ then ℵx ⊗ ℵy ⊗ · · · ⊗z ℵz is a soundworkflow from Theorem 1.
If ⊗z ≡ ∨ then ℵx ⊗ ℵy ⊗ · · · ⊗z ℵz is a soundworkflow from Theorem 2.
if ⊗z ≡→ then ℵx ⊗ ℵy ⊗ · · · ⊗z ℵz is a soundworkflow from Theorem 11.
∴, the framework is scalable over operator ⊗.
4.9 Robustness of the Framework
To show that the proposed cooperative frameworkis correct and robust, the following criteria must beconsidered for the workflow: soundness, deadlock-freeness, livelock-freeness, and starvation-freeness[60, 61]. Soundness implies that the model is bothstructurally and behaviorally well-formed. ThroughTheorems 1-8, we have shown that the workflowpreserves the notion of soundness in different casesusing the cooperative operators, hence, we can saythat the overall framework preserves the notion ofsoundness.
Deadlock and livelock are a result of choice depen-dent structures. Similar to soundness, to prove thedeadlock-freeness and livelock-freeness of the pro-posed framework, we need to prove the deadlock-freeness and livelock-freeness for every proposedoperator as shown below.
Theorem 9 Having a cooperative workflow ℵ = ℵx∧ℵy , if ℵ is sound then ℵ is also deadlock-free andLivelock-free.
Proof ∵ ℵ is sound,∴ ℵx and ℵy are both sound.∵ ℵ = (pi, ti)∪ℵx ∪ℵy ∪(to, po) with pi = •ti and
ti = •ℵx and ti = •ℵy and to = ℵx• and to = ℵy•and to = •po
∴ ∀M ∈ pi, M ∈ iℵx and M ∈ iℵy
∵ ℵx and ℵy are both sound,∴ ∀M ∈ pi, M ∈ oℵx and M ∈ oℵy
∴ ∀M ∈ pi, M ∈ po
∴ ℵ is deadlock-free and livelock-free.
Theorem 10 Having a cooperative workflow ℵ =ℵx ∨ ℵy , if ℵ is sound then ℵ is also deadlock-free.
Proof ∵ ℵ is sound,∴ ℵx and ℵy are both sound.∵ ℵ = (pi, tix, tiy) ∪ ℵx ∪ ℵy ∪ (tox, , toypo) with
pi = •tix and pi = •tiy and tix = •ℵx and tiy = •ℵy
640
Cloud-Based Multi-Agent Cooperation for IoT Devices
and tox = ℵx• and toy = ℵy• and tox = •po andtoy = •po
∴ ∀M ∈ pi, M ∈ iℵx or M ∈ iℵy
∵ ℵx and ℵy are both sound,∴ ∀M ∈ pi, M ∈ oℵx or M ∈ oℵy
∴ ∀M ∈ pi, M ∈ po
∴ ℵ is deadlock-free and livelock-free.
Theorem 11 Having a cooperative workflow ℵ =ℵx → ℵy , if ℵ is sound then ℵ is also deadlock-free.
Proof ∵ ℵ is sound,∴ ℵx and ℵy are both sound.∵ ℵ = ℵx ∪ tm ∪ ℵy with tm = •ℵy and tm = ℵx•∴ ∀M ∈ iℵx , M ∈ oℵx
∴ ∀M ∈ iℵx , M ∈ iℵy
∴ ∀M ∈ iℵx , M ∈ oℵy
∴ ℵ is deadlock-free and livelock-free.
Starvation is the case when one or more transitionsdo not get enough resources for a token to fire. Theobjective of this article is to always guarantee an out-put of the cooperative workflow, which has alreadybeen proven by the proposed theorems. Starvation isguaranteed not to happen since workflows are provento be sound, deadlock-free, and livelock-free. The factthat the proposed framework is starvation-free is adirect result from all the proposed theorems.
5 Evaluation Results
Both simulations and implementations were con-ducted on the proposed cooperation framework. Sim-ulations are used to empirically demonstrate the cor-rectness of the framework. On the contrary, implemen-tations are used to test the validity of the framework.
5.1 Simulation Set-Up
A simulator was developed using C++ to implementthe cooperation algorithm described in Section 3.Details regarding the simulation setup were intro-duced in [23, 24] and are summarized below:
– Simulator input is a linear logic expression thatrepresents a cooperative plan using cooperativeoperator.
– Each input parameter represents a set of IoTagents and their capabilities. Such that, agents
represent IoT devices and their resource capabili-ties and their rational decision-making process.
– Capabilities correspond to actions that are per-formed, with a cost associated to each action.
– Actions that are not part of an agent’s set ofcapabilities have a cost set to infinity.
– Actions and their costs are assigned randomlyusing a uniformly distributed function.
The set of actions needed to achieve a task are usedto determine the set of agents that need to cooperate.Such cooperation is used to construct a cooperativeplan, that represents each agent capability and thedependency of the action execution. To simplify theproblem at hand, we randomly selected a plan forexecution, expressed as follows:
((((λA ∨ λE) → (λB ∨ λC)) → λD) ∧ (λG → λF ))
(31)
The presented plan corresponds to seven differentcapabilities, such that each capability corresponds toa device, and all are needed to execute the task. A setof 50 agents (i.e. IoT device) were used in 100 sim-ulation runs. The probability for an agent to withholda capability was controlled manually. For instance, inone of the simulation tests, we set the probability foran agent to withhold a certain capability to 0.3. Thisindicates that each one of the 50 agents would have a30% chance for possessing each of the 7 capabilitiesshown in (31). The execution time is calculated as thetotal execution cost of the workflow. Time units aredepicted in terms of transition costs in a workflow.
5.2 Simulation Results
Experiments were conducted to compare the execu-tion time needed to complete up to 1,000 tasks fordifferent plans and workflows, and Fig. 7 illustratesthe result of adapting four different plans. Plan[0]is a fully parallel non-cooperative plan used to exe-cute the requested tasks, Plan[1] is a fully cooperativeplan in which some form of parallelism is applied,Plan[2] is a partially cooperative plan where sometasks are performed in sequence and Plan[3] is a fullysequential non-cooperative non-parallel solution usedto complete the requested tasks. The results showthat the fully parallel solution completes the requestedtasks faster than the other solutions. However, thoughthere is a significant increase in terms of time, this
641
Y. Kotb et al.
0 100 200 300 400 500 600 700 800 900 10000
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2x 10
6
Number of Achieved Tasks (Tokens)
Tim
e (M
ilise
cond
s)
Plan[0]Plan[1]Plan[2]Plan[3]Average
Fig. 7 Number of achieved tasks versus time required to complete tasks for four sets of plans (full parallelism (Plan[0]), fullcooperation (plan[1]), partial cooperation (plan[2]), sequential (plan[3]))
solution has higher costs with respect to agent capa-bility replication, since each agent must acquire thefull set of capabilities needed to complete all tasks.This is considered either unrealistic, or it will causean unacceptably high cost for each agent. In con-trast, the fully cooperative solution has a similar delayfor task completion, and also outperforms the othersolutions in terms of the least cost for agent capabil-ities when the set of capabilities are divided amongthe set of agents. The figure also shows the delayincurred for both a partially cooperative plan and anon-cooperative sequential plan; the latter requiresmore time to complete the requested tasks.
Figure 8 illustrates two different cooperative work-flows used to execute a plan and compares them toa fully parallel execution. As shown in the algorithmpresented in Section 3, a back-tracking mechanism isadopted to choose the optimal solution among the setof workflows. In this particular example, two work-flows (WF1 and WF2) are created to achieve therequired tasks, and the one with the least delay (WF1)is chosen to execute the plan. Comparing WF1 to thefully parallel solution shows that their execution timesare similar. As stated previously, the cooperative solu-tion outperforms the fully parallel solution in terms ofthe cost required for agent capability requirements.
5.3 Implementation Experiment Set-up and Details
As stated earlier in this article, we adopted robots as anexample to showcase the effectiveness of collaborativeIoT devices in fog and cloud computing environments.It is important to note here, that, the considered exper-imental setup can be replicated to any IoT device thathas either sensing, computational, or storage capabil-ities. We assumed there are two sets of robot clustersin two separate rooms, as depicted in Fig. 9. A maptraversal problem was incorporated to compel a set ofrobots move from one location to another while avoid-ing certain obstacles (i.e. walls and furniture). Therobots can communicate with a fog computing node,which publishes and requests information to/from acloud computing storage site. The robots’ direction oftravel, represented by a dashed arrow, indicates thedetermined traversal path to the destination, which isrepresented by a solid circle. The robots are placedin two different rooms with the same furniture andlayout.
All robots are constructed from the GoPiGo robotkit [62] and connected to a Raspberry Pi 3 mini-computer [63]. The robots communicate wirelesslywith each other and the fog device. We assumed thatthe fog device is a computer equipped with an Intel
642
Cloud-Based Multi-Agent Cooperation for IoT Devices
0 100 200 300 400 500 600 700 800 900 10000
0.5
1
1.5
2
2.5
3x 10
6
Number of Achieved Tasks (Tokens)
Tim
e (M
ilise
cond
s)
WF1WF2AverageParallel
Fig. 8 Number of achieved tasks versus time required to complete tasks for a cooperative solution (WF1 and WF2) and a fully parallelsolution
Core i7-3520M CPU, 8GB RAM and 1TB storage.Robots R1 and R4 are equipped with a Raspberry Picamera used for office similarity detection (see Fig. 10a).Robot R2 is equipped with an ultrasonic sensor tomeasure the distance between objects (see Fig. 10b).Robots R3 and R5 do not have sensing capabilities,
and can only store and process information retrievedfrom other robots and the fog node (see Fig. 10c).
Since robots R3, R4 and R5 cannot move throughan office in a timely manner without colliding intoobstacles due to the lack of ultrasonic sensors, R4sends images of the surrounding environment to the
Cloud Fog Node
RouterGateway
Fig. 9 Tested real-time scenario using a set of five robots belonging to two different fog computing sites. Robots R1 and R2 belong tothe first cluster, and R3, R4 and R5 belong to the second cluster. The two clusters can share information and cooperate to accomplisha task
643
Y. Kotb et al.
(a) (b)
(c)
Fig. 10 Of the five robots used in the experiment, R1 and R4 are equipped with a Raspberry Pi camera, R2 is equipped with anultrasonic sensor, and R3 and R5 do not have sensing capabilities, and are only capable of storing and processing information
fog computing device. Using an image recognitionalgorithm [64], the fog computing device determinesthat the layout of the office is similar to an office asso-ciated with robots R1 and R2; thus robots R1 and R2determine a traversal path using their sensing capabili-ties (camera and ultrasonic), and build a traversal map.Traversal maps are represented as a 2-dimensionalgrid of cells; a cell being a region with a predefinedsize. The accuracy of the grid depends on its resolu-tion, which is the number of cells that occupy a squaremeter. Each cell is defined as a tuple T |T = (x, y, v),where (x, y) are the x− and y− coordinates, and v isthe status of the cell, such that:
v =⎧⎨
⎩
−1 non-explored path0 obstacle in the path
+1 safe path
Figure 11 depicts the final merged global map ofthe complete office area constructed by robots R1 andR2 in our example. Maps are built by cooperatingrobots in a distributed approach, and a mathematical
model is used to merge the learned sub-maps into oneglobal map. We define an operator ⊕ as the mergeoperator of the sub-maps. With a robot set R = {R1,R2, . . . , Rn} and a set of sub-maps M = {m1,m2, . . . , mn}, the learning process outcome is R×M.Since the outcome of the × operator is a set of mul-tiple sub-maps, we need to merge the sub-maps suchthat M = m1 ∪m2 ∪· · ·∪mn. This is performed usingthe ⊕ operator, such that mi ⊕ mj = ∀(x, y)|Xmin ≤X ≤ Xmax and Ymin ≤ Y ≤ Ymax , where Xmin =MIN(mi(x) ∪ mj(x)), and Xmax =MAX(mi(x) ∪ mj(x)), and Ymin = MIN(mi(y) ∪mj(y)), and Ymax = MAX(mi(y) ∪ mj(y)).Figure 12 is an example of two sub-maps generatedinitially by R1 and R2. The other sub-maps are gen-erated, and a merge process is initiated to create thefinal global map.
An issue that could arise is having two sub-mapspartially overlapping each other, with part of an areadiscovered by one robot also discovered by anotherrobot, as depicted in Fig. 13. An update mechanism isused for the cell status in overlapping areas, and when
644
Cloud-Based Multi-Agent Cooperation for IoT Devices
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
00000000000000
000000000
000000000
0 0
0 00
000000
000000
0 0 0
0 0 0
00
0
000
00
0000
00
0
0000
0
000000000 0
0000 0
0 0 0 0 0 0 0 0 0 0 0+1+1+1
+1+1+1+1
+1 +1
+1+1
+1+1
+1+1 +1 +1
+1+1+1
+1+1+1+1
+1 +1 +1 +1 +1+1
+1+1+1+1+1+1+1+1+1+1+1
-1-1-1-1-1-1-1-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1-1
-1-1-1-1
-1-1
0
00
-1-1 -1
-1-1-1
-1-1
-1-1-1-1-1
-1
-1 -1-1
-1-1-1-1-1
-1-1-1
-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1
-1-1-1-1
-1-1
-1
-1-1 -1 -1
-1-1-1-1-1
-1-1-1-1
-1-1-1
x-axis
y-ax
is
Fig. 11 A merged global map showing the explored office area, where -1 indicates a non-explored path, 0 an obstacle in the path and+1 a safe path
comparing the cell status from the two maps the newcell status v∗ is determined as follows:
−1 0 +1
v∗ =−10
+1
⎡
⎣−1 0 +10 0 0−1 0 +1
⎤
⎦
If two robots have the same cell status, the new cellstatus is not modified. However, if one of the robotshas a cell status of -1 (unexplored) and the other hasa cell status of 0 (obstacle), the new cell status wouldalso be 0. Similarly, if one robot has a cell status of-1 and the other has a cell status of +1 (safe path), thenew cell status would also be +1. In addition, if oneof the robots has a cell status of 0 and the other has a
x-axis
y-ax
is
0000
0000
0000
00
+1+1+1+1
-1-1-1-1-1-1-1
-1-1-1-1-1-1-1-1-1
-1 -1 -1-1-1-1-1 0
0-1-1-1 -1 00R2
000000000 0
+1+1
+1+1
+1+10 -1
-1-1-1-1-1
-1
-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1
R1
Sub-Map (m1)
Sub-Map (m2)
Ymax
Ymin
Xmin Xmax
Fig. 12 Two sub-maps generated by robots R1 and R2 located within the maximum and minimum allowable coordinates of the x-and y-axis for the global map
645
Y. Kotb et al.
R2R1
Sub-Map (m1)
Sub-Map (m2)
Overlapping Explored Areas
Fig. 13 Overlapping in two sub-maps
cell status of +1, the new cell status is set to 0 to avoidcollisions.
We use induction to prove the scalability of the ⊕operator as follows:
Base: Given two maps m1 and m2, m = m1 ⊕ m2
from the definition given above.Hypothesis: Let m = m1 ⊕ m2 ⊕ · · · ⊕ mk .Inductive step: Proof that m = m1 ⊕ m2 ⊕ · · · ⊕
mk ⊕ mk+1.
From the hypothesis, let mt = m1 ⊕m2 ⊕· · ·⊕mk ,therefore m = m1 ⊕ m2 ⊕ · · · ⊕ mk ⊕ mk+1 = mt ⊕mk+1. Therefore, from the base step, m = mt ⊕mk+1.
Once a global map is generated, it is shared withrobots R3, R4 and R5 via the fog computing node. Therobots cooperate, and robot R4 with a camera sensorinforms robots R3 and R5 of their locations relative
to the shared global map. Then a follow-the-leadertraversal solution is adopted, and R3 and R5 con-stantly inform R4 of their cell locations. Essentially,robot R4 guides the others through the safe path.
5.4 Implementation Experiment Results
Various test sets were performed on the robots toassess the effectiveness of the cooperation method.Three techniques were adopted: i) a cooperative solu-tion in which robots from different locations con-nected through the fog node cooperate to complete atask; ii) a semi-cooperative solution in which robotsin the same location can only cooperate, without con-nection to the fog node; and iii) a non-cooperativesolution in which robots must complete the taskindividually. The results in Fig. 14 show that using the
0
400
800
1200
1600
R1 R2 R3 R4 R5
)ces( emiT tne
meveihcA ksaT
Robots
Coopera�ve
Semi-Coopera�ve
Non-Coopera�ve
Infinity
Fig. 14 Task completion time using Cooperative, Semi-Cooperative and Non-Cooperative techniques
646
Cloud-Based Multi-Agent Cooperation for IoT Devices
0
10
20
30
40
R1 R2 R3 R4 R5
elcatsbO
snoisilloC
Robots
Coopera�ve
Semi-Coopera�ve
Non-Coopera�ve
Infinity
Fig. 15 Number of robot collisions with obstacles using Cooperative, Semi-Cooperative and Non-Cooperative techniques
semi- and non-cooperative techniques prevents robotsR3 and R5 from accomplishing the task. This is dueto their inability to traverse a safe path without priorknowledge of the relative distances between them andsurrounding objects, given their lack of sensing capa-bilities. On the contrary, robots R1 and R2, are capableof moving in the room using the semi- and non-cooperative approaches. Although sensing capabilitiessuch as the camera and ultrasonic sensors allow themto find a traversal path, it takes them significantlylonger. Thus, the cooperative approach is the optimalsolution, with robots R3, R4 and R5 determining a safepath in the shortest time.
In addition to the task completion time test, anotherexperiment tested the effectiveness of the proposedtechnique in terms of collision avoidance. The resultsin Fig. 15 show that robot R4 had no collisions whenusing the cooperative technique, and the number of
collisions for the robots without sensing capabilitiesare significantly reduced to two or three.
Path accuracy was also experimentally evaluated totest the effectiveness of the proposed solution. A robotis said to be accurate if it follows the determined path;that is, the selected set of cells from source to destina-tion. The results in Fig. 16 show that the cooperativeapproach achieves almost perfect accuracy for all therobots. With the semi-cooperative approach, robots R3and R5 had very low accuracy due to their inability toprecisely determine their location with respect to sur-rounding objects. Similarly, with the non-cooperativeapproach, robots R3 and R5 had an accuracy rate ofonly 2–3%, due to having neither on-board sensors norcommunication capabilities with the other robots. Theexperiments showed that the cooperative approach notonly accomplishes the required task, but does so in atimely, accurate and efficient manner.
0
20
40
60
80
100
R1 R2 R3 R4 R5
)%( ycaruccA
RobotsCoopera�ve Semi-Coopera�ve Non-Coopera�ve
Fig. 16 Accuracy of each robot with respect to the intended traversal path using Cooperative, Semi-Cooperative and Non-Cooperativetechniques
647
Y. Kotb et al.
6 Conclusion and Future Work
The management process of distributed IoT deviceswithin different fog computing sites has proven tobe a challenging task. The design and implementa-tion of fog-based cooperative frameworks adapted forservice delivery to IoT devices should consider theplethora of capabilities available in the cloud andfog computing environment. This article proposed aPetri-net based cooperative framework for fog-basedIoT systems. The framework provided an algorithmto compose workflows based on similarities amongIoT device agent capabilities that belong to differentfog computing sites. It gives agents the opportunityto cooperate in order to complete the selected tasks.The dynamic behavior of the framework was ver-ified by examining its reachability, soundness andscalability criteria. Examples of using IoT roboticagents to define and provide solutions for cooperationissues were provided throughout the article. Resultsgathered from both simulations and real-time exper-iments indicated that the proposed framework pro-vides acceptable cooperation among IoT devices, in atimely and efficient manner when compared againstexisting work. According to the experiment results,task achievement in a cooperative approach can beachieved seven times faster with more accuracy whencompared against a non-cooperative approach.
Many open research areas still remain to be inves-tigated. One main issue that arises from cooperationand resource sharing is the willingness of differentfog computing sites to cooperate. Since fog computingsites may belong to different network providers, fogcomputing nodes and IoT devices may not cooperateunless some form of incentives and profit sharing isguaranteed. Another issue that may arise from coop-eration is security and privacy [65]. Some approachesthat may be used to tackle such issue is to use arti-ficial intelligence to analyze and classify data traffic.Although solid solutions still do not exist, we believethat in the near future, promising solutions are yet tobe discovered.
References
1. Gharibi, M., Boutaba, R., Waslander, S.L.: Internet ofdrones. IEEE Access 4, 1148–1162 (2016)
2. Semeniuta, O., Falkman, P.: Flexible image acquisition ser-vice for distributed robotic systems. In: 2018 Second IEEEInternational Conference on Robotic Computing (IRC),pp. 106–112 (2018)
3. Prado, J., Yandun, F., Torriti, M.T., Cheein, F.A.: Overcom-ing the loss of performance in unmanned ground vehichlesdue to the terrain variabilitiy. IEEE Access 6, 17391–17406(2018)
4. Alnasser, A., Sun, H.: A fuzzy logic trust model for securerouting in smart grid networks. IEEE Access 5, 17896–17903 (2017)
5. Zhang, N., Yang, P., Ren, J., Chen, D., Yu, L., Shen, X.:Synergy of big data and 5g wireless networks: opportuni-ties, approches, and challenges. IEEE Wirel. Commun. 25,12–18 (2018)
6. Mohanarajah, G., Hunziker, D., D’Andrea, R., Waibel, M.:Rapyuta: a cloud robotics platform. IEEE Trans. Autom.Sci. Eng. 12, 481–493 (2015)
7. Krasovec, B., Filipcic, A.: Enhancing the grid with cloudcomputing. Journal of Grid Computing 17, 119–135 (2019)
8. Masip-Bruin, X., Marin-Todera, E., Tashakor, G., Jukan,A., Ren, G.J.: Foggy clouds and cloudy fogs: a real needfor coordinated management of fog-to-cloud computingsystems. IEEE Wirel. Commun. 23, 120–128 (2016)
9. Sun, X., Ansari, N.: Edgeiot: mobile edge computing for theinternet of things. IEEE Commun. Mag. 54, 22–29 (2016)
10. Ridhawi, I.A., Kotb, Y., Ridhawi, Y.A.: Workflow-net basedservice composition using mobile edge nodes. IEEE Access5, 23719–23735 (2017)
11. Shames, I., Fidan, B., Anderson, B.D.O., Hmam, H.: Coop-erative self-localization of mobile agents. IEEE Trans.Aerosp. Electron. Syst. 47, 1926–1947 (2011)
12. Cao, J., Wang, X., Das, S.K.: A framework of using coop-erating mobile agents to achieve load sharing in distributedweb server groups. Futur. Gener. Comput. Syst. 20(4), 591–603 (2004). Advanced services for Clusters and Internetcomputing
13. Lei, Y., Junxing, Z.: Service composition based on multi-agent in the cooperative game. Futur. Gener. Comput. Syst.68, 128–135 (2017)
14. Yu, Y., Hu, R.Q., Bontu, C.S., Cai, Z.: Mobile associationand load balancing in a cooperative relay cellular network.IEEE Commun. Mag. 49, 83–89 (2011)
15. van der Aalst, W.M.P.: The application of petri nets toworkflow management. Journal of Circuits, Systems, andComputers 8(1), 21–66 (1998)
16. van der Aalst, W.: Verification of workflow nets. In: Pro-ceedings of the 18th International Conference on Applica-tion and Theory of Petri Nets, pp. 407–426 (1997)
17. van der Aalst, W.M.P.: Interorganizational workflows: anapproach based on message sequence charts and petri nets.Syst. Sci. 34(3), 335–367 (1999)
18. Savaglio, C., Fortino, G., Ganzha, M., Paprzycki, M.,Badica, C., Ivanovic, M.: Agent-based computing in theinternet of things: a survey, pp. 307–320. Springer Interna-tional Publishing, Cham (2018)
19. Ridhawi, I.A., Kotb, Y., Aloqaily, M., Kantarci, B.: Aprobabilistic process learning approach for service com-position in cloud networks. In: 2017 IEEE 30th Canadian
648
Cloud-Based Multi-Agent Cooperation for IoT Devices
Conference on Electrical and Computer Engineering(CCECE), pp. 1–6 (2017)
20. Baker, T., Rana, O.F., Calinescu, R., Tolosana-Calasanz,R., Banares, J.A.: Towards autonomic cloud services engi-neering via intention workflow model. In: Altmann, J.,Vanmechelen, K., Rana, O.F. (eds.) Economics of Grids,Clouds, Systems, and Services, pp. 212–227. SpringerInternational Publishing, Cham (2013)
21. Luo, C., Yang, S.X., Li, X., Meng, M.Q.H.: Neural-dynamics-driven complete area coverage navigationthrough cooperation of multiple mobile robots. IEEETrans. Ind. Electron. 64, 750–760 (2017)
22. Aloqaily, M., Kantarci, B., Mouftah, H.T.: Fairness-awaregame theoretic approach for service management in vehic-ular clouds. In: 2017 IEEE 86th Vehicular TechnologyConference (VTC-Fall), pp. 1–5. IEEE (2017)
23. Kotb, Y.: Workflow-net based cooperative multi-agent sys-tems. PhD thesis, The University of Western Ontario,London, ON (2011)
24. Kotb, Y.: Work-flow nets for multi-agent cooperation, Tech.Rep. London, ON (2011)
25. Javaid, N., Hafeez, T., Wadud, Z., Alrajeh, N., Alabed,M.S., Guizani, N.: Establishing a cooperation-based andvoid node avoiding energy-efficient underwater wsn for acloud. IEEE Access 5, 11582–11593 (2017)
26. Iqbal, Z., Kim, K., Lee, H.: A cooperative wireless sensornetwork for indoor industrial monitoring. IEEE Trans. Ind.Inf. 13, 482–491 (2017)
27. He, Y., Sun, D., Zhao, M., Cheng, S.: Cooperative driv-ing and lane changing modeling for connected vehicles inthe vicinity of traffic signals: a cyber-physical perspective.IEEE Access 6, 13891–13897 (2018)
28. Ridhawi, I.A., Aloqaily, M., Kantarci, B., Jararweh, Y.,Mouftah, H.T.: A continuous diversified vehicular cloudservice availability framework for smart cities. Comput.Netw. 145, 207–218 (2018)
29. Aloqaily, M., Otoum, S., Al Ridhawi, I., Jararweh, Y.: Anintrusion detection system for connected vehicles in smartcities, Ad Hoc Networks (2019)
30. Otoum, S., Kantarci, B., Mouftah, H.T.: On the feasibil-ity of deep learning in sensor network intrusion detection,IEEE Networking Letters (2019)
31. Otoum, S., Kantarci, B., Mouftah, H.: Adaptively super-vised and intrusion-aware data aggregation for wirelesssensor clusters in critical infrastructures. In: 2018 IEEEInternational Conference on Communications (ICC), pp. 1–6. IEEE (2018)
32. Alkheir, A.A., Aloqaily, M., Mouftah, H.T.: Connected andautonomous electric vehicles (caevs). IT Professional 6,54–61 (2018)
33. Fortino, G., Savaglio, C., Zhou, M.: Toward opportunisticservices for the industrial internet of things. In: 2017 13thIEEE Conference on Automation Science and Engineering(CASE), pp. 825–830 (2017)
34. Balasubramanian, V., Aloqaily, M., Zaman, F., Jararweh,Y.: Exploring computing at the edge: a multi-interface sys-tem architecture enabled mobile device cloud. In: 2018IEEE 7th International Conference on Cloud Networking(CloudNet), pp. 1–4. IEEE (2018)
35. Aloqaily, M., Balasubramanian, V., Zaman, F., Al Rid-hawi, I., Jararweh, Y.: Congestion mitigation in denselycrowded environments for augmenting qos in vehicularclouds. In: Proceedings of the 8th ACM Symposium onDesign and Analysis of Intelligent Vehicular Networks andApplications, pp. 49–56. ACM (2018)
36. Aloqaily, M., Ridhawi, I.A., Salameh, H.B., Jararweh, Y.:Data and service management in densely crowded environ-ments: challenges, opportunities, and recent developments.IEEE Commun. Mag. 57, 81–87 (2019)
37. Memon, S., Jens, J., Willem, E., Neukirchen, H., Book, M.,Riedel, M.: Towards federated service discovery and iden-tity management in collaborative data and compute cloudinfrastructures. Journal of Grid Computing 16, 663–681(2018)
38. Chunlin, L., Jianhang, T., Youlong, L.: Hybrid cloud adap-tive scheduling strategy for heterogeneous workloads. Jour-nal of Grid Computing 18, 1–28 (2019)
39. Oliveira, D., Brinkmann, A., Rosa, N., Maciel, P.: Per-formability evaluation and optimization of workflow appli-cations in cloud environments. Journal of Grid Computing18, 1–22 (2019)
40. Yousefpour, A., Ishigaki, G., Gour, R., Jue, J.P.: On reduc-ing iot service delay via fog offloading. IEEE InternetThings J. 5, 998–1010 (2018)
41. Al-khafajiy, M., Baker, T., Al-Libawy, H., Maamar, Z.,Aloqaily, M., Jararweh, Y.: Improving fog computing per-formance via fog-2-fog collaboration. Futur. Gener. Com-put. Syst. 100, 266–280 (2019)
42. Pandey, P., Pompili, D., Yi, J.: Dynamic collabora-tion between networked robots and clouds in resource-constrained environments. IEEE Trans. Autom. Sci. Eng.12, 471–480 (2015)
43. Wang, L., Liu, M., Meng, M.Q.H.: A hierarchical auction-based mechanism for real-time resource allocation in cloudrobotic systems. IEEE Transactions on Cybernetics 47,473–484 (2017)
44. Li, T.H.S., Liu, C.Y., Kuo, P.H., Chen, Y.H., Hou, C.H., Wu,H.Y., Lee, C.L., Lin, Y.B., Yen, W.H., Hsieh, C.Y.: Recip-rocal learning for robot peers. IEEE Access 5, 6198–6211(2017)
45. Fink, J., Ribeiro, A., Kumar, V.: Robust control of mobil-ity and communications in autonomous robot teams. IEEEAccess 1, 290–309 (2013)
46. Luo, C., Yang, S.X., Li, X., Meng, M.Q.H.: Neural-dynamics-driven complete area coverage navigationthrough cooperation of multiple mobile robots. IEEETrans. Ind. Electron. 64, 750–760 (2017)
47. Waibel, M., Beetz, M., Civera, J., D’Andrea, R., Elfring, J.,Galvez-Lopez, D., Haussermann, K., Janssen, R., Montiel,J.M.M., Perzylo, A., Schießle, B., Tenorth, M., Zweigle,O., De Molengraft, R.V.: Roboearth. IEEE Robot. Autom.Mag. 18, 69–82 (2011)
48. van der Aalst, W., Hee, V., Houben, G.: Modelling andanalysing workflow using a petri-net based approach. In:Proceeding of the Second Workflow on Computer Sup-port Cooperative Work, Petri Nets and Related Formalisms,pp. 31–50 (1994)
649
Y. Kotb et al.
49. Chebbi, I., Tata, S., Dustdar, S.: The view-based approachto dynamic inter-organizational work-flow cooperation,Tech. Rep. TUV-1841-2004-23, Vienna University of Tech-nology, Salzburg, Austria (2004)
50. Grigori, D., Charoy, F., Godart, C.: Coo-flow: a processtechnology to support cooperative processes. Int. J. Softw.Eng. Knowl. Eng. 14(01), 61–78 (2004)
51. Al Ridhawi, I., Aloqaily, M., Kotb, Y., Al Ridhawi, Y.,Jararweh, Y.: A collaborative mobile edge computing anduser solution for service composition in 5g systems. Trans-actions on Emerging Telecommunications Technologies19(11), e3446 (2018)
52. Al Ridhawi, I., Kotb, Y.: A secure workflow-net model forservice-specific overlay networks. In: Kim, K.J., Joukov,N. (eds.) Mobile and Wireless Technologies 2017, pp. 389–399. Springer, Singapore (2018)
53. Ridhawi, I.A., Mostafa, N., Kotb, Y., Aloqaily, M., Abual-haol, I.: Data caching and selection in 5g networks usingf2f communication. In: 2017 IEEE 28th Annual Interna-tional Symposium on Personal, Indoor, and Mobile RadioCommunications (PIMRC), pp. 1–6 (2017)
54. Ridhawi, I.A., Kotb, Y.: A secure service-specific overlaycomposition model for cloud networks. Software Network-ing 2017(1), 221–240 (2017)
55. Kendrick, P., Baker, T., Maamar, Z., Hussain, A., Buyya,R., Al-Jumeily, D.: An efficient multi-cloud service compo-sition using a distributed multiagent-based, memory-drivenapproach. IEEE Transactions on Sustainable Computing,1–1 (2019)
56. Wei, T., Yushun, F., MengChu, Z., MengChu, Z.: A petrinet-based method for compatibility analysis and compo-sition of web services in business process execution lan-guage. IEEE Trans. Autom. Sci. Eng. 6, 94–106 (2009)
57. Du, Y., Li, X., Xiong, P.: A petri net approach to mediation-aided composition of web services. IEEE Trans. Autom.Sci. Eng. 9, 429–435 (2012)
58. Kindler, E., Martens, A., Reisig, W.: Inter-operability ofworkflow applications: Local criteria for global sound-ness. Lecture Notes in Computer Science, Business processmanagement 1806, 235–253 (2000)
59. Liu, G.: Some complexity results for the soundness problemof workflow nets. IEEE Trans. Serv. Comput. 7, 322–328(2014)
60. Liu, G., Zhou, M., Jiang, C.: Petri net models and collabo-rativeness for parallel processes with resource sharing andmessage passing. ACM Trans. Embed. Comput. Syst. 16,113:1–113:20 (2017)
61. Wang, M., Liu, G., Zhao, P., Yan, C., Jiang, C.: Behaviorconsistency computation for workflow nets with unknowncorrespondence. IEEE/CAA Journal of Automatica Sinica5, 281–291 (2018)
62. Gopigo. https://www.dexterindustries.com/gopigo3/.Accessed: 2018-04-17
63. Raspberry pi. https://www.raspberrypi.org/. Accessed:2018-04-17
64. Lemaire, T., Berger, C., Jung, I.-K.: Lacroix, and Simon,Vision-based slam: Stereo and monocular approaches. Int.J. Comput. Vis. 74, 343–364 (2007)
65. Zhang, P., Zhou, M., Fortino, G.: Security and trust issuesin fog computing: a survey. Futur. Gener. Comput. Syst. 88,16–27 (2018)
Publisher’s Note Springer Nature remains neutral withregard to jurisdictional claims in published maps and institu-tional affiliations.
650