Task Placement on Fog Computing Made Efficient for IoT ...downloads.hindawi.com/journals/wcmc/2019/6215454.pdf · as computational power, data organization and indexing, and functional

Research ArticleTask Placement on Fog Computing Made Efficient forIoT Application Provision

Minh-Quang Tran Duy Tai Nguyen Van An Le Duc Hai Nguyen and Tran Vu Pham

Ho Chi Minh City University of Technology VNU-HCM Vietnam

Correspondence should be addressed to Minh-Quang Tran quangtranhcmuteduvn

Received 23 July 2018 Revised 23 November 2018 Accepted 20 December 2018 Published 10 January 2019

Guest Editor Antonio Moschitta

Copyright copy 2019 Minh-Quang Tran et al This is an open access article distributed under the Creative Commons AttributionLicense which permits unrestricted use distribution and reproduction in any medium provided the original work is properlycited

Fog computing is one of the promising technologies for realizing global-scale Internet of Things (IoT) applications as it allowsmoving compute and storage resources closer to IoT devices where data is generated in order to solve the limitations in cloud-basedtechnologies such as communication delay network load energy consumption and operational cost However this technology isstill in its infancy stage containing essential research challenges For instance what is a suitable fog computing scheme whereeffective service provision models can be deployed is still an open question This paper proposes a novel multitier fog computingarchitecture that supports IoT service provisioning Concretely a solid service placement mechanism that optimizes servicedecentralization on fog landscape leveraging context-aware information such as location response time and resource consumption ofservices has been devisedThe proposed approach optimally utilizes virtual resources available on the network edges to improve theperformance of IoT services in terms of response time energy and cost reduction The experimental results from both simulateddata and use cases from service deployments in real-world applications namely the intelligent transportation system (ITS) in HoChiMinhCity show the effectiveness of the proposed solution in terms ofmaximizing fog device utilization while reducing latencyenergy consumption network load and operational cost The results confirm the robustness of the proposed scheme revealing itscapability to maximize the IoT potential

1 Introduction

The Internet of Things (IoT) has emerged as a revolutionarytechnology that offers a fully connected ldquosmartrdquo world thataccelerates the 4th industrial revolution where thousands ormillions of things in the physical world are connected witheach other These things share data and services to specifymonitor and manage the physical world thereby smart cityhealthcare agriculture services and applications are enabledto transform the way we work play and live improving thequality of life and the human civilization

Realization of IoT services in a large scale however ishindered due to the constraints of IoT devices (embedded oneveryday objects such as consumer goods enduring productsvehicles utility components sensors and other physicaldevices) in terms of computing resources memory capacityenergy and bandwidth limitations Many of these issues

could be resolved by employing the Cloud-Assisted Internetof Things or Cloud-of-Things (CoT) technology as it offerslarge-scaled and on-demand networked computing resourcesto manage store process and share IoT data and services [1]

Nevertheless the CoT paradigm is facing increasingdifficulties to handle Big Data generated by IoT servicesassociated with beyond billions of connected devices Asthese devices are frequently (eg in every second or evenshorter intervals) generating data a large amount of datais generated every moment (exabytes of data per day) Ifevery IoT captured data pattern is transferred to data centers(DCs) on the cloud for processing and storage and thenanother large amount of information is returned to usersor to actuators on the physical world a huge volume oftraffic is pumped into the network making it congested ormalfunctioned Obviously this process challenges systemsrsquoperformance and robustness in terms of ensuring low latency

HindawiWireless Communications and Mobile ComputingVolume 2019 Article ID 6215454 17 pageshttpsdoiorg10115520196215454

2 Wireless Communications and Mobile Computing

and network bandwidth consumption optimal utilization ofcomputational resources and scalability

In fact most of IoT data and services are generatedand consumed by local users Therefore to cope with theaforementioned issues a recent trend is to devise effectiveedge computing infrastructures termed as Edge-of-Things(EoT) computing edge computing or fog computing [2] Fogcomputing allows moving compute and storage resourcescloser to IoT devices where data is generated Fog computingdevices could be smart gateways or routers deployed at thenetwork edge local PCs and even mobile devices such assmartphones or tablets carried by users that can offer com-puting and storage capabilities These devices play their ownroles of determining what data should be stored or processedlocally (for low latency and saving network bandwidth) andwhat needs to be sent to the cloud for further analysis Itis clear that EoT complements CoT paradigm in terms ofproviding high scalability low delay and location awarenessand leveraging local resources which are available at thenetwork edges

Although the benefit of fog computing in the IoTs is clearand the basic ideas of this computing paradigm have beenwell stated in various researches [3 4] there still lacks sys-tematical modeling for practical fog computing frameworksand effective service placement approaches to maximize theutilization of existing devices on the fog landscape while sat-isfying application response times and reducing energy andoperation cost In this article we propose a novel approachto task placement on fog computing made efficient for IoTapplication provision The main contributions of this workare summarized as follows

(i) We propose a systematical fog computing frameworkconsisting of multiple intelligent tiers that effectively supportIoT service decentralization

(ii) We devise an efficient task (service) placementapproach to optimizing service decentralization on fog com-puting landscape leveraging context-aware information suchas location compute and storage capacities of fog devices andexpected deadline of an application and hence maximize theutilization of fog devices that are available at the networkedge and minimize the latency energy consumption andcost

(iii) We conduct a thorough feasibility and performanceanalysis with various simulations The results provide acomprehensive understanding of the effectiveness of theproposed approach in terms of maximizing the utiliza-tion of fog devices while reducing latency energy con-sumption and network load In addition the experimen-tal results with service deployment in real-world applica-tions that we have built for a smart city ecosystem inHo Chi Minh City such as the intelligent transportationsystem (ITS) show the feasibility of the proposed solutionThese results demonstrate the robustness of the proposedscheme revealing its capability to maximize the IoT poten-tial

The rest of the paper is organized as follows Section 2reviews related work The overall architecture and problemdefinition are described in Section 3 The proposed serviceplacement mechanism is presented in Section 4 Section 5

describes the evaluation of the proposed approach whileSection 6 concludes the paper

2 Related Work

Most of the existing IoT related projects assume the avail-ability of centralized data centers based on a cloud-centricapproach [5] A typical example is described in [6] whichaddresses necessary components of a cloud-centric IoT archi-tecture The authors proposed a federation between a privatecloud (eg Aneka their own system) and a public cloud (egMicrosoft Azure cloud) to efficiently handle sensing datafrom wireless sensor networks (WSNs) In the networkingaspects this approach focused on access networks whileignoring the core networks Consequently it could not satisfythe effectiveness required in IoT as global services are mainlycomputed on the cloud and transmitted and managed overthe core networks

There are several works to reinforce the shortage ofcloud-centric IoT approaches by employing localization ofcomputing resource [2 3 7] The work in [7] describes aLocality-Based Utility Computing (LUC) Operating SystemThese utilities are distributed over the network backbonessuch as local servers connecting to routers aiming to providethe computing resources The motivation of this work issimilar to our present paper which is instead of buildingbigger and bigger data centers and oversized networks weshould bring resources near to the network edges or userswhere the IoT data is created Unfortunately the workin [7] had not utilized context-aware information such aslocation awareness and other related information to improveits effectiveness but keeps location awareness for futurework

Deploying miniclouds or private clouds on the networkedges to handle IoT data processing and service provisioninghas extracted numerous researches [8 9] Having smallclouds ormicrodata centers at the edges can help to efficientlydeliver services closer to users hence mitigating trafficbombing on the network and reducing communication costIn order to direct research to a more standardized approachCisco proposed the fog computing concept in a seminalstudy in [2] Fog computing is a highly virtualized platformthat provides compute storage and networking servicesbetween end devices and traditional cloud computing datacenters typically but not exclusively located at the edge ofnetwork

Several studies such as [8 10] discuss the challengespotential applications and benefits of fog computing It isconsidered a complementary technique to cloud comput-ing that provides the missing links in the cloud-to-thingcontinuum in the IoT paradigm [11 12] Studies in [13]analyze the essential roles of fog computing for extendingcontinuous links of IoT data and services from the cloudto the network edges Meanwhile studies in [14] proposearchitectural imperatives for fog computing and analyze usecases requirements and architectural techniques for fog-enabled IoT networks

Wireless Communications and Mobile Computing 3

Although there are several proposals that help researcheson fog computing converge to some extent to standardiza-tion Fog computing is still in its infancy stage containinginherent difficulties that need to be thoroughly investigatedFor instance what is a suitable fog computing schemewhere effective and efficient service provision models can bedeployed is still an open challenge

There are numerous studies in the area of resourceprovisioning in distributed environments such as in cloudcomputing [15 16] and mobile cloud computing [17 18]Although service provisioning problems in fog computingshare similar concepts and research issues with virtualmachine placement problems in edge networks as discussedin [19 20] the existing approaches cannot be directlyapplied to fog computing One of the reasons is that foglandscapes are usually more volatile compared to those ofcloud environments hence more context-aware informationaround fog landscapes and Things should be utilized toeffectively adopt with the dynamic change of large-scaled IoTenvironments

In order to resolve the difficulties discussed above severalrecent researches have been dedicated to resource allocationproblems in edge and fog computing by investigating variousimperatives [14] A study in [21] proposes a fog computingplatform where software modules are dynamically deployedon end devices (Things) while the study in [22] introducesa model that effectively allocates computing resources onnetwork edges to process local and regional data In anotherdirection such as in [23] the authors introduce solutions forQoS-aware service allocation in fog computing as a basicoptimization problem More recent work in [24 25] inves-tigates a conceptual framework for the service provisioningproblem in fog computing These studies propose interestingconcepts of fog cells as software modules running on IoTnodes and orchestrating models of these cells for handlingservices

Our proposed fog computing scheme in this presentpaper is closely related to Ciscorsquos Fog computing model[2] One of the major differences in our work compared toexistingwork discussed above is that the computing resourcesin our newly proposed approach are more flexibly designedand allocateddistributed in accordance with context-awareinformation specifically location network condition type ofservice and quality of the service (QoS in terms of expectedresponse time) Concretely location identifies the location ofIoT data sources or sinks which help to effectively determinewhere on the fog landscape a particular service should bedeployed in accordance with network conditions and theconstraint of the service type This context is useful for opti-mally distributing services on the fog in terms ofmaximizingvirtualized resources available along network edge whilesatisfying the expected response time of applications anothercontext required by usersconsumers

There are also references on the passive microdatacenterthat is rechargeable datacenter (eg using solar energy)at a very small scale [26] This datacenter concept can beextended and applied in our proposed architecture where notonly energy but also communication delay can be reducedby reasonably deploying compute and storage services such

as computational power data organization and indexingand functional computing on these datacenters Howeveras mentioned before the existing work on fog comput-ing has not effectively utilized context-aware informationfor optimizing IoT resources to maximize its potential[7]

In this present work we thoroughly extend our previousstudy on task placement on fog landscapes [27] Concretelywe analyze context-aware information that is necessary foreffectively provisioning fog services As a result resourceallocation is effectively conducted improving the qualityof services such as reducing communication latency andmitigating network load while saving energy and deploy-ment costs significantly In addition we provide a thoroughanalysis on experimental results with service deployment inreal-world applications for a smart city ecosystem in Ho ChiMinh City such as the ITS to confirm the effectiveness andthe robustness of the proposed scheme

3 Context-Aware Multitier FogComputing Scheme

This section presents the proposed context-aware multitierfog computing architecture for IoTs where necessary contextinformation and concepts related to task placement in theproposed scheme are described

31 Context-Aware IoT Service Provision As discussed con-text information could be useful for IoT service provisionmeanwhile context-aware solutions for effectively utilizingIoT resources have not been thoroughly addressed in theexisting technologies [7] This section describes fundamen-tal context used in the proposed multitier fog computingscheme

The notion of context has been observed in numerousareas including linguistics knowledge discovery artificialintelligent information retrieval reasoning and theory ofcommunications [28 29] As a high level of abstractioncontext is defined as ldquothat which surrounds and gives meaningto something elserdquo In this definition ldquosomethingrdquo can be anartifact a building a person a computer system or evenan assertion in logic as ldquocontext is any information that canbe used to characterize the situation of an entity An entityis a person place or object that is considered relevant to theinteraction between a user and an application including theuser and applications themselvesrdquo [30]

In the IoT environment context includes but is notlimited to location network condition and type of servicequality of service In this work context information used forservice placement is described as follows

(i) Location identifies the location of IoT devicesuserswhere IoT data is generated or consumed Thiscontext is more useful for service placement whenit is associated with network topology and compu-tation scheme (eg fogedge computing scheme) inthe proposed multitier model presented in the nextsection


(ii) Network Condition describes the current networkcondition such as topology and resource (computa-tion storage) available at each node and communi-cation quality (delay and packet loss) between nodes

(iii) Type of Service specifies servicersquos features suchas sensing actuating computing and storing whichdefine the possibility of deploying a particular serviceon a specific nodedevice based on its resource avail-ability (eg a storing service cannot be conducted ata light-weight sensor without storage capacity)

(iv) Quality of a Service (QoS) describes the expectedQoS when usersconsumers receive a service upontheir request This work utilizes the response time asthe indicator for QoS

Obviously the above context information is relevant foroptimization of dataservice placement allocating resources(computing storage and communications) in the IoT wherethere are a large number of devices and a huge amount ofcomplicated services However it could be difficult to applythis concept of context-aware IoT service provision in theconventional Internet architecture To realize this approachwe proposed a new computing scheme namely the multitierfog computing architecture presented in the next section

It is worth to be noticed that the context is dynami-cally changed specifically in the IoT environment How toeffectively deal with dynamic context complying with therequirements of applications especially new arrival onesis an open challenge It is not always good if the serviceplacement solutions immediately change upon any changeof the context and requirements as the service placementalgorithms need to back-and-forth scan the environmentcondition On the other hand if the context information isnot affected in time the context could be useless In orderto overcome this dilemma the proposed service placementmethod evaluates context and resolves the service placementproblems in appropriate time period namely placement turnas presented in Section 431 Here the duration of a turnis dynamically estimated by the response time of all tasksassigned in the current turn at a particular node New arrivalnodes will be stored in a waiting queue which is processed inthe next turn with updated context information

32 Overall Architecture The natural features of an IoTsystem are its complicated connections between a hugenumber of devices while the provision of data and services isspecific to application domains (eg healthcare agriculturetraffic) IoT devices are distributed almost everywhere inthe physical world to which data and services are mostlygenerated and consumed by local users In some othercases these services are consumed by global users via cloudcomputing paradigm In general sensor systems distributedservice computing elements are connected with each othervia intermediate connection elements (eg local servers) andglobal computing elements on the cloud in order to resolvethe challenges on scalability flexibility and domain specificon IoT However in which way these distributed systemscan be efficiently managed in the current infrastructures

specifically the current Internet which is not originallydesigned to support for the distributed computing with highflexibility in the IoT environments is an essential researchquestion

In this article we firstly introduce a novel multitierarchitecture for the IoT namely the 3-tier architecture andthen we propose a novel approach to task placement on fogcomputing made efficient for IoT service provision

In the 3-tier architecture IoT elements such as sen-sors mobile phones laptops vehicles base stations localservers network connection and management elements areconnected in a multitier distributed scheme consisting ofdifferent levels of intelligence devicegroup-of-devices tierregional tier and global tier as depicted in Figure 1 anddescribed as follows

(i) DeviceGroup-of-Device Tier includes IoT distributedservices (DSs) This tier manages distributed servicesgenerated by things such as wireless sensors vehiclesand mobile devices connected with each other viaad-hoc or P2P modes These services can be usefulfor local users such as mobile users surrounding IoTdevices in the DS sites Examples for these servicesinclude advertisements sent to mobile users whenthey pass a favorite restaurant at a department storea warning on overspeed sent to a driver and so on

(ii) Regional Tier consists of IoT services that are com-puted at a fog colony on the fog landscape Each fogcolony consists of a fog orchestration node servingas a service fog endpoint (SFE) and several fog cellsSFEs provide servicescontents that could not befound from DSs SFEs also serve as intermediateprocessing nodes used for data preprocessing or dataintegrations for example before being forwarded toDCs on the cloud for further computations Thisscheme not only mitigates communication and com-putation costs but also helps to reduce latency oflocal-based services for local users In addition itenables us to provide services which are best fit withthe local context For instance in a smart IoT-basedheart disease monitoring system [31] the systemcollects patientsrsquo ECG and heart beat signals (viawearable devices) to detect abnormality (eg heartattacks) and provide healthcare services The deviceitself can detect certain abnormalities based on somethresholds on ECG or heart beat signals Howevermore sophisticated detections such as those basedonmachine learning approaches using historical datacould not be conducted at IoT devices because of theircomputation and storage limitations The proposedscheme can introduce appropriate regional services atsuitable clinics in terms of specialty and capacity ofanalyzing patientsrsquo data (context about service types)which are close to userspatients (context about loca-tion) Regional services at the recommended clinicanalyze patientsrsquo ECG and heart beat signals to advicefor on-site treatments and prepare necessary equip-ment as well as medical practitioners for registeringpatients when they are hospitalized at the clinic


IoT

Distrib

uted

serv

ice

Cloud Gateway(CG)

Cloud Gateway

Cloud s

ervic

es

Fog s

ervic

es

(CG)

Fog control

Wired client

DS1DS2

DSG

(DSG)DS Gateway

Wireless client

Fog cell Fog cellnode (FG) Fog control

Fog colony

Fog colony

Fog colony

node (FG)

IoT devices (things)

Adndashhoc wireless link

Infrastructured wireless link

Distributed services (DS)

Services edge endpoint (SEE)

Services cloud endpoint (SCE)

Wired link Cloud and edge network controllerWireless access point Base station

Figure 1 A multitier architecture for the Internet of Things

(iii) Global Tier provides global IoT services or cloudserviceswhich are computedintegrated at centralizedDCs or service cloud endpoints (SCEs) SCEs collectdata from multiple SFEs or even from multiple DSsand provide global services to global users Theseglobal services are adequate with common context toa specific application For example in a healthcaresystem in accordance with flu symptoms such ashigh fever headache nausea etc reported by auser besides introducing appropriate clinics nearby(by SFEs) as mentioned before this data is alsosent to a preventive healthcare center for furtheranalysis If this is a transmissive flu the center willimmediately provide related information and instruc-tions to the community to prevent the flu spreadingThis is a global service computed on the cloud (atSCEs) using global data such as medical dictionarydescriptive data about epidemic and data supplied byusers

33 Applications and Services in the 3-Tier ArchitectureIn order to understand the usage of the proposed 3-tier

architecture we clarify concepts related to IoT applicationsand services as follows

(1) An IoT Application is a concrete application on anIoT environment that provides data information oractuating functions to the requesting clients from theInternet An application is a set of services (or tasks)described as follows

(2) A Service is considered as the smallest componentthat processes a concrete task A task can be classifiedin one of the following types sensing actuatingcomputing and storing The task type will limit thepossibility to deploy it on a particular nodedevice(eg a storing service cannot be conducted at alight-weight sensor without storage capacity) In thisarticle the terms service and task are used inter-changeably

(3) Service Provider is any device in the 3-tier archi-tecture that provides the execution of a task upon acorresponding request from a client For example IoTdevices (Things) are service providers for sensing oractuating services whereas providers for computing


services can be IoT devices fog devices and DCs onthe cloud and providers for storing services could befog devices and DCs on the cloud

(4) Client is a user application that issues applicationrequestsWe assume that the code for the available IoT applica-tions and services is already loaded to the correspond-ing devices (providers) in the 3-tier architecture Thearchitecture is not aware of computation details doneby applications or services It just knows what typeof providers needed to satisfy client requests (definedby sensing actuation and context properties) theoverlay topology of the providers and the resourcesrequired by each service with the constraint of ser-vicersquos response time Assuming that applications andservices are predefined and registered to SCEs or SFEswhich are front-end points for clients to request par-ticular applications The procedure generated whena client c requests an application a is described asfollows

(i) c asks its associated SCE (or even an SFE on itsclosest fog instance)

(ii) The involved SCE or SFE will identify the tasks(services) associated with the requested applica-tion and recognize corresponding providers byrunning the task placement method to optimizethe utilization of virtualized resources in the fog

(iii) The involved providers (ie devices wheretasks are deployed) execute the correspond-ing tasks and provide the results (processeddatainformation informing of the completionof an actuatingstoring task) to the servicefront-end (ie SCE or SFE) for integration andthen return the integrated results to the client c

4 Task Placement on the Fog Landscape

An inherent issue in fog computing is how to optimize theutilization of virtualized resources on the fog landscape inorder to not only mitigate the response time of requestedapplications but also reduce energy consumption and otheroperation costs This section proposes a novel method formaximizing such available resources in accordance with thecurrent context when deploying tasks in the proposed 3-tierarchitecture

41 Problem Definition and System Notations Given a setof applications 1198601 1198602 119860119898 each of which is constrainedwith a deadline 119863119860119896 suppose that each application is com-posed of independent tasks (ie tasks can be executedsimultaneously) (In IoT the degree of dependencies betweentasks could be complicated we defer those issues to the futurework This work focuses on devising a 3-tier fog computingarchitecture combining with context information for taskplacement on the fog landscape) 119860119896 = 1205911 1205912 120591119899 Let119869 = ⋃119898119894=1 119860119896 = 1205911 1205912 120591119873 be the set of tasks resultingfrom the decomposition of all applications that need to be

deployed on the 3-tier network This work aims at deployingthe tasks mentioned above on the fog landscape and the cloudbased on the current context

As presented in Section 31 the four main contextsnamely location network condition including network topol-ogy nodesrsquo resource availability and communication qualityservice type and QoS (in terms of expected response time)are taken into account in the proposed taskservice placementsolution In addition the task placement approach mustsatisfy the two criteria as follows

C1 (hard criteria) No application misses its deadline asdescribed in equation (1) where 119877119860119896 is the response timeof 119860119896 Here the context of expected response time andestimated execution time of tasks are taken into account

119877119860119896 le 119863119860119896 forall119860119896 (1)

C2 (softoptimal criteria) The number of tasks deployedon the fog landscape is maximized

In order to properly form and solve the optimized serviceplacement problem we need to devise estimation metricsfor the fog landscape wrt the network architecture proposedin Section 3 We describe the functional components theirresource capability communication delays and energy con-sumption in the fog computing paradigm Table 1 shows thenotations and descriptions of terms used for task placementmodeling in this paper

42 Task Placement Modeling This subsection proposes apractical task placement model on the fog landscape tomaximize the utilization of already available virtualizedresources at the network edges reducing latency and energyconsumption It is worth to be noted that fog colony is thebasic entity of fog landscape each of which consists of a setof computational devices denoted as fog cells or fog nodes119891 Each fog colony is managed by a fog orchestration node119865 which is a fog cell with more powerful and extendedfunctionality for managing resources and controlling the taskplacement and execution Upon receiving application requestsfrom clients the corresponding fog orchestration node 119865 isresponsible for generating and deploying tasks over the sys-tem in accordance with two criteria (C1 and C2) mentionedin Section 41 Given a task 120591119894 node 119865 will determine to placeit on one of the four places

(i) On itself (ie on F)(ii) On a fog cell on the colony managed by F that is any119891 isin 119877119890119904(119865) where 119877119890119904(119865) denotes a set of fog cells in 119865rsquos

colony that comply with service type required by 120591119894(iii) On its neighbor colony controlled by the orchestra-

tion node N (the details of task management and executionare delegated to N)

(iv) On the cloud denoted as RIt is worth to be noted that the orchestration node F

provides context information about network capacity (CPURAM communication quality and computation type) of eachfog cell in its colony and the context about its neighborcolonyrsquos capacity at the placement time

Let 119909119891120591119894 119909119865120591119894 119909119873120591119894 119909119877120591119894 isin 0 1 be binary variables tellingwhether the task 120591119894 is deployed on a fog node 119891 ( 119909119891120591119894 = 1)


Table 1 Notation and description of terms in the proposed task placement model

Notation Parameter Notation Description

Fog landscape

DS Distributed servicesF Fog orchestration node119891 a Fog cell (node)119891119896119894 Fog cell 119894th belongs to Fog colony 119896 controlled by the fog orchestration node F119896119873119896 The set of fog neighbors of F119896119901 Node p isin 119865119889119891 Link delay between a fog cell 119891 and its colonyrsquos orchestration node 119865119889119873 Link delay between a fog orchestration node 119865 and its neighbor119873119889119877 Link delay between a fog orchestration node 119865 and the cloud119875119875119898119886119909 Maximum power consumption of node 119901 in the fog landscape119875119901119894119889119897119890

Power consumption of node 119901 when it is idle

Cloud 119875119877119894119889119897119890 Power consumption of a node on the cloud when it is idle119908 Power consumption per instruction when executing tasks on the cloud

Application

A Set of applications to be executedA119896 The application 119896120591119894 The task 119894J The set of all tasks that need to be executed119877119860119896 Response time of the application 119860119896119863119860119896 Deadline of the application 119860119896119908120591119894 Deployment time of the task 120591119894119898120591119894 Execution time (makespan) of the task 120591119894119889120591119894 The communication time of the task 120591119894119886119894 The size (MIPS) of the task 120591119894119904119894 Memory required by the task 120591119894119863119894 The total amount of data exchanged when running the task 120591119894

on the fog orchestration node 119865 (119909119865120591119894 = 1) on the neighborcolony (119909119873120591119894 = 1) or on the cloud (119909119877120591119894 = 1) Since a task isdeployed only once the constraint in (2) is held

119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)

Since our purposedmethod is tomaximize the number oftasks assigned on the fog landscape with a given fog colonyorchestrated by F the objective function is formed in (3)

max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)

where 0 le 120572 120573 120574 le 1 are coefficients defining the priorityof task deployment on different types of computationalentities (fog cell 119891 fog orchestration node 119865 neighbor colonyN or on the cloud R respectively) This prioritizing helps tomitigate the computation time of the solverThese parameterscould be determined by examining historical data or can beheuristically selected based on an intuition that a task shouldbe tried at a fog cell or at the fog orchestration node beforebeing propagated to the neighbor colony and propagatingto the cloud is the last choice In this work we set 120572 =120573 = 1 120574 = 05 for evaluation without losing the generalityof the proposed approach while presenting the utilizationof location context (ie resources close to IoT data sources

are utilized first) In addition Res(F) describes context aboutnetwork condition (topology resource availability at eachnode etc) which is periodically updated at the beginning ofa task placement turn

Resolving the objective function in equation (3) providesan optimal placement plan that maximizes the number oftasks deployed on the fog landscape (ie near to data sourcesand better utilize the available virtualized resources) Thisplan satisfies the QoS constraint presented in equation (1)where every application is completed before a predefineddeadline 119863119860119896 under the available virtualized resources onthe fog landscape This means that for a task 120591119894 which isplanned to be deployed on anode p (fog cell fog orchestrationnode) pmust satisfy resources required by 120591119894 and all the taskscomposing the application 119860119896 must be completed beforethe applicationrsquos deadline to satisfy the global constraint inequation (1)

Therefore the hard constraint in this problem solvingis that available resources in the deployment node such ascomputation power (CPU) and storage (memory) capacitymust be adequate to process the requested tasks in time (iethe application consisting of tasks will be completed before itsdeadline) In addition the priority to assign a task locally onthe considering fog colony is significantly higher than that ofassigning such a task to a neighbor colony or to the cloudThiscan be seen as a soft constraint to maximize the utilization


of fog devices revealing the reduction of communicationlatency energy consumption and operational cost

43 Response Time Estimation As discussed before the taskplacement plan provided by the proposed model must satisfythe hard constraint on the application response time (ie119877119860119896 le 119863119860119896 presented in equation (1)) The difficulty hereis that how to appropriately model or estimate the responsetime of an application which consists of multiple tasks beingdeployed at different locations This subsection addressesthis issue by thoroughly estimating the time expended forapplication execution wrt the related resource constraintssuch as CPU power and memory capacity of available fogdevices

431 Estimating Response Time of a Task and an ApplicationAccomplishing a task 120591119894 requires four steps task submis-sion deployment execution and result return Therefore theresponse time 119903120591119894 of such a task is calculated as follows

119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)

where(i) 119908120591119894 is the deployment time in which data and compute

resources needed by the task are prepared(ii)119898120591119894 is the execution time (or makespan time) in which

the task actually utilizes resources on the deploying node forexecution

(iii) 119889120591119894 is the communication time consisting of (a) tasksubmission time which is the time it takes to move necessaryinformation from the fog orchestration node to the nodewhere the task will be deployed and (b) result return timewhich is the time it takes to return the result to the fogorchestration node and release unused resources

We assume that resources on the cloud are unlimitedhence when a task 120591119894 is submitted to the cloud it is executedand finished immediately Therefore if a task is assignedto the cloud its response time is composed of only thecommunication time (ie 119903120591119894 = 119889120591119894)

Estimating the response time of a task running ona fog cell in contrast strongly depends on how the fogorchestration node distributes tasks to other nodes and themechanisms each node uses to schedule task deployment andexecution We briefly describe those as follows

Each fog node p runs tasks in multiple turns namely 12 M At the beginning of a turn the node loads all tasksassigned to it and deploys all of them Once a task is deployedsuccessfully the node uses a part of its computation powerto execute the task Right after the task has been finishedthe result will then be transferred back to its correspondingfog control node When every task has been done the nodereleases all resources and marks the current turn as ldquofinishrdquoAfter that the node moves to the next turn loads new tasksand executes them if there is any assignment

It should be noted that a task must be completed withina single turn It cannot be propagated across multiple turnsIn addition a node only deploys tasks at the beginning of aturn Therefore if a task is assigned to a node this node doesnot start the task immediately but waits for the current turn

to finish (tasks are put on the nodersquos waiting queue) Moreformally a node deploys new tasks if and only if

(i) there exists at least one task in its waiting queue and(ii) all tasks in the previous turn have been finished and

the node is ready for releasing resources for deploying newtasks

Since a node loads all tasks assigned to it in eachturn and tasks are executed concurrently and all fog nodesare controlled (ie they can be synchronized) by the fogorchestration node the response time of an application 119903119860119896can be estimated as follows

119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)

Given this mechanism the next subsection presentsin detail the estimation of each time component namely119908120591119894 119898120591119894 119889120591119894 based on the available CPU memory and com-munication resources of the destination node (where thetask will be deployed on) and the corresponding resourcerequirement from the task

432 Estimating Deployment Time (119908120591119894) In this work weassume that if a task is deployed on the cloud R it canbe deployed immediately as the resource on the cloud isalways available on demand Therefore the deployment 119908120591119894of the task 120591119894 is accountable when 120591119894 is deployed on the foglandscape This time is calculated in equation (6)

119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)

where(i) 119879119873 is the time the task spends on the waiting queue of

the neighbor fog colony 119873 if it is assigned to the neighborcolony (ie 119909119873120591119894 = 1)119879119865 is the time the task spends on the waiting queue ofthe fog orchestration node 119865 if it is assigned to the fogorchestration node (ie 119909119865120591119894 = 1)

(ii) 119879119891 is the time the task spends on the waiting queue ofa fog node 119891 if it is assigned to this node (ie 119909119891120591119894 = 1)

In order to estimate 119879119873 the fog orchestration node 119865examines the historical data collected fromN during previousexecution turns Supposing that at node N m turns havepassed then 119879119873 is calculated in equation (7)

119879119873 = 119879119898 minus 119879119901119898 (7)

where(i) 119879119901119898 is the amount of time passed after the turn 119898 had

finished (ie the fog node in N has run its current turn for119879119901119898 time unit (s) see Figure 2 for more details)(ii) 119879119898 is the average duration (ie the total time a node

spends on a turn for deploying executing tasks and releasingresources) of a turn calculated from the previousm turns andis calculated by the following equation

119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)

where119879119898 is the waiting length (duration) of the turnm 120582reflects the sensitivity of the approximation If 120582 approaches 1


TimeCurrentcolony F

Neighborcolony N

t=0

m-1 turns have passed

Ｎ0 ４Ｇ４ＧＪ

The mtℎ turnneighbor colony

４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1

Task Ｃ is sent to the

Figure 2 Estimation of the taskrsquos waiting time at the neighbor fog colony N 119879119873

the approximation tends to rely much on the recent durationof the last turn On the other hand if 120582 approaches 0 theapproximation tends to rely on the previous approximationon historical data

Obviously 119879119865 and 119879119891 can also be calculated using thismethod However tasks are given beforehand expected tobe executed in a single turn and there is no new task orapplication generated during the execution it is reasonable toset 119879119865 = 119879119891 = 0 Consequently equation (6) can be rewrittenas in

119908120591119894 = 119879119873119909119873120591119894 (9)

433 Estimating Execution Time (119898120591119894) Execution time ormakespan time119898120591119894 is the time required to execute the task 120591119894given the CPU power of the node where the task is deployedThis time is calculated in the following equation

119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)

where119898119865120591119894 119898119891120591119894 119898119873120591119894 and119898119877120591119894 are the execution times if the task 120591119894is deployed at the fog orchestration node F fog node f underthe control of F (eg 119891 isin 119877119890119904(119865)) the neighbor fog colonyN and the cloud R respectively These times are calculated asfollows

Let p be the selected nodewhere the task will be deployedthe execution time 119898120591119894 is calculated in accordance withcompute capacity (ie CPU power) of p denoted as 119862119901which is the maximum number of (million) instructionsper second (or MIPS) that this node can spend on runningtasks (other compute capacity which has to be used for otheroperations such as transferring data is set aside and will notbe considered in here) It should be noted that if p is a nodeon the considering colony (ie F119891) the 119862119901 is available to theconsidering orchestration node F If p represents the cloud(ie R) in this case the task 120591119894 must be deployed on thecloud due to the time constraint the cloud-based computeresource is required adequately to complete the task on timeTherefore the orchestration node F is not responsible forestimating this resource As a result the execution time inequation (10) can be rewritten as in the following equation

119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)

Besides the compute capacity 119862119901 execution time of atask is also affected by the task size denoted as |120591119894| whichis measured by the number of (million) instructions to beexecuted (denoted as MI) This size is directly calculated bythe fog orchestration node F and can be used as an explicitinput for computation resource requirement Our target is toreduce the execution time of the task asmuch as possible thusthe computation capacity of the node must be fully used Todo so assume that at every turn m the node p has a set oftasks to execute 119869119901119898 = 1205911 1205912 120591119899 | 119909119901120591119894 = 1 We assignthe computation capacity 119862119901 proportionally to each task inaccordance with tasksrsquo sizes More formally the amount ofcomputation capacity assigned to task 120591119894 is presented in thefollowing equation

119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)

Consequently the execution time of task 120591119894 is calculatedin the following equation

119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)

Since compute resource is proportionally divided to tasksbased on their sizes all tasks in the same turn (deployed onthe same node) will have the same execution time regardlessof their sizes From (12) and (13) the execution time of a taskcan be rewritten in

forall120591119894 isin 119869119901119898 119898119901120591119894 = sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119901 (14)

Since a fog colony executes all tasks assigned to it withina single turn we can clarify the execution time of a task whenit is deployed at the orchestration fog node F at a regular fognode f and when it is propagated to the neighbor colonyN asfollows

(i) Estimating the Execution Time 119898119865120591119894 and 119898119891120591119894 When 120591119894 IsDeployed on the Considering Colony According to equation


(14)119898119865120591119894 and119898119891120591119894 can be clarified as in equations (15) and (16)respectively

119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)

forall119891 isin 119877119890119904 (119865) 119898119891120591119894 = sum120591119895isin119869 119909119891120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119891 (16)

(ii) Estimating the Execution Time 119898119873120591119894 When the Task 120591119894 IsDeployed on the Neighbor Colony N Obviously 119898119873120591119894 cannotbe directly calculated as the same way as the calculation for119898119865120591119894 and 119898119891120591119894 mentioned above since the orchestration node Fdoes not have information about other tasks that are currentlyrunning on the neighbor colony N In order to overcome thisdifficulty we proposed to estimate119898119873120591119894 throughhistorical datafrom previous executions on N Suppose that there were ktasks executed on N previously the119898119873120591119894 can be estimated in

119898119873120591119894 = 119898119873119896

(17)

where119898119873119896is the average execution time of tasks from the 1st

task to the 119896th task and is defined in

119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)

where(i)119898119873119896 is the execution time of the 119896th taskwhich has been

done at the colony N(ii) 119898119873

119896minus1is the average execution time of tasks from the

1st task to the 119896th task(iii) 120583 is a predefined parameter which reflects the weight

of the execution time of recent moving tasks

434 Estimating Communication Time (119889120591119894) In order toestimate the communication time we need to model thenetworked resources in our proposed 3-tier architecture Wedenote the system as an undirected graph G=(VE) where119881 is the set of vertices representing the physical elementsthat consist of the cloud (R) fog orchestration node (F) ofeach fog colony and fog cells (119891) E is the set of physicalconnections between two vertices in the graph Formally theset of connections (links) in the network topology can berepresented in

119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896

= 119890119891119894 =≺ 119887 119889119901119903119900119901 ≻ |119894 = 1 |119903119890119904(119865)119896| is the set ofphysical connections between the orchestration node 119865119896 andthe fog cells in the colony k |119903119890119904(119865)119896| is the number of fogcells in the considered colony k119864119873119896 = 119890119873119894 =≺ 119887 119889119901119903119900119901 ≻ |119894 = 1 |119873119896| is the set ofphysical connections between the orchestration node 119865119896 of

the colony k and its neighbors |119873119896| is the number of fogneighbors of the considered colony k119864119877119896 = 119890119873 =≺ 119887 119889119901119903119900119901 ≻ is the physical connectionbetween the orchestration node 119865119896 of the colony k and thecloud

b is the maximum throughput of the considered linkwhen data is transferred and 119889119901119903119900119901 is the propagation delayof the considered physical link

As a result when the task 120591119894 is distributed from theorchestration node 119865119896 to an appropriate node (ie F f N orR) the communication time is calculated in

119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)

where119889119891120591119894 119889119873120591119894 119889119877120591119894 are one-way latencies when the task 120591119894 isdeployed on f N or R respectively It should be noted thatthe communication time is the double of this one-way latencyand the latency when the task is deployed on F (namely 119889119865120591119894)is 0 hence it does not appear in equation (20)

For any p representing any type (f N or R) 119889119901120591119894 iscalculated in

119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)

where119889119901120591119894119905119903119886119899119904 119889119901120591119894119901119903119900119901 119889119901120591119894119902119906119890119906119890 are the communication times oftask 120591119894 caused by the transportation propagation and queu-ing times respectively This work assumes that the queuingtime is 0119863120591119894 is the amount of data (in Byte) of the task 120591119894 that needto be transferred on the considered link

It should be noted that reaching this stage all thedeployment time makespan time and communication time(119908120591119894 119898120591119894 119889120591119894) of the task 120591119894 have been thoroughly estimatedThey can be applied to equation (5) in Section 431 to estimatethe response time of an application 119903119860119896435 Memory Constraint In order to deploy a task on anappropriate node p the memory constraint must be satisfiedas shown in

sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)

where119878120591119894 is the memory required to executing the task 120591119894(Bytes) It is assumed that this value can be estimated by thecorresponding orchestration node F119878119901 is the memory capacity of node p (Bytes) It should benoted that the corresponding orchestration node F can exam-ine 119878119891 of any fog cell f belonging to its colony Meanwhile theorchestration node of the neighbor colony N must notify to Fits available memory 119878119873Thememory on the cloud 119878119877 alwayssatisfies the required memory of the deployed tasks


Table 2 Configuration of the general network topology

Node name Delay (s) CPU capacity (MIPS) Ram capacity (MB) Power consumption (J max and idle)1198910 2 250 16 200 1001198911 2 250 16 200 1001198912 2 250 16 200 1001198913 2 250 16 200 100F 0 350 1e3 600 300N 10 350 1e3 600 300R 50 1e3 8e3 1e3 300

Table 3 Summary of simulation scenarios

Number of apps No tasksapp Network topology1-6 1-8 4-7 nodes (1 F 1 N 1R and 1 - 4 f)

Deadline (s)ltmin mean maxgtTaskCPU(MI)

Nodef CPU(MIPS)

Delay (s) Power consumption(J) ltidle maxgt

lt10 19 29gt lt100 252 399gt lt205 389 581gt lt1 6 10gt lt200 600gt5 Evaluation

The main purpose of the evaluation is to verify the effec-tiveness of the proposed approach in terms of reducingof latency energy consumption and network load whileincreasing the utilization of virtualized resources available onthe fog landscape thus mitigating the operational costs incomparison with the conventional cloud computing modelWe have conducted various experiments using simulationsincluding those simulating task distribution problems in realworld applications that we are building for a smart city systemsuch as the ITS in Ho Chi Minh City

51 Experiment Environment In order to evaluate the opti-mized task distribution model presented in Section 4 weneed to describe several experimental variables as follows

(i) Network topologies and resource description Weuse iFogsim [32] to generate various network topologiesassociated with their devicesrsquo resource description such as fogcolonies the orchestration node of a specific colony fog cellsin a fog colony associated with their CPUmemory capacitiesand the network bandwidth as well as the propagation delayson each link between two physical nodes in the consideredtopology

(ii)Application composition and resource requirementby tasks In order to describe applications and tasks wehave analyzed several real world applications such as the ITSthat we are building for Ho Chi Minh City We analyzedapplication composition (which tasks are composed in aspecific application) and the resource required by each task(the memory and CPU capacities and the size of eachtask) as well as the reasonable deadline required by eachapplication in the ITS applications Concrete examples forthese descriptions are presented in the next subsection thatdescribes different application scenarios

(iii) Optimize task placement on the fog landscape Inorder to solve the optimization problem of task placement

on the fog landscape proposed in Section 4 we implementeda program for optimization problem solving leveraging theIMB CPLEX solver [33] The result is an optimal placementplan which is used to (i) analyze the network performanceand (ii) redeploy on the considering network topology usingiFogsim [32] to verify the network performances

52 Experimental Results As discussed energy consumptionreduction fog device utilization and cost saving as functionsof application complexities (ie number of applicationsnumber of tasks in each application and resources requiredby each task) and network topologies (number of fog nodesand the capacity of each node) have been thoroughly evalu-ated through experiments on general scenarios and real worldapplications

521 Evaluation on General Scenarios In this section weevaluate how the proposed approach works to provide taskplacement plans on different situations in terms of networktopologies and applications (including tasks) to be processedon each network topologies We have simulated 28 differentnetwork topologies (configurations) each of which has astructure as follows one orchestration node F several fogcells (119891119894) controlled by F one neighbor colony N and adata center on the cloud Table 2 depicts an example ofa configuration that consists of 1 colony with 4 fog cellsmanaged by an orchestration node F connecting with aneighbor colony N and the cloud R

In our simulations the requirements of network topolo-gies are randomly selected with reasonable constraints Inorder to ensure the diversity of the simulations variousparameters have been varied as summarized in Table 3Each configuration is deemed to deploy several applicationsvarying from 1 to 6 each of which consists of 1 to 8 tasksEach application and task are varied by the required deadline(min average and max values are shown in the table) andthe required CPU (to which the response time of each


0

10

20

0 10 20minus10Configuration Index

ApplicationsTasksNodes

(a) The number of applications tasks and nodes

minus10minus5

05

101520253035

Tim

e (se

cs)

150 5 10 20 25minus5minus10Configuration Index

DeadlineNode Delay

(b) Average application deadline and node delay

50100150200250300350400450

MI


Application CPUNode CPU

(c) Average application CPU and node CPU

Figure 3 Simulation configurations

Table 4 Applications associated with tasks deployed on the 3-tier architecture

App name Task 120591119894 119863119860119896 (s) task size (|120591119894|MI)1198601 0 5 6 250 350 200 100 250 3001198602 6 10 7 260270280 2901001198603 11 15 8 200 250 200 250 3001198604 16 21 9 100 100 100 100 100 2001198605 22 26 95 10 10 10 10 101198606 27 28 85 100 120

task can be inferred in accordance with network topologiesand deployment plans) respectively Network topologies arevaried by the number of fog cells (f) in the consideringcolony which is ranged from 1 to 4 Fog cell is characterizedby three parameters namely the CPU capacity delay andenergy consumption as shown in the table

We have conducted 28 different scenarios and collectedinformation of 65 applications in total with variants men-tioned above The above summary of scenarios is alsoillustrated in Figure 3The figures show application deadlinesnodersquos CPU taskrsquos CPU and number of tasks applicationsand nodes with regard to network configurations Figure 3(a)shows the number of applications number of tasks need tobe deployed and the number of fog nodes in each networktopology in the 28 scenarios In addition as a general rulethe available resources of a topology have to be greater thanthose required by planned applications While the averagenode delay is less than the average application deadline inFigure 3(b) to allocate time slots for executing applicationsthe application CPU is intersected by node CPU becausein the worst case tasks could be deployed to the cloud(see Figure 3(c)) An example of application composition isillustrated in Table 4

As presented each network configuration consists of 4to 7 nodes to deploy 1 to 6 applications each of which is

composed of 1 to 8 tasks As a result the maximum numberof variables in each topology is max(119899119906119898119887119890119903 119900119891 119886119901119901119904 times119899119906119898119887119890119903 119900119891 119905119886119904119896119904 times 119899119906119898119887119890119903 119900119891 119899119900119889119890119904) = 6 times 8 times 7 = 336 itensures that the CPLEX resolver is able to produce the resultsOther apparent constraints include 119862119865 gt 119862119891 119889119877 gt 119889119873 gt119889119891 119875119865119898119886119909 gt 119875119891119898119886119909 Obviously in order to satisfy these con-straints accompaniedwith the objective function presented inequation (3) Section 42 each simulation takes into accountcontext about location network condition service type andexpected response time collected at the starting time of eachplacement turn

We have solved the optimization problem of task place-ment on fog landscape and applied the task distribution planon the given network topology to evaluate the effectivenessof the proposed approach in terms of satisfying deadlinerequirement energy consumption reduction fog utilizationand cost saving compared to the cloud based approach Theresults are presented and analyzed as follows

Deadline Satisfaction As we have analyzed one of theadvantages of the proposed 3-tier architecture is its capabilityof utilizing the locally available resources on the fog landscapefor computing tasks hence it can reduce the communicationtimes (compared to the cloud-based approach) providingmore chances to satisfy the required application deadlines In


Tim

e (s)

DeadlineFog_ResponseCloud_Response

Application index706050403020100

5

10

15

20

25

0

Figure 4 Response times in the proposed 3-tier architecture compared with the conventional cloud approach extracted from 65 applications

Fog CellFog OrchestrationNeighborCloud

100908070605040302010

0Port

ion

of T

ask

Plac

emen

t

2827262322212018 191716 1514 1312 11109 8 7 6 543 21Configuration Index

24 25

Figure 5 Utilization of the fog landscape

these evaluations the response time r119860119896 of each applicationis estimated using the model presented in equation (5) whilethe response time of each task 119903120591119894 is estimated using equation(4) Section 431 For simplicity without losing the generalityof the response time estimating model the deployment timeat each fog node is ignored (119908120591119894 = 0) while the execution time(119898120591119894) and the communication time (119889120591119894) are calculated usingequations (10) and (20) respectively using data providedin Tables 2 and 4 After estimation r119860119896 is compared withthe corresponding deadline 119863119860119896 provided in Table 4 Thecomparison results are presented in Figure 4

As shown around 57 of the applications miss thedeadline if they are processed on the cloud Meanwhileno application in the proposed 3-tier approach misses thedeadline It should be noted that there are some cases theresponse times in the proposed approach are larger thanthe cloud-based ones (both of them satisfy the deadlines)These situations occur when applications consisting of heavytasks (ie tasks require a large number of processing instruc-tions) are deployed on fog nodes with low computationalpower

Fog Landscape Utilization Figure 5 shows an effective utiliza-tion of the virtual resources available on the fog landscapein our proposed method Among 28 configurations (con-sisting of 65 applications) there is only one configurationthat involves the cloud revealing that more than 95 ofconfigurations the applications are fully processed on thefog landscape (without using any cloud-based resource) An

interesting point here is that applications are firstly attemptedon the fog orchestration node then on fog cells then onthe neighbor colony and finally on the cloud Obviously thecommunication time needed for applications to be deployedon the fog orchestration node is 0 and the computationpower of this node is commonly much more powerfulthan those of fog cells in many cases tasks are referredto be and successfully be deployed on this node It is alsoworth to be noticed that in the cases when cloud resourcesare involved only 15 of such resources are required theremained resources come from the fog landscape

Energy Consumption ReductionWe also evaluated the energysaving by the proposed architecture and the results aredepicted in Figure 6 In most of the cases the proposedarchitecture saves more than 80 of the energy comparedto that of the cloud-based approach There are only 2 casesamong 28 configurations (ie 7) the energy consumptionin our proposed method is comparable or a little bit higherthan that of the cloud-basedmethodThis is because themainobjective of our approach is tomaximize the task deploymenton the fog landscape when the estimated response timestill satisfies the required deadline although the computationtime is higher than the case that tasks are processed onthe cloud However as mentioned these situations are rare(only 7) and in fact (in most of the cases) the proposed 3-tier architecture provides benefits in both the response time(computation and communication times) and the energysaving


2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25

Figure 6 Energy consumption in the proposed scheme compared with the cloud-based approach

Proposed approachCloud

Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

Figure 7 Cost saving in the proposed method

Cost Saving Figure 7 reveals the effectiveness of the proposedmethod in terms of cost saving As analyzed before in mostof configurations applications are fully deployed on the foglandscape (see Figure 5) no renting cost is required for cloudservices in these cases Cost incurs only in one configuration(configuration 15)when someof cloud resources are required

522 Verification under the Real World ITS Application Thecommunications infrastructure in HCMC is not designedfor a specific application such as the ITS Meanwhile wecould not redesign the network infrastructure physicallyInstead we applied the proposed model to realize the fogcomputing paradigm solving the problem of task placementthus improving the performance of the ITS that we arebuilding forHoChiMinh City In this workwe have designedthe system with the following principles

(i) Decentralization The whole system is geographicallypartitioned into small autonomy regions each of which isconsidered a fog colony operating independently with a min-imized interference from a ldquocentral light-weight controllerrdquo(normally a high-end server or a data center) This principlemitigates global communications to lessen the impact ofpoor connections Moreover the autonomy regions help tostrengthen the systemrsquos availability and fault tolerance

(ii) Localization Computing resources are distributedacross local regions deployed close to data sources hence thedata can be processed locally without invoking many partsof the system This principle guarantees instant responseseven in the context of low and unstable connections Thislocalization also allows us to provide qualified services at

low cost by efficiently utilizing computation resources alreadyavailable at the network edges Besides helping to save thehigh cost of renting computation and storage resources fromthe cloud these edge-based devices commonly consume lessenergy compared to that of data centers on the cloud whenprocessing the same tasks

We apply principles mentioned above in our ITS systemin accordance with the proposed 3-tier architecture with 3layers namely cloud fog and IoT devices We partition thewhole city into smaller areas and deploy a fog colony on eacharea (formed by a group of multiple fog nodes) to handledata and services related to the considered areas such as toestimate the average velocity of a traffic flow on a specificroad segment on the considered area The organization ofa fog colony is followed with the designs on the proposed3-tier architecture presented in Section 4 Each fog colonymaintains connection to one (ormore) neighbor colony If thefog colony is overloaded it moves some tasks to its neighborandor to the cloud

We designed a testbed for emulating our model withthe configuration described in Table 5 Note that we use 2physical machines with Intel Core i7-4790 360GHz CPU4GB memory and running on Ubuntu 1604 (64-bit) eachmachine emulates one fog colony Concretely we deploy 1orchestration node and 3 other fog nodes each of whichis emulated by a single virtual machine to describe thedetailed configuration of a specific colonyThe other machineis used to simulate the neighbor colony of the above colonyThe fog colonies connect to a data center (cloud) at HoChi Minh City University of Technologyrsquos high performancecomputing center (30 kmapart from the fog nodesmentioned


Table 5 Configuration of the network topology in the ITS testbed

Node name Delay (s) CPU capacity (MIPS) Ram capacity (MB) Power consumption (W max and idle)F 0 100 2e3 50 101198910 002 3 16 10 21198911 002 3 16 10 21198912 002 3 16 10 2N 05 100 2e3 50 10R 2 684e3 128e3 120 50

Table 6 ITSrsquos applications and associated tasks

App Task Deployment time (119901120591119894 ms) Task size (|120591119894| MI) Memory consumption (119878120591119894 MB) Deadline (s)Analyzing traffic flow (1198861) 1205911 asymp 0 002 016 1Traffic light control (1198862) 1205912 8 6 3 10

Table 7 Effectiveness of the proposed 3-tier scheme compared with the cloud-based approach in the real-world ITS applications

Real-world case Deadline missing rate () Energy consumption (J) Cost ($)No of a1 No of a2 3-tier Cloud 3-tier Cloud 3-tier Cloud5 1 0 8333 4525 2074 0 56e-610 2 0 8333 456 4148 0 113e-615 3 0 8333 45933 6222 0 169e-650 10 0 50 4305 2074 0 563e-680 16 0 50 4488 33184 0 900e-6

above) The data center is deployed with 2 CPU Intel XeonE5-2680v3 215GHz x 24 CPU and 128GB memory Theconnection between fog nodes is emulated by Mininet andthe configuration of this topology is described as follows

In this work we select two representative applicationsamong many ITS applications for analysis as follows

(i)Analyzing traffic flow Given a set of GPS signal fromvehicles traveling on a road segment estimate the averagevelocity and the density of the considered traffic flow

(ii) Traffic light control Given a traffic light currentlyat the beginning of its color phase (that is the sequence ofthe green red and yellow lights) set the duration of eachlightrsquos color for the next phase appropriately with the trafficcondition

Table 6 shows parameters associated with each applica-tion mentioned above

As presented each application above is composed of asingle task However many of similar applications can runconcurrently on the same colony (ie each application isapplied for one road segment in the region covered by theconsidered colony)

We have solved the optimization problem of task place-ment on fog landscape to this real world application designThen we applied the task distribution plan on the givennetwork topology to evaluate energy consumption reductionfog utilization and cost saving of the proposed methodcompared to the cloud-based approach

As shown in Table 7 the proposed approach in the 3-tier architecture is significantly more effective compared tothe cloud computing counterpart in all of the three factors(deadline missing rate energy consumption and cost) The

deadline missing rate in the proposed method is 0 whileit is more than 50 in the cloud approach mainly becauseof communication latency As for the energy consumptionwhen more tasks are deployed on the cloud the energyconsumption is large as the cloud-based servers must be upwaiting for the arrival of tasks (which are delayed due toupward communication latencies) For example in the lastrow the energy consumptions in the proposed method andthe cloud approach are 4488 (J) and 33184 (J) respectivelywhich are significantly different The last column shows thecost for renting computing services on the cloud while thecost on our proposed approach is 0 as the virtual resourcesavailable on the network edges are utilized It should be notedthat the cloud service cost is calculated in accordancewith thecloud service renting model described in [34 35]

6 Discussion

This work directly focuses on the feasibility of the opti-mization on task provision on fog landscape to improve thecapacity of fog computing paradigm In order to reach thistarget we have thoroughly analyzed and modeled applica-tions tasks associated with their required resources andnetwork configurations with their resource capacity to clarifyconcrete constraints on the proposed optimization modelThe proposed approach is more effective and robust than theexisting approaches in terms of practical realization energyand cost reduction by means of maximizing the utilizationof fog computing paradigm However further improvementsshould be considered


(1) Orchestration node selection In the current designand prototype the orchestration node is statically decided inadvance based on their computation and storage capacitiesAs fog devices may die due to energy shortage a dynamic fogorchestration election model should be thoroughly investi-gated This model could be useful for IoT environment withmobile devices(2) Nontree based structure The 3-tier architecture iscomposed based on a tree-based structure which helps tosimplify the networkmanagement However this may dangerthe network as it is vulnerable to orchestration node failureAs discussed before when orchestration nodes can be electeddynamically and if this approach is extended thereby everynode can serve as an orchestration node if it satisfies somecriteria then the architecture in the fog landscape couldbecome ldquoflatrdquo In this sense the system is more tolerantwith node failures but it could be complicated for networkmanagement and for task distribution(3) Task distribution In this work task distribution ishandled by orchestration nodes The inherent limitation hereis that each orchestration node can obtain only local infor-mation about fog nodes in its colony and limited informationfrom its neighbor colonies rather than examining a globalview of the whole network hence global optimization is notachieved SDNOpenflow [36] based approaches can help toachieve global optimization by the capability of collectingglobal network statistics from the Controller There is apotential direction to apply SDN approach for dynamic taskprovision in the proposed 3-tier architecture(4) Task dependencies In this work tasks composingan application are assumed to be executed simultaneouslyto make the proposed 3-tier architecture combining withcontext-aware service placement viable before going furtherIt should be noted that however in the IoT applicationsthe degree of parallelism and dependencies between taskscould be complicated Therefore similar to the dynamic ofcontext update the dependence degrees between tasks couldalso dynamically change Context-aware service placementin large-scale IoT environments with multiple dependencedegrees between tasks is a challenge but potential researchdirection for our future work which can be developed fromthis paper

7 Conclusion

In this article we have proposed a novel approach totask placement on fog computing made efficient for IoTapplication provision where a systematical fog computingframework consisting of multiple intelligent tiers for theIoT has been introduced and a context-aware task provisionmechanism in the fog has been devised The proposedapproach optimally utilizes virtual resources available on thenetwork edges to improve the performance of IoT services interms of response time energy and cost reduction

The experimental results from both simulated data anddata summarized from service deployments in real-worldapplications namely the ITS in Ho Chi Minh City which weare building show the effectiveness of the proposed approach

in terms of maximizing the utilization of fog devices whilereducing latency energy consumption network load andoperational cost These results confirm the robustness of theproposed scheme revealing its capability to maximize the IoTpotential In the future we are planning to implement thismethod in real applications to support the process of realizinglarge-scaled IoT applications smart city ecosystems

Data Availability

The [simulated evaluation] data used to support the findingsof this study are included within the article

Conflicts of Interest

The authors declare that there are no conflicts of interestregarding the publication of this paper

Acknowledgments

This research is funded by Vietnam National Foundation forScience and Technology Development (NAFOSTED) undergrant number 10201-201628

References

[1] Y Nan W Li W Bao F C Delicato P F Pires and A YZomaya ldquoCost-effective processing for Delay-sensitive appli-cations in Cloud of Things systemsrdquo in Proceedings of the15th IEEE International Symposium on Network Computing andApplications NCA 2016 pp 162ndash169 Cambridge Mass USANovember 2016

[2] F Bonomi R Milito J Zhu and S Addepalli ldquoFog computingand its role in the internet of thingsrdquo in Proceedings of the 1stACMMobile Cloud Computing Workshop MCC 2012 pp 13ndash15Helsinki Finland August 2012

[3] A V Dastjerdi H Gupta R N Calheiros S K Ghoshand R Buyya Fog Computing Principles Architectures andApplications Internet of Things Principles and Paradigmschap 4 Morgan Kaufmann 2016

[4] S Sarkar S Chatterjee and S Misra ldquoAssessment of theSuitability of Fog Computing in the Context of Internet ofThingsrdquo IEEE Transactions on Cloud Computing vol 6 no 1pp 46ndash59 2015

[5] D Miorandi S Sicari F de Pellegrini and I Chlamtac ldquoInter-net of things vision applications and research challengesrdquo AdHoc Networks vol 10 no 7 pp 1497ndash1516 2012

[6] J Gubbi R Buyya S Marusic and M Palaniswami ldquoInternetof Things (IoT) a vision architectural elements and futuredirectionsrdquo Future Generation Computer Systems vol 29 no 7pp 1645ndash1660 2013

[7] M Bertier F Desprez G Fedak et al ldquoBeyond the cloudhow should next generation utility computing infrastructuresbe designedrdquo in Cloud Computing Computer Communicationsand Networks Z Mahmood Ed pp 325ndash345 Springer 2014

[8] L M Vaquero and L Rodero-Merino ldquoFinding your way inthe fog towards a comprehensive definition of fog computingrdquoACM SIGCOMM Computer Communication Review Archivevol 44 no 5 pp 27ndash32 2014


[9] M Aazam and E N Huh ldquoFog Computing Micro DatacenterBased Dynamic Resource Estimation and Pricing Model forIoTrdquo in Proceedings of the IEEE 29th International Conferenceon Advanced Information Networking and Applications (AINArsquo15) pp 687ndash694 IEEE Gwangiu South Korea March 2015

[10] S Yi Z Hao Z Qin and Q Li ldquoFog computing Platformand applicationsrdquo in Proceedings of the 3rd Workshop on HotTopics in Web Systems and Technologies HotWeb 2015 pp 73ndash78 Washington DC USA November 2015

[11] OpenFog Consortium 2018 httpswwwopenfogconsortiumorg

[12] OpenFog Consortium Architecture Working Group OpenFogReference Architecture for Fog Computing technical report [PhDthesis] 2017

[13] R S Montero E Rojas A A Carrillo and I M LlorenteldquoExtending the Cloud to the Network Edgerdquo The ComputerJournal vol 50 no 4 pp 91ndash95 2017

[14] C C Byers ldquoArchitectural Imperatives for Fog Computing UseCases Requirements and Architectural Techniques for Fog-Enabled IoT Networksrdquo IEEE Communications Magazine vol55 no 8 pp 14ndash20 2017

[15] P Hoenisch I Weber S Schulte L Zhu and A Fekete ldquoFour-fold Auto-Scaling on a Contemporary Deployment Platformusing Docker Containersrdquo in Proceedings of the 13th Interna-tional Conference on Service Oriented Computing (ICSOC 2015)vol 9435 of Lecture Notes in Computer Science pp 316ndash323Springer 2015

[16] P Leitner W Hummer B Satzger C Inzinger and S DustdarldquoCost-efficient and application SLA-aware client side requestscheduling in an infrastructure-as-a-service cloudrdquo in Proceed-ings of the 2012 IEEE 5th International Conference on CloudComputing CLOUD 2012 pp 213ndash220 USA June 2012

[17] H T Dinh C Lee D Niyato and PWang ldquoA survey of mobilecloud computing Architecture applications and approachesrdquoWireless Communications andMobile Computing vol 13 no 18pp 1587ndash1611 2013

[18] N Fernando S W Loke and W Rahayu ldquoMobile cloudcomputing a surveyrdquo Future Generation Computer Systems vol29 no 1 pp 84ndash106 2013

[19] Y-J Yu T-C Chiu A-C Pang M-F Chen and J Liu ldquoVirtualmachine placement for backhaul traffic minimization in fogradio access networksrdquo in Proceedings of the IEEE InternationalConference on Communications (ICC) pp 1ndash7 2017

[20] L Gu D Zeng S Guo A Barnawi and Y Xiang ldquoCost efficientresource management in fog computing supported medicalcyber-physical systemrdquo IEEE Transactions on Emerging Topicsin Computing vol 5 no 1 pp 108ndash119 2017

[21] H J Hong P H Tsai and C H Hsu ldquoDynamic moduledeployment in a fog computing platformrdquo in Proceedings ofthe 18th Asia-Pacific Network Operations and ManagementSymposium APNOMS 2016 pp 1ndash6 Japan October 2016

[22] J Xu B Palanisamy H Ludwig and Q Wang ldquoZenithUtility-Aware Resource Allocation for Edge Computingrdquo inProceedings of the 1st IEEE International Conference on EdgeComputing EDGE 2017 pp 47ndash54 USA June 2017

[23] V B Souza W Ramirez X Masip-Bruin E Marin-Tordera GRen andGTashakor ldquoHandling service allocation in combinedFog-cloud scenariosrdquo in Proceedings of the ICC 2016 - 2016 IEEEInternational Conference on Communications pp 1ndash5 KualaLumpur Malaysia May 2016

[24] O Skarlat S Schulte M Borkowski and P Leitner ldquoResourceprovisioning for IoT services in the fogrdquo inProceedings of the 9th

IEEE International Conference on Service-Oriented ComputingandApplications SOCA 2016 pp 32ndash39 ChinaNovember 2016

[25] O Skarlat M Nardelli S Schulte and S Dustdar ldquoTowardsQoS-Aware Fog Service Placementrdquo in Proceedings of the 1stIEEE International Conference on Fog and Edge ComputingICFEC 2017 pp 89ndash96 IEEE Madrid Spain 2017

[26] 2018 httpparasolcsrutgersedu[27] T M Quang D T Nguyen A Van Le H D Nguyen and

A Truong ldquoToward service placement on Fog computinglandscaperdquo in Proceedings of the 4th NAFOSTED Conferenceon Information and Computer Science pp 291ndash296 HanoiVietnam 2017

[28] VAkmanContext in Artificial Intelligence A FleetingOverviewMcGraw-Hill Milano Italy 2002

[29] P Bouquet C Ghidini F Giunchiglia and E Blanzieri ldquoThe-ories and uses of context in knowledge representation andreasoningrdquo Journal of Pragmatics vol 35 no 3 pp 455ndash4842003

[30] A K Dey ldquoUnderstanding and using contextrdquo Personal andUbiquitous Computing vol 5 no 1 pp 4ndash7 2001

[31] T T Do P H Phung and T M Quang ldquoToward An IoT-basedExpert System for Heart Disease Diagnosisrdquo in the 28thModernArtificial Intelligence andCognitive Science Conference (MAICS)pp 157ndash164 Fort Wayne Ind USA 2017

[32] H Gupta A V Dastjerdi S K Ghosh and R BuyyaldquoiFogSim A Toolkit for Modeling and Simulation of ResourceManagement Techniques in Internet of Things Edge and FogComputing En-vironmentsrdquo Tech Rep CLOUDS-TR-2016-2Cloud Computing and Distributed Systems Laboratory TheUniversity of Melbourne 2016

[33] IBM CPLEX Optimizer 2018 httpswwwibmcomanalyticsdata-scienceprescriptive-analyticscplex-optimizer

[34] I Pietri G Juve E Deelman and R Sakellariou ldquoA perfor-mancemodel to estimate execution time of scientific workflowson the cloudrdquo in Proceedings of the 9th Workshop on Workflowsin Support of Large-Scale Science WORKS 2014 pp 11ndash19 NewOrleans LA USA

[35] Elastic Compute Cloud (EC2) 2018 httpsawsamazoncomec2pricingon-demand

[36] N McKeown T Anderson H Balakrishnan et al ldquoOpenFlowenabling innovation in campus networksrdquo Computer Commu-nication Review vol 38 no 2 pp 69ndash74 2008

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


and network bandwidth consumption optimal utilization ofcomputational resources and scalability

In fact most of IoT data and services are generatedand consumed by local users Therefore to cope with theaforementioned issues a recent trend is to devise effectiveedge computing infrastructures termed as Edge-of-Things(EoT) computing edge computing or fog computing [2] Fogcomputing allows moving compute and storage resourcescloser to IoT devices where data is generated Fog computingdevices could be smart gateways or routers deployed at thenetwork edge local PCs and even mobile devices such assmartphones or tablets carried by users that can offer com-puting and storage capabilities These devices play their ownroles of determining what data should be stored or processedlocally (for low latency and saving network bandwidth) andwhat needs to be sent to the cloud for further analysis Itis clear that EoT complements CoT paradigm in terms ofproviding high scalability low delay and location awarenessand leveraging local resources which are available at thenetwork edges

Although the benefit of fog computing in the IoTs is clearand the basic ideas of this computing paradigm have beenwell stated in various researches [3 4] there still lacks sys-tematical modeling for practical fog computing frameworksand effective service placement approaches to maximize theutilization of existing devices on the fog landscape while sat-isfying application response times and reducing energy andoperation cost In this article we propose a novel approachto task placement on fog computing made efficient for IoTapplication provision The main contributions of this workare summarized as follows

(i) We propose a systematical fog computing frameworkconsisting of multiple intelligent tiers that effectively supportIoT service decentralization

(ii) We devise an efficient task (service) placementapproach to optimizing service decentralization on fog com-puting landscape leveraging context-aware information suchas location compute and storage capacities of fog devices andexpected deadline of an application and hence maximize theutilization of fog devices that are available at the networkedge and minimize the latency energy consumption andcost

(iii) We conduct a thorough feasibility and performanceanalysis with various simulations The results provide acomprehensive understanding of the effectiveness of theproposed approach in terms of maximizing the utiliza-tion of fog devices while reducing latency energy con-sumption and network load In addition the experimen-tal results with service deployment in real-world applica-tions that we have built for a smart city ecosystem inHo Chi Minh City such as the intelligent transportationsystem (ITS) show the feasibility of the proposed solutionThese results demonstrate the robustness of the proposedscheme revealing its capability to maximize the IoT poten-tial

The rest of the paper is organized as follows Section 2reviews related work The overall architecture and problemdefinition are described in Section 3 The proposed serviceplacement mechanism is presented in Section 4 Section 5

describes the evaluation of the proposed approach whileSection 6 concludes the paper

2 Related Work

Most of the existing IoT related projects assume the avail-ability of centralized data centers based on a cloud-centricapproach [5] A typical example is described in [6] whichaddresses necessary components of a cloud-centric IoT archi-tecture The authors proposed a federation between a privatecloud (eg Aneka their own system) and a public cloud (egMicrosoft Azure cloud) to efficiently handle sensing datafrom wireless sensor networks (WSNs) In the networkingaspects this approach focused on access networks whileignoring the core networks Consequently it could not satisfythe effectiveness required in IoT as global services are mainlycomputed on the cloud and transmitted and managed overthe core networks

There are several works to reinforce the shortage ofcloud-centric IoT approaches by employing localization ofcomputing resource [2 3 7] The work in [7] describes aLocality-Based Utility Computing (LUC) Operating SystemThese utilities are distributed over the network backbonessuch as local servers connecting to routers aiming to providethe computing resources The motivation of this work issimilar to our present paper which is instead of buildingbigger and bigger data centers and oversized networks weshould bring resources near to the network edges or userswhere the IoT data is created Unfortunately the workin [7] had not utilized context-aware information such aslocation awareness and other related information to improveits effectiveness but keeps location awareness for futurework

Deploying miniclouds or private clouds on the networkedges to handle IoT data processing and service provisioninghas extracted numerous researches [8 9] Having smallclouds ormicrodata centers at the edges can help to efficientlydeliver services closer to users hence mitigating trafficbombing on the network and reducing communication costIn order to direct research to a more standardized approachCisco proposed the fog computing concept in a seminalstudy in [2] Fog computing is a highly virtualized platformthat provides compute storage and networking servicesbetween end devices and traditional cloud computing datacenters typically but not exclusively located at the edge ofnetwork

Several studies such as [8 10] discuss the challengespotential applications and benefits of fog computing It isconsidered a complementary technique to cloud comput-ing that provides the missing links in the cloud-to-thingcontinuum in the IoT paradigm [11 12] Studies in [13]analyze the essential roles of fog computing for extendingcontinuous links of IoT data and services from the cloudto the network edges Meanwhile studies in [14] proposearchitectural imperatives for fog computing and analyze usecases requirements and architectural techniques for fog-enabled IoT networks




























IoT

Distrib

uted

serv

ice

Cloud Gateway(CG)

Cloud Gateway

Cloud s

ervic

es

Fog s

ervic

es

(CG)

Fog control

Wired client

DS1DS2

DSG

(DSG)DS Gateway

Wireless client


Fog colony

Fog colony

Fog colony

node (FG)



























119877119860119896 le 119863119860119896 forall119860119896 (1)













Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





























IoT

Distrib

uted

serv

ice

Cloud Gateway(CG)

Cloud Gateway

Cloud s

ervic

es

Fog s

ervic

es

(CG)

Fog control

Wired client

DS1DS2

DSG

(DSG)DS Gateway

Wireless client


Fog colony

Fog colony

Fog colony

node (FG)



























119877119860119896 le 119863119860119896 forall119860119896 (1)













Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia















IoT

Distrib

uted

serv

ice

Cloud Gateway(CG)

Cloud Gateway

Cloud s

ervic

es

Fog s

ervic

es

(CG)

Fog control

Wired client

DS1DS2

DSG

(DSG)DS Gateway

Wireless client


Fog colony

Fog colony

Fog colony

node (FG)



























119877119860119896 le 119863119860119896 forall119860119896 (1)













Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



IoT

Distrib

uted

serv

ice

Cloud Gateway(CG)

Cloud Gateway

Cloud s

ervic

es

Fog s

ervic

es

(CG)

Fog control

Wired client

DS1DS2

DSG

(DSG)DS Gateway

Wireless client


Fog colony

Fog colony

Fog colony

node (FG)



























119877119860119896 le 119863119860119896 forall119860119896 (1)













Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia














119877119860119896 le 119863119860119896 forall119860119896 (1)













Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





Fog landscape




Application



119909119891120591119894 + 119909119865120591119894 + 119909119873120591119894 + 119909119877120591119894 = 1 forall120591119894 (2)


max119873sum119894

(120572119877119890119904(119865)sum119891

119909119891120591119894 + 120573119909119865120591119894 + 120574119909119873120591119894) (3)









119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia






119903120591119894 = 119908120591119894 + 119898120591119894 + 119889120591119894 (4)













119903119860119896 = max120591119894isin119860119896

(119903120591119894)m = max120591119894isin119860119896

(119908120591119894 + 119898120591119894 + 119889120591119894) (5)



119908120591119894 = 119879119873119909119873120591119894 + 119879119865119909119865120591119894 + 119879119891119909119891120591119894 (6)





119879119873 = 119879119898 minus 119879119901119898 (7)




119879119898 = 120582119879119898 + (1 minus 120582)119879119898minus1 120582 isin [0 1] (8)



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



TimeCurrentcolony F

Neighborcolony N

t=0




４

-gt ４Ｇ-1

４Ｇ=４Ｇ+(1-)４Ｇ-1





119908120591119894 = 119879119873119909119873120591119894 (9)


119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 + 119909119877120591119894119898119877120591119894 (10)



119898120591119894 = 119909119865120591119894119898119865120591119894 + sum119891isin119877119890119904(119865)

119909119891120591119894119898119891120591119894 + 119909119873120591119894119898119873120591119894 (11)


119862119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816sum120591119895isin119869119901119898 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862

119901(12)


119898119901120591119894 =10038161003816100381610038161205911198941003816100381610038161003816119862119901120591i (13)







119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




119898119865120591119894 = sum120591119895isin119869 119909119865120591119894 1003816100381610038161003816100381612059111989510038161003816100381610038161003816119862119865 (15)



119898119873120591119894 = 119898119873119896

(17)



119898119873120591119894 = 120583119898119873119896 + (1 minus 120583)119898119873119896minus1

120583 isin [0 1] (18)







119864 = 119870⋃119896=1

119864119891119896cup 119864119873119896 cup 119864119877119896 (19)

where119864119891119896





119889120591119894 = 2 (119889119891120591119894119909119891120591119894 + 119889119873120591119894 119909119873120591119894 + 119889119877120591119894119909119877120591119894) (20)



119889119901120591119894 = 119889119901120591119894119905119903119886119899119904 + 119889119901120591119894119901119903119900119901 + 119889119901120591119894119902119906119890119906119890 = 119863120591119894119887 + 119889119901120591119894119901119903119900119901 (21)



sum120591119895isin119869119901119898

119878120591119894 le 119878119901 (22)








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia








Nodef CPU(MIPS)













0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



0

10

20




minus10minus5

05

101520253035

Tim

e (se

cs)


DeadlineNode Delay


50100150200250300350400450

MI














Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Tim

e (s)



5

10

15

20

25

0



100908070605040302010

0Port

ion

of T

ask

Plac

emen

t


24 25








2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



2827262322212018 191716 1514 1312 11109 8 7 6 543 21

Ener

gy (w

)FogCloud

Configuration Index

30000

20000

10000

0

70000

60000

50000

40000

24 25



Cos

t ($)

000008000006000004000002

0

00002000018000016000014000012

00001

Config Index2827262322212018 1917161514131211109 8 7 6 543 21 24 25

























6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


















6 Discussion




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




7 Conclusion




Data Availability




Acknowledgments


References









































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia




RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


Documents

Task Placement on Fog Computing Made Efficient for IoT ...downloads.hindawi.com/journals/wcmc/2019/6215454.pdf · as computational power, data organization and indexing, and functional