Research ArticleMultilayer Architecture Model for Mobile CloudComputing Paradigm

Higinio Mora ,1 Francisco J. Mora Gimeno,1

Mar-a Teresa Signes-Pont,1 and Bruno Volckaert 2

1Department of Computer Science Technology and Computation, University of Alicante, 03690 Alicante, Spain2Internet Technology and Data Science Lab (IDLab), imec, Department of Information Technology, Ghent University, Belgium

Correspondence should be addressed to Higinio Mora; hmora@ua.es

Received 9 November 2018; Accepted 27 January 2019; Published 11 February 2019

Guest Editor: Andrew Schumann

Copyright © 2019 Higinio Mora et al. This is an open access article distributed under the Creative Commons Attribution License,which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Mobile Cloud Computing is one of today's more disruptive paradigms of computation due to its effects on the performance ofmobile computing and the development of Internet of Things. It is able to enhance the capabilities of devices by outsourcing theworkload to external computing platforms deployed along the network, such as cloud servers, cloudlets, or other edge platforms.The research described in this work presents a computational model of a multilayer architecture for increasing the performanceof devices using the Mobile Cloud Computing paradigm. The main novelty of this work lies in defining a comprehensive modelwhere all the available computing platforms along the network layers are involved to perform the outsourcing of the applicationworkload.This proposal provides a generalization of theMobile Cloud Computing paradigmwhich allows handling the complexityof scheduling tasks in such complex scenarios. The behaviour of the model and its ability of generalization of the paradigm areexemplified through simulations. The results show higher flexibility for making offloading decisions.

1. Introduction

Cloud Computing paradigm is one of the most disrup-tive technology advances of our times. This paradigm hasmade Information Technology (IT) resources available to thegeneral public through Internet. In this way, any business,organization or particular user can access to computinginfrastructures and services for a fee. The progress of com-munication technologies has also contributed to this end.Boosting the bandwidth and hence speed of all connectionshas enabled us to handle more traffic. In addition, theimprovements on management of cloud centres thanks tovirtualization and server consolidation methods allow us togive a rapid response to changing application demands [1].These cloud-based services evolutions have resulted in anincreased outsourcing work to the cloud in all areas. Thisparadigm is now growing many times faster than the rest ofIT industry [2].

Implementation of this paradigm to mobile computationhas led to Mobile Cloud Computing (MCC) concept [3, 4].

It consists in outsourcing part of the processing load tothe Cloud and getting back the results. The implications formobile devices are evident: in the first place, they can increasetheir performance without any change in their hardware,and, secondly, they allow us to extend the life of battery-powered devices. These benefits have enhanced the potentialof Internet ofThings (IoT) paradigm and allow us to computeadvanced applications on devices and embedded systems.

However, this promise of providing new resourcesbeyond mobile computing capabilities by accessing cloudservers can lead to uncertainty and delays in response timesdue to unpredictability in network operations through theInternet. Further, some applications cannot expect to receivethe calculated results from offloading the source. In general,there is a lack of versatility in the cloud thatmakes it unable toadapt to specific task requirements and to internet operationconditions.Thus, the user-perceived quality is highly variableand depends on both the application’s degree of interactivityand the network’s end-to-end latency. There is a require-ment to improve the ability of the MCC paradigm to meet

HindawiComplexityVolume 2019, Article ID 3951495, 13 pageshttps://doi.org/10.1155/2019/3951495

2 Complexity

the performance requirements for heterogeneous devices indynamic environments where the available infrastructure canchange.

From these motivation aspects exposed by these prob-lems, the main objective of this work consists of researchingarchitecturemodels that are able to increase the resilience andflexibility of offloading the workload outside the device andto enable scheduling the tasks along the network. To advancethis goal, it is assumed as a working hypothesis that severalnetwork computing layers exist around the mobile deviceor embedded system and are available for outsourcing theapplication workload.

The key contributions of this work can be summarized asfollows.

(i) A study of the complexity and key issues of distribut-ing the processing load among several computing lay-ers along the network and a reviewof the architecturesand network layers to perform this offloading process.

(ii) The proposal of a general framework for a multilayerarchitecture to formalize the processing of an applica-tion and the implications of the distributed configu-rations to the performance and the communicationsrequirements.

The novelty of this proposal is the extension of the MCCparadigm to the available computing layers by consideringthem in a comprehensive and integrated fashion with thedistributed architecture.

This paper is organized as follows: in Section 2, we reviewmost relevant models and frameworks of MCC paradigm;in Section 3 the formal framework of the computationalmodel is introduced, and the key technical characteristicsof offloading are described; Section 4 explains how theproposed multilayer computational model can handle real-world scenarios; and, finally, conclusions are drawn and someapproaches for future work are also pointed out in Section 5.

2. Related Work

2.1. Outsourcing Options for MCC. The concept of MCC hasbeen evolved in recent times with the goal of increasingthe performance by offloading the workload outside themobile devices. As a result, the outsourcing options have beenincreased along the communication network as shown inFigure 1.

These outsourcing options are deployed at different layersof the network forming a pool of computing platforms thatare available depending on the application context.

In the top, at the network core, the cloud layer remainsthe most powerful computing platform. This is the tra-ditional way for outsourcing the workload and takes itsorigin from the Cloud Computing Paradigm. Much of thecurrent research on MCC is using this option as a default forimplementing the offloading process [5–7].

Next, the cloudlet layer concept emerges. This infrastruc-ture is a “little” data center with the objective of bringingthe cloud closer to the users [8]. Usually, cloudlets aredeployed inside the organizations that use it [9, 10].Themain

Cloud Server

IoTLayer

Fog Layer

MECLayer

Cloudlet Layer

CloudLayer

Cloudlet

Fog devices LTE Base station

MEC server

Internet

NetworkCore

NetworkEdge

IoT devices

Figure 1: Outsourcing options deployed along the communicationnetwork.

advantages provided by cloudlets are twofold: in the firstplace, to reduce service disruptions and delays caused by thenetwork to remote servers and secondly to ensure a high levelof security of the data since it does not need to be sent throughInternet [11]. Therefore, cloudlets are computing platformssimilar to cloud servers but prepared and scaled accordingto the specific requirements of the organization.

The same principle of cloudlets is applied to the MobileEdge Computing (MEC) Layer. A MEC server is a data centerin a box, that, in this case, it is deployed by themobile telecomoperators in close proximity to mobile subscribers [12].Thus,access to these computing services is made through telecom-munication base stations using communication protocolssuch as 3G or LTE to offer a service environment with highbandwidth and low latency [13, 14]. In addition, the benefitsof MEC paradigm will be enhanced by the advent of 5Gcommunication protocol [15].

These last two layers (cloudlet and MEC) can be enabledin a dynamic way to deliver computing support to the cloudservers. In thisway, they are not replacing but complementingthe Cloud Computing Paradigm by providing a flexible com-puting powerwhen necessary [16].This operation encouragesthe development of IoT solutions and enhances the mobileapplications when devices are moving over time.

Finally, a recent trend to develop the model of MCCis the Fog Computing Paradigm. The fog layer is a set ofdevices such as routers, switches, or other networking devicescloser or within the end users' local networks. Their aimis to provide processing efforts as close as possible where

Complexity 3

the data is generated [17]. Thus, these devices have somecomputing capabilities able to compute part of the workloadof the “things” and other application devices [18, 19]. Asa result, service delay is significantly reduced for end userapplications.

2.2. MCC Frameworks. Realizing the vision of multilayeroffloading architecture for implementing theMCC paradigmis a challenging task because of the complexity in handlingthe multiple aspects involved, especially those concernedwith performance evaluation and tasks scheduling. In thisissue, the motivation for offloading is diverse depending onthe user requirements, device configuration or applicationconstraints.Moreover, performance aspect can be of differentnature such as power consumption, time delay, money cost ofusing external services, and network usage.

There is a need to design suitable frameworks to formalizethe performance components in a homogeneous way tomakedecisions on when and where to outsource the processingload. In this subsection, a review of recent frameworks ofMCC paradigm is described in order to reach the knowledgeborder in this issue.

There are several existing frameworks and architecturesin the literature for outsourcing the tasks of the applicationworkload to other computing platforms.The areas of applica-tion of these techniques cover many sectors and disciplines.In general, they develop the IoT and Cyber-Physical Systems(CPS) paradigms that are experiencing a great growth inrecent years. The devices involved are a heterogeneous setwhich mainly consists of sensors, actuators, and embeddedsystems. In addition, the mobile phones and other mobiledevices such as wearables are also in this kind of applications.

As overview of the MCC proposals, they aim to carryout a collaborative work for distributing the processing loadand meeting the application requirements [20, 21]. In mostcases, these applications have special features and are highdemanding of computing resources such as multimedia anal-ysis [22], high volume of data [23], or real-time constraint [4].By distributing the work, the cloud architecture bottleneck isovercome, and better delay and predictability can be achieved[24, 25].

In general terms, offloading from the “things” or mobiledevices to cloud, edge, or cloudlet server always producedsignificant increase in performance. It is clear that the slowerthe devices are, the sharpest these differences become. How-ever, the offloading criteria can consider other aspects such asnetwork usage or money cost of external computing services[26]. In these cases, an indirect relation exists between usingoutsourcing services and benefits. Thus, the benefit functionneeds to be redefined to consider a heterogeneous type ofaspects in order to make decisions on where and when tooutsource the application workload.

The key parts of a framework for handling the offloadingprocess are the architecture that defines the available out-sourcing platforms, the decision method on where and whento offload, and the communicationmodel that defines how toperform this process.

Regarding the decision method for offloading, in generalterm, it is considered as a scheduler which decides when

and where to offload taking into account the applicationconstraints, the tasks’ features, and the performance aspectsof the available computing platforms. Its main aim is how toreasonably allocate the tasks to available computing platformsto minimize the total cost and load. The optimal schedulingscheme belongs to NP-complete problem set and, therefore,traditional strategies cannot be applied in a suitable way forMCC applications.

To address this issue, many approaches have been pro-posed based on different mathematical techniques and algo-rithms. In recent approaches, the scheduling method can beformulated as a constrained optimization problem where asuboptimal solution is usually the best choice.Thesemethodscan be used for multitask [27] and multiobjective [28]scheduling problems in several scenarios. In the same line,there are methods based on stochastic techniques and searchalgorithms to deal with the high complexity of this problem[29, 30].Other proposals are based ondynamic programmingmethods in order to handle the runtime variations of tasksexecution [31]. Also, a decision tree can be built to classifythe conditions and decision parameters in order to get afast offloading response [32]. Finally, other works proposeinnovative approaches to address this problem based ontechniques used for processor scheduling area such as geneticalgorithms [33], and imprecise computation strategies [4].

Inmost cases, the offloading decisions aremainly focusedon energy optimization [31] since it is a critical issue formobile devices. However, other performance aspects such asresponse time and Quality of Service (QoS) are also beingconsidered by these methods [4, 27, 29, 33].

The frameworks can be implemented as a set of proce-dures, methods, and tools. These components can be partof the device itself or installed in a middleware layer in anexternal supervising device [34]. This layer is introducedas an intermediary between the devices and the computingplatforms and it works as a smart gateway that monitors theunderlying nodes and decides if offloading is needed or not[35, 36]. Table 1 summarizes the recent proposals on theseaspects.

2.3. Findings. After reviewing the frameworks for offloadingmobile computation, three main findings can be drawn thatjustify our proposed model for designing multilayer MCCarchitectures:

(1) The general objective of existing MCC architecturalapproaches is to improve the overall applicationfunctioning. However, in most cases, they do notconsider multiple options for offloading the work northe intermediate network infrastructure.

(2) There are numerous frameworks on how to distributethe computation of the applications to performpartialremote execution. They are mainly focused on mini-mizing the energy consumption of devices, increasingthe performance, and maximizing the overall QoS.However, they do not consider heterogeneous perfor-mance metrics such as money cost or global networktraffic.

4 Complexity

Table 1: Recent frameworks for MCC.

Work Key aspects of frameworkCollaborative Working Architecture [20] General architecture and scheduler. OT: ad hoc cloud, fog, and CloudMultilayered scheduling [37] Tasks specification, scheduling method. OT: ad hoc cloud of CPS nodesCuckoo [38] Programming model and integration tools. OT: CloudData storage framework [39] Architecture, Database Management, and File Repository Model. OT: CloudFlexible Framework [4] General architecture and Scheduling method. OT: CloudCyber-Manufacturing [40] Architecture, communication protocol and analysis. OT: Cloud, cloudlet, fog

Federated IoT services [41] Management, problem formulation, and heuristic for tasks allocation over 5G. OT: MEC, adhoc clouds

VMmigration framework [42] Smart precopy live migration approach. OT: Fog, CloudCloudlet in MCC [10] Architecture, Stochastic performance modelling. OT: Cloudlet, CloudResource usage optimization [5] Architecture, Resource usage, and performance evaluation modelling. OT: CloudMobile code offloading [43] Architecture, offloading methods in Java and push notifications. OT: CloudQoS Aware Computation Offloading [44] Problem formulation, optimal offloading decision process. OT: ad hoc cloudAdaptive MCC framework [45] Application partitioning, offloading decision algorithm. OT: CloudEdge Computing Framework [22] Communication and Computation Models. OT: Edge nodesDistributed computational model [46] Resource utilization specification, management system. OT: CPS nodes, CloudScheduling internet of things applications[47] Scheduling method, performance metrics. OT: Cloud

IoT and Cloud Computing Integration [48] Architecture and components. OT: CloudContext-aware computation offloading [49] Design pattern and estimation model. OT: CloudEdge-Fog cloud [50] Method for distributing the processing tasks. OT: Edge and fog nodesFramework for code offloading [25] Architecture and offloading decision-making engine. OT: Edge and CloudOffloading target (OT).

(3) The existing works in the literature do not provide aformal framework to formalize the overall offloadingprocess; rather, they conduct numerical results oftheir reference architectures. Other works have insuf-ficient depth, or they are focused on specific issues ofeach layer separately.

The research presented in this article pursues the sameobjectives as mentioned above. To the best of our knowledge,this is the first study to provide, from a holistic perspective, acomprehensive model that provides an analysis of technicalaspects and includes all known computing layers of thenetwork.Thismodel will allow us to handle complexity of theoffloading process of MCC systems.

Next section introduces the proposedmultilayer architec-ture and presents a formal basis for modelling the offloadingprocess in the MCC paradigm.

3. Multilayer Architecture Model

3.1. Proposed Distributed Architecture. This architecturedesign promotes an adaptation to changing environmentsand enables a dynamic scaling of computational power ableto assume a variable and/or intensive application workload inamore effectivemanner than existing proposals.The networklayers considered for offloading computation can be thosedescribed in Section 2.1. An overview of the network layersto be used by the proposed framework is depicted in Figure 1.

This approach attempts to identify methods to obtain thebest results and performance using the network infrastruc-ture deployments and local processing capabilities. Multipledesign configurations can be supported. The mobile devicesand connected “things” can be heterogeneous and havedifferent capabilities for processing data. The middle infras-tructure layers can be deployed by stakeholders to improvethe execution of their mobile or IoT applications and extendthem to more potential customers, for example, advancedmultimedia games and complex financial apps. These layerscan be equipped with specialized hardware componentsfor improving the complex calculations, including customcloudlets with GPUs, DSP, and cryptographic coprocessors.

Below, the main technical characteristics of the MCCparadigm are introduced together with the implications andadvantages provided for them by the proposed model.

The application partitioning method is a critical aspect forenabling the outsourcing of the code at multiple heteroge-neous layers of the network architecture, even at the nearestavailable layers. In this manner, although an elastic approachis desirable to provide flexibility, the time determining theoffloadable code must be minimized. Thus, the proposedarchitecturemust use a static partitioning to know, at any step,the candidate parts of the application to be offloaded. Otherdynamic proposals can be applicable in a complementaryfashion if resources exist.

The offloading decision mechanism can be, at the firstlayer for either of the mentioned options: static or dynamic.

Complexity 5

Table 2: Technical characteristics of offloading methods and frameworks.

MCC technical characteristics Methods Key aspects for multilayerarchitecture

Application partitioning method Static, dynamic Exploit the available nearest resources

Offloading decision mechanism Static, dynamic Leverage the potential of the availableresources

Granularity unit Module, bundle, subroutine, process, thread, class, component,method

Provide flexibility to the applicationneeds

Offloading mode Client-server communication, virtualization, mobile agents Support heterogeneous infrastructuresContext-awareness offloading Adaptive schemes Awareness of available layers

Cost-benefit model Resource monitoring and profiling, parametric analysis,stochastic methods

Decide where to perform thecomputations

However, to ensure that the maximum advantage of theavailability ofmultiple layerswith different profiles is selected,the dynamic option is preferable. In this case, the architecturemust calculate, for each layer, the offloading decision accord-ing to an optimization problem that addresses all the issuesspecified. This algorithmmust be able to be executed quicklyto leverage the potential of the available resources. In theprevious section the latest trend on this issue can be found. Inany case, fast methods [32] and real-time strategies [4] mustbe introduced to provide a rapid response and address thetime constraints.

The desirable granularity unit for outsourcing must be assmall as possible to provide the highest flexibility; however,small size implies higher management cost. The granularityunit for the architecture can be variable, depending on thefeatures of the target platform for offloading. That is, smallparts of the application can be outsourced for fast executionon surrounding platforms and other intensive parts can beoffloaded to specialized platforms. The optimal partitioningis an NP-complete problem [51]. To avoid time consumptionin the automatic analysis of the code, the variable granularityapproach can be made in the design stage of the application.This requires the collaboration of the application developersby annotating into the code the possibilities for outsourcing.

The offloading mode for the proposed MCC architecturemustmeet the followingminimum requirements: themethodmust be suitable for heterogeneous infrastructures and mustuse a lightweight method so as to not overload the limitedresources of the edge layers (devices of ad hoc clouds andfog nodes). The mode based on mobile code would appearto be the best option; however, it requires further researchon mobile agent management to become a robust optionfor implementing heterogeneous MCC architectures [3].Until then, a combination of virtualization and client-servermethods offers the best results for each layer.

The context-awareness feature is important to performoffloading to several layers of the network. The desirableconfiguration requires a self-adaptive architecture to knowwhat layers and devices are available at any time for offloadingthe work. It is significant to perform this feature withoutintervention of an administrator to shape dynamic environ-ments. It is precisely in these complex environments wheremany options exist and where the proposed architectureattains its full potential.

Finally, the cost-benefit function must be computed oneach level of the architecture to determine where to performthe computation. Thus, complex algorithms are not suitablefor this function, although suboptimal decisions are found.A stability of the performance for network infrastructure inthe same working conditions is supposed. Hence, predictionmodels based on look-up tables of history data are a fastapproach to the offloading of application work. Further, thisinformation can be complemented at minimum cost withdata from the device itself and the main network parameters.

Table 2 presents the technical characteristics of offloadingmethods and frameworks for the MCC paradigm and high-lights the key aspects for a multilayer architecture.

The descriptions and recommendations regarding theoperation of the proposed architecture reveal that therecontinue to be important challenges that must be addressedto leverage the available infrastructure at multiple layers ofthe network. In this regard, this work introduces basic ideasand notes on specific research issues for implementing amultilayer architecture.

The next subsection describes the formal framework ofthe architecture and the elements involved in the distributedcomputing.

3.2. General Framework. This subsection describes the gen-eral aspects of the multilayer distributed architecture foroutsourcing the processing load using the combination ofcomputing layers of the available infrastructure.

According to the stated working hypothesis, the mainidea behind the multilayer architecture to address compu-tation offloading is to offer a set of options for performingthe computations at different network layers where availableinfrastructure exists. As a rule, it is advisable to perform theprocessing as close as possible to where the data are acquiredto reduce the delay and global network traffic. However,the final decision on where to offload each task dependson many other aspects including application requirements,devices configuration, user preferences, size of input data,and pricing. The result is a flexible and scalable model wherethe computations can be performed on a variety of platformsand computing layers. The formulation introduced in thissubsection is utilized to better describe the contributionsof the proposed architecture for providing flexibility tothe processing requirements of IoT applications. Important

6 Complexity

Table 3: Summary of Notations.

Notation Definition (#Expression)tj Application TaskΓAppl = {t1, t2, . . . , tn} Set of Application tasks (1)L = {L0, . . . , Lcc} Set of available computing layers (2)pj Computing platformpkj Computing platform of layer kp0j Computing platform of layer baseLj = {pj1, pj2, . . . , pjmj} Set of computing platf. of layer j (3)𝐴𝑡𝑖𝑚𝑒𝑝0𝑖 ={p1,i, p2,i, . . . , pcc,i}

Set of the available upper platforms of devicep0i at a time (4)Ω ={delay, power, . . .} Set of performance aspects (5)

∧(ΓAppl) =⟨(t1, pk1,j1), . . .⟩

Sequence of platforms on which theapplication is processed (13)

∧𝑚𝑖𝑛(𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 ) List of platforms that meets the minimumcomputing costs for the 𝛼 performance

aspect at a given time

∧𝑚𝑖𝑛(𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 ) List of platforms that meet the minimumcommunication costs for the 𝛼 performance

aspect at a given timeΔ Saturation value in calculation costData(ti, ) Volume of data generated by task ti (10)

Data(ti, pj,k) Necessary data to be moved for computingthe task ti in the platform pj of the layer k

(11)

notations and expression used in this paper are provided inTables 3 and 4.

First, we consider a granularity unit for offloading theapplication task. This unit can be one of those mentioned inTable 2 under the condition that the applications consideredby this framework consist of a list of tasks. The tasks canbe executed sequentially or in parallel depending on theinterrelationships between inputs and outputs. These taskscan be variable sized depending on the offloadable code. Forexample, a task can be a fragment of code, such as a set ofinstructions, a process, a method, or a subroutine.

Let ΓAppl be the set of tasks of an application:

ΓAppl = {t1, t2, . . . , tn} . (1)

These tasks can be processed at different computing layersand platforms. LetL be the set of available computing layersof the architecture:

L = {L0, . . . , Lcc} (2)

The number of network processing layers depends onnumerous aspects such as execution environment, availableinfrastructure, and configuration options. In all these cases,L0 is the layer of the single device where the task is generatedand Lcc is the remote cloud-computing server. In betweencan be several available computing layers to perform theprocessing at different levels. For example, in an autonomousvehicle application context, L1 can be the network composed

Table 4: Summary of Formulations.

Formulation Definition (#Expression)

𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ti, pk,j) Processing cost of the task ti in theplatform pk,j for the 𝛼 performance

aspect (7)

𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min

Minimum processing cost of theapplication for the 𝛼 performance

aspect (17)

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ti, pk,j) Communication cost to move the taskti to the platform pk,j for the 𝛼

performance aspect (9)

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min

Minimum communication cost of theexecution of the application for the 𝛼

performance aspect (18)

𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl) Execution cost of the application forthe 𝛼 performance aspect (6), (14)

𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min

Minimum execution cost of theapplication for the 𝛼 performance

aspect (16)

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ΓAppl) ∧min

Minimum communication costthrough the distributed architecturefor the minimum processing cost (19)

Data(ΓAppl) Volume of data to be moved forcomputing the whole application (15)

Data (ΓAppl)min

Volume of data to be moved throughthe distributed architecture to run theapplication within the minimum cost.

(20)

of several nearby vehicles, L2 can be the layer formed bythe city traffic infrastructure or deployed cloudlets, and L3can be the mobile edge-computing infrastructure behindthe communication network. Other configurations of theinfrastructure can be configured for this application.

Each layer has a set of computing platforms, which canbe heterogeneous with different processing capabilities andabilities according to their characteristics. Thus, layer Lj hasmj computing platforms, where Lj ∈ {0, . . . , cc} and mj > 0:

Lj = {pj1, pj2, . . . , pjmj} , (3)

where pjk is platform k of layer j.The different layers of the network can be deployed in

sequence or in a parallel configurationwhere each computingplatform of a layer can execute the services of the upper layersand provides services to several elements of the lower layers.

For a specific device (p0i), the list of available upperplatforms at a given time can be expressed by 𝐴𝑡𝑖𝑚𝑒𝑝0𝑖 :

𝐴𝑡𝑖𝑚𝑒𝑝0𝑖 = {p1,i, p2,i, . . . , pcc,i} (4)

The list of platforms described in Expression (4) repre-sents the specific network architecture for the device andindicates the possibilities for offloading the work at thegiven time. This list can vary with time depending on theapplication context. For example, if the mobile device ismoving, the available infrastructure can change.

Complexity 7

Several expressions can be introduced into the proposedgeneral framework to define the behaviour of the multilayerarchitecture related to performance and resource consump-tion issues. In this section, the execution cost and datacommunication are analysed. The execution cost can be anyof the different performance aspects that are involved in theexecution of a task in a device. In this manner, letΩ be the setof performance aspects to consider:

Ω = {time delay, power consumption,money, . . .} (5)

For each of these aspects, the overall execution cost (E)of an application in this distributed infrastructure consists oftwo main components as indicated in Expression (6): (a) thecomputing cost (Cmp) and (b) the communication cost alongthe network and layers (Net):

𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl) = 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ΓAppl) + 𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ΓAppl) , (6)

where 𝛼 ∈ Ω.The cost expressions are a function of time because the

execution conditions can change at any time depending onthe workload currently processing on each platform, theother processes that eventually are executing simultaneously,and the network traffic situations.

Related to the first aspect (a), the processing capabilityof each computing platform can be in a range from zero toextremely high. Further, there may be platforms with specificcapabilities that provide services to many applications andallow the acceleration of the processing of specific types oftasks. For example, GPUs can be installed on the cloudletservers to accelerate multimedia algorithms. In this manner,the granularity of this calculation is the cost of computingeach task. For each task ti of the application, the cost ofexecuting ti on each element of the distributed architecturecan be determined. Expression (7) is the cost of processing theti task in platform pj of layer k for the 𝛼 performance aspect:

𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ti, pk,j) ∈ R+⋃{0} (7)

The workload of a platform can vary during the daydepending on the number of devices simultaneously con-nected and other features. This fact is common in the inter-mediate platforms and in the cloud infrastructure becausethey collect data from different elements of the lower levels.However, it is normal that they have redundant computingelements that perform massive parallel processing. If a plat-form cannot compute a task, it will be assigned a cost of thesaturation value 𝛿. That is,

∀x ∈ R+⋃{0} ,

x + 𝛿 = 𝛿. (8)

In addition to computational cost, the framework consid-ers the communication cost along the architecture, that is, thecost of moving the tasks between the platforms and layersas well as the data they require. The following expressionindicates the communication cost to move task ti to platformpj of layer k for the 𝛼 performance aspect:

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ti, pk,j) ∈ R+⋃{0} (9)

This expression is also a function of time and can havea variable result at any time according to different aspectssuch as network congestion, device connectivity, bandwidthavailability, and pricing. The cost of moving the data in thesame processing element is null; that is, executing the entireapplication on the same platformprocessor has no communi-cation cost. Further, as in the case of the computational cost,if it is not possible to move the data to the p platform, thenthe communication cost is 𝛿, for example, when the platformis not connected to the place where this data was generatedor there is no connectivity.

The communication cost can be any performance aspectof the set Ω defined in Expression (5). A complementaryexpression can be defined to determine the transferred data(in data units) between platforms when the processing isdistributed. Expressions (10) and (11) indicate, respectively,the volume of data generated by each task and the necessarydata to be moved for computing task ti in platform pj of layerk. If the task is processed in the same platform, the necessarydata is zero. These functions are independent from time:

Data (ti, ) ∈ R+⋃{0} (10)

Data (ti, pj,k) ∈ R+⋃{0} (11)

Normally, the necessary input data of a task correspondswith the generated output data from the previous task:

Data (ti+1, pj,k) = Data (ti, ) (12)

The data flow and connectivity of the computing plat-forms define a graph to share and distribute the applicationworkload. In the base of the graph are the mobile/embeddeddevices; the upper side is formed by the cloud-computingservers. Between these two sides, several intermediate com-puting platforms can be installed. This infrastructure allowsexecuting advanced applications and provides improvedoverall performance.

In this architecture, movements of the tasks can occurbased on the offloading configuration and execution costs.The many possible options allow flexible implementation ofthe applications to optimize any of the system parametersincluding minimizing response time, reducing the data flowthrough the communication network,minimizing the energyconsumption of the devices, increasing the processing timeof the cloud system, and minimizing the money cost ofusing external resources. Hence, the proposed multilayerarchitecture allows the design of numerous configurations forthe execution of tasks depending on the type of application,execution restrictions, or operating conditions consideringthe above aspects.

The sequence of platforms on which the applicationexecutes is defined by the vector ∧(ΓAppl) as follows:

∧ (ΓAppl) ≡ ⟨(t1, pk1,j1) , . . . , (tn, pkn,jn)⟩ , (13)

where ∀ti ∈ ΓAppl. ∧i[k,j] = (ti, pk,j); that is, task ti is processedon platform j of layer k.

8 Complexity

Then, the execution cost of an application can be obtainedexpanding Expression (6) with the platforms of the vector ∧:

𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl) = ∑i[𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (∧i[k,j]) + 𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (∧i[k,j])] . (14)

Similarly, the amount of data to be moved for computingthe entire application is obtained from the next expression:

Data (ΓAppl) = ∑iData (∧i[k,j]) . (15)

From the previous expressions, calculations can be madeto optimize the processing according to the configurationcriteria of the architecture. Consequently, a more appropriatesequence of platforms for outsourcing is obtained.This infor-mation can guide the scheduling methods and the offloadingstrategy to achieve the best performance.

The following expression obtains theminimumcost of theexecution of the application considering the cost of the plat-forms and cost of data movement along the communicationnetwork:

𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min

= mink,j

{∑i[𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (∧i[k,j]) + 𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (∧i[k,j])]} (16)

The cost of one of the components of Expression (6) couldbe similarly obtained. That is, the next expressions producethe cost for the separate components:

𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min = mink,j

{∑i𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (∧i[k,j])} (17)

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ΓAppl)min

= mink,j

{∑i[if 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (∧i[k,j]) < 𝛿: Nettime (∧i[k,j])

else: 𝛿 ]} (18)

Note that Expressions (16), (17), and (18) only consider thecalculations for the platforms which are able to compute thetasks.

The list of platforms that meets the minimum cost isdefined as follows. Let ∧𝑚𝑖𝑛(𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 ) be the sequence ofplatforms executing each of the tasks that achieve the mini-mum computing cost of the application and let ∧𝑚𝑖𝑛(𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 )be the sequence of platforms that achieve the minimumcommunication cost through the distributed architectureamong the different options for offloading.

Then, considering the minimum processing cost forone performance aspect 𝛼 (for example time delay), thefollowing expression obtains the minimum communicationcost through the distributed architecture to execute theapplication:

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (ΓAppl) ∧min = ∑𝑖

𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 (∧i[k,j]) , (19)

where ∧i[k,j] ∈ ∧𝑚𝑖𝑛(𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 ).

Finally, the following expression obtains the amount ofdata to be moved through the distributed architecture toexecute the application within the minimum cost:

Data (ΓAppl)min = ∑iData (∧i[k,j]) , (20)

where ∧i[k,j] ∈ ∧𝑚𝑖𝑛(𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝛼 ).It is notable that the information regarding computational

and communication costs is not fixed and it is time dependentfor some of the performance aspects. Thus, the computingplatforms of the architecture can follow different strategiesto derive the correct decisions regarding offloading tasks toanother platform or layer.

First, it can use prediction techniques based on historicaldata. In this manner, the devices can know the estimatedperformance of the available platforms quickly. A possibleimplementation can be a look-up table that stores the per-formance data for each interesting aspect. The tasks canbe clustered to ensure manageable table sizes. For example,the similarity criteria can be any indicator of the type ofspecialized processing required, such as integer, floatingpoint, multimedia, or cryptographic. This feature should benoted in the programming stage of the application to ease theoffloading process. Moreover, this data must be updated aftereach operation.

Secondly, there are methods for periodically testing thedata time costs. Light threads can be launched at the begin-ning of processing to request performance conditions of thearchitecture.

A combination of the above methods can be made toobtain more accurate information regarding the executioncontext of the architecture.

In any case, an embedded middleware layer could benecessary to take charge of this job. This layer is alreadyplaying an increasingly important role in the edge computingparadigm to perform discovery and other broker services[52]. In this case, it is responsible for gathering and evaluatingall the relevant data and identifying the available optionsto make the right offloading decision. The cost of thisdecentralized approach is lower than a centralized controlhosted somewhere along the network. However, the rationaloperation of each device in ad hoc scenario should besatisfactory, but presumably suboptimal [53].

4. Application Examples

This section describes how the proposed multilayer compu-tational model can handle real-world scenarios in order tofind the best execution cost (𝐸𝑡𝑖𝑚𝑒𝛼 (ΓAppl)) for computing anapplication taking into account the different available offload-ing layers. For this purpose, three application contexts havebeen defined to test the model under different conditions.These scenarios correspond to operation modes affected byuser preferences or device configurations. This section justshows three examples. Of course, other application contextscould be defined. In all cases, the main contribution of theproposedmodel is the versatility in formalizing the offloadingrequirements of each environment and the better leveragingof the available resources in the communication network.The

Complexity 9

exact values in simulation and numerical examples providedin this section do not impact essentially to these outcomes.

In these scenarios, the IoT layer is composed by mobiledevices such as smartphones, tablet PCs, and smartwatches.These are heterogeneous devices and might have differentcomputing and communication capabilities. In addition,the users might configure the devices according to theirpreferences and economic plans.

The example application consists of an Augmented Real-ity (AR) system for Smart Cities which enables the user tomove freely through the modelled environment of the cityusing their mobile devices. This technology recognizes whatyou are doing and then enhances it.TheAR systems for SmartCities have great potential for all involved [54], for example,the disabled citizens in order to know the resources forinclusive city and accessible paths along the city. Moreover,the latest AR solutions consider edge resources togetherwith cloudlets and cloud server as high-end computingplatforms to offload the AR applications [55]. Therefore, theavailable layers of the architecture areLA = {IoT devices, fogcomputing, fog nodes, cloudlet, MEC server, Cloud server}.

In this example, the scheduling algorithm of the mid-dleware could be based on prediction techniques and, forexample, the performance estimations could be like thoseshown in Table 5 for each case.These data have been retrievedfrom other sources and on our own experiments of previousresearch on this matter [4, 46]. Scheduling algorithms basedon historical data are common in dynamic environments[56]. Therefore, these performance estimations are recordedin a Look-Up Table that can be embedded in each device andfrequently updated by broker services.

4.1. Battery Saving Application Context. The general defini-tion of these contexts is that the user device is configured tosave battery power. Battery consumption is a performanceaspect for only battery-powered devices such as mobiledevices or wireless sensors. Thus, it only applies to IoTdevices. In addition, this is a static feature. That is

∀𝑘 > 0,𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑏𝑎𝑡𝑡.𝑐𝑜𝑛𝑠. (ti, pk,j) = 0 (21)

Itmeans that the processing cost of outsourcing platformsdoes not matter for this configuration since the only impor-tant thing is energy saving. Thus, under this configuration,the application workload will be outsourced whenever andwherever possible. However, the communication costs formoving the tasks to another computing platform are not voidsince data communication consumes battery. Therefore, inthis scenario, the computation of a task (ti) will be offloadedwhen battery consumption of local execution is greater thancommunication cost to some outsourcing platform (pk,j).That is

∃𝑘 > 0,𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝑏𝑎𝑡𝑡.𝑐𝑜𝑛𝑠. (ti, pk,j) < 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑏𝑎𝑡𝑡.𝑐𝑜𝑛𝑠. (ti, p0,j) (22)

This consumption depends on where the data is moved.Generally, communication costs through a wireless local

network are lower than through a telecommunication net-work such as LTE [57]. Therefore, in this case a table withthe communication cost of the mobile device is needed toimplement the Net function. For example, Table 5(A) showsestimated data of battery consumption (𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝑏𝑎𝑡𝑡.𝑐𝑜𝑛𝑠.(ti, pk,j))for different communication options.

As can be seen in Table 5(A), the communication costthrough mobile operators is higher than through wiredInternet. For this reason, the cost of cloud server is differentaccording to how the connection is made.

4.2. Monetary Cost Saving Application Context. The generaldefinition of this context is that the user device does not haveperformance enough to run theVR application. It is only usedfor displaying the results and, therefore, it has to outsourcethe processing load. In such a context, it is configured tosave processing expenses when using an external computingplatform.

This is a similar approach than the previous one but, inthis case, the device is unable to compute any task; that is

𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑚𝑜𝑛𝑒𝑦 (ti, p0,j) = 𝛿 (23)

This scenario supposes that using outsourcing resourceshas money cost under the Infrastructure-as-a-service (IaaS)model. That is, the workload can be outsourced, but theinfrastructure owner will charge you the cost. In addition,the cost can be variable depending on where the comput-ing platform is placed, its performance, and the moment(hour/day/month) when it is required.The new cloud servicebrokerage efficiently trades infrastructure cloud servicesamong multiple resource providers and consumers [58, 59].In this way, billing is completely flexible and just based onresource usage.

However, in order to know the processing cost, a dynamicmonitoring is needed. For example, Table 5(B) shows anestimated data (𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑚𝑜𝑛𝑒𝑦.(ti, pk,j)) for the different outsourc-ing options at an instant time. In this case, fog layer is notconsidered since it is difficult to estimate the monetary costof outsourcing to it. In addition, due to its limited computingcapabilities, this layer is usually used for short periods of timewhich are not comparable with published hourly rates.

Generally, cloudlet andMEC price should be higher thancloud since they cannot take advantage of economies of scale.In addition, they are limited to a more restricted area, andthus, they have less competitors for outsourcing. From otherpoints of view, cloudlet layer can be deployed and ownedby organizations and therefore they should have no costs fortheir users.

Regarding Net function, the devices might have a com-munication cost. It could also be taken into account in orderto offload through local wireless or communication network,since, in many cases, the former has no costs.

4.3. Real-Time Application Context. The general definition ofthese contexts is to minimize the computing delay of theapplication in order tomeet quality constraints of demandingreal-time AR algorithms.

10 Complexity

Table 5: Performance estimations.

Offloadingtarget

Application context(A) BATTERY SAVING (B) MONETARY COST (C) REAL-TIME

Ω = {battery consumption} Ω = {money} Ω = {time delay}𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝑏𝑎𝑡𝑡.𝑐𝑜𝑛𝑠.(ti, pk,j)(mJ/Kbps)a 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑚𝑜𝑛𝑒𝑦.(ti, pk,j) ($/hour) 𝑁𝑒𝑡𝑡𝑖𝑚𝑒𝑡𝑖𝑚𝑒𝑑𝑒𝑙𝑎𝑦(ti, pk,j) (ms/KB) 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝑡𝑖𝑚𝑒𝑑𝑒𝑙𝑎𝑦(ti, pk,j) (ms)

Fog nodes 1 0.2143 250Cloudlet 1 0.256 0.4286 52MEC server 1.56 0.128 0.7812 52Cloud server 1.56b / 1c 0.064d 2.2177 50aEstimations from [57].bCloud server connection through mobile station.cCloud server connection through cloudlet.dOn-demand instance for t2.medium server (https://aws.amazon.com/ec2/spot/pricing/).

In this scenario, there exists a very dynamic nature of thecost matrix since it depends on the current workload of eachcomputer. In addition, the data must be moved to the targetcomputing platform, and therefore the communication costsare responsible for a relevant part of the total delay [45, 60].For example, Table 5(C) shows an estimated data at an instanttime.

As can be noted from the above data, the communi-cation costs are increasing with distance from outsourcingplatforms. In addition, fog and cloudlet layers can be into thesame Local Area Network (LAN) of the device or at a veryclose one. Of course, these costs depend on communicationtechnology used. For 5G technology the delay of MEC andcloud platforms will be significantly decreased.

Regarding computing delay, in general, the computingcosts of intermediate computing platforms and the cloudserver are significantly lower than those of the device itself.In this way, a decreasing computing cost must occur for themost of application tasks:

∀𝑝𝑘,𝑗 ∈ 𝐴𝑡𝑖𝑚𝑒𝑝0𝑖 ,𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ti, pk,j) < 𝐶𝑚𝑝𝑡𝑖𝑚𝑒𝛼 (ti, pk-1,j)

(24)

This consideration is quite frequent in environmentsdesigned for outsourcing of tasks from mobile devices orconnected “things.”

Table 5(C) shows the fact that fog nodes are limitedresourced platforms, but useful for reaching a fast responsein data operation. Another aspect taken into account is thatcloud servers are powerful platforms, but they are usuallypublic infrastructures used by many applications at once.Thus, their perceived performance is similar to MEC andcloudlet platforms.

Theremay be certain applicationsmore suited than othersto make the most of this model. Certainly, applicationscontaining intensive computing tasks will bemore candidatesto outsource than others;moreover, those tasks that require orproduce a large volume of data should be processed as closeas possible to the data sources to minimize communicationcosts.

5. Conclusions and Future Work

MCC is a recent paradigm with disruptive implications formobile computing and for the development of IoT and CPSadvanced applications. This paradigm promotes the QoS ofdevices and ‘things’ by outsourcing their computation tasksto external computing platforms.Themajority of proposals inMCC take into account only the cloud layer for outsourcingthe application workload. Another computing infrastructurehosted at different network layer is also being introducedrecently (cloudlets, fog nodes, etc.).

This work generalizes the idea of MCC paradigm tomultiple computing platforms at different network layers.The proposed model considers not only the cloud layer, butalso other network computing layers such as fog computing,Mobile Edge Computing, and cloudlet computing platforms.

To the best of our knowledge, this paper is the firstwork that extends the MCC paradigm to the availablecomputing layers by considering them in a comprehensiveand integrated fashion with the distributed architecture.To this end, a general framework of a multilayer networkarchitecture is described.The proposed model formalizes theprocessing of the application workload and the implicationsof the distributed configurations in the performance andin the communications needs. This model offers a versa-tile approach where different performance aspects can beconsidered within the same framework (time delay, powerconsumption, money, etc.). In this way, the proposal analyzesfrom a holistic perspective the technical aspects involved inMobile Cloud Computing paradigm taking into account thecontributions and results of the more recent works on thesetopics.

This framework enables decision making regardingscheduling the outsourcing of the applications tasks based onthe current and historical information of the systems. Severalexamples of these features have been described in three sce-narios where different performance aspects and computingplatforms are involved. Each of them is conditioned by itsuser preferences or device configurations. The results showthe versatility of the model to represent all the elementsinvolved.

In the future, this research can be extended to coverremaining challenges around this paradigm, for example, (a)

Complexity 11

the specification of the network topology and link capacityof the computing platforms along the network; (b) thedefinition of a middleware layer to drive the outsourcingprocess; (c) the introduction of discovery and broker services,and a suitable decision method for outsourcing; and (d)the design of mechanisms for collecting and disseminatingthe performance information, and the evaluation about theassociate cost for doing that. In any case, the extension of themodel can be made from the proposal of this work by addingnew modules and features.

Data Availability

The available data can be found in the references and webpages cited in the document.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported by the Spanish Research Agency(AEI) and the European Regional Development Fund(ERDF), under Project CloudDriver4Industry TIN2017-89266-R, and by the Conselleria de Educacion, Investigacion,Cultura y Deporte, of the Community of Valencia, Spain,within the program of support for research under ProjectAICO/2017/134.

References

[1] K. Li, “Optimal temporal partitioning of a multicore serverprocessor for virtual machine allocation,” IEEE Access, vol. 6,pp. 54726–54738, 2018.

[2] IDC, International Data Corporation’s Worldwide SemiannualPublic Cloud Services SpendingGuide,2018, Available online at:https://www.idc.com/getdoc.jsp?containerId=IDC P33214.

[3] N. Fernando, S. W. Loke, and W. Rahayu, “Mobile cloudcomputing: a survey,” Future Generation Computer Systems, vol.29, no. 1, pp. 84–106, 2013.

[4] H. Mora, D. Gil, J.-F. Colom-Lopez, and M. T. Signes-Pont,“Flexible framework for real-time embedded systems basedon mobile cloud computing paradigm,” Mobile InformationSystems, vol. 2015, Article ID 652462, p. 14, 2015.

[5] P. Nawrocki andW. Reszelewski, “Resource usage optimizationin Mobile Cloud Computing,” Computer Communications, vol.99, pp. 1–12, 2017.

[6] K. Akherfi,M. Gerndt, andH.Harroud, “Mobile cloud comput-ing for computation offloading: issues and challenges,” AppliedComputing and Informatics, vol. 14, no. 1, pp. 1–16, 2018.

[7] V. Haghighi and N. S. Moayedian, “An offloading strategyin mobile cloud computing considering energy and delayconstraints,” IEEE Access, vol. 6, pp. 11849–11861, 2018.

[8] M. Satyanarayanan, “Mobile computing: the next decade,” inProceedings of the ACM Workshop on Mobile Cloud Computing& Services: Social Networks and Beyond, 2010.

[9] U. Shaukat, E. Ahmed, Z. Anwar, and F. Xia, “Cloudlet deploy-ment in local wireless networks: Motivation, architectures,

applications, and open challenges,” Journal of Network andComputer Applications, vol. 62, pp. 18–40, 2016.

[10] H. Raei, N. Yazdani, and R. Shojaee, “Modeling and per-formance analysis of cloudlet in Mobile Cloud Computing,”Performance Evaluation, vol. 107, pp. 34–53, 2017.

[11] F. Mora-Gimeno, H. Mora-Mora, D. Marcos-Jorquera, and B.Volckaert, “A secure multi-tier mobile edge computing modelfor data processing offloading based on degree of trust,” Sensors,vol. 18, no. 10, Article ID 3211, 2018.

[12] E. Ahmed and M. H. Rehmani, “Mobile Edge Computing:Opportunities, solutions, and challenges,” Future GenerationComputer Systems, vol. 70, pp. 59–63, 2017.

[13] N. Abbas, Y. Zhang, A. Taherkordi, and T. Skeie, “Mobile edgecomputing: A survey,” IEEE Internet of�ings Journal, vol. 5, no.1, pp. 450–465, 2018.

[14] Y. Mao, C. You, J. Zhang, K. Huang, and K. B. Letaief, “A surveyon mobile edge computing: The communication perspective,”IEEE Communications Surveys & Tutorials, vol. 19, no. 4, pp.2322–2358, 2017.

[15] L. Gupta, R. Jain, and H. A. Chan, Mobile edge computing— an important ingredient of 5g networks. IEEE SoftwareDefined Networks, Newsletter. 2018, Available online at: http://sdn.ieee.org/newsletter/march-2016/mobile-edge-computing-an-important-ingredient-of-5g-networks.

[16] Y. Zhang, K. Wang, Y. Zhou, and Q. He, “Enhanced adaptivecloudlet placement approach for mobile application on spark,”Security and Communication Networks, vol. 2018, Article ID1937670, pp. 1–12, 2018.

[17] J. Pereira, L. Ricardo, M. Luıs, C. Senna, and S. Sargento,“Assessing the reliability of fog computing for smart mobilityapplications in VANETs,” Future Generation Computer Systems,vol. 94, pp. 317–332, 2019.

[18] O. Salman, I. Elhajj, A. Chehab, and A. Kayssi, “IoT survey: AnSDN and fog computing perspective,” Computer Networks, vol.143, pp. 221–246, 2018.

[19] D. Rosario, M. Schimuneck, J. Camargo et al., “Service migra-tion from cloud to multi-tier fog nodes for multimedia dissem-ination with QoE support,” Sensors, vol. 18, no. 2, 2018.

[20] H. Mora, M. Signes-Pont, D. Gil, and M. Johnsson, “Collabora-tive working architecture for IoT-based applications,” Sensors,vol. 18, no. 6, Article ID 1676, 2018.

[21] H. Mora, D. Gil, R. M. Terol, J. Azorın, and J. Szymanski, “AnIoT-based computational framework for healthcare monitoringinmobile environments,” Sensors, vol. 17, no. 10, Article ID 2302,2017.

[22] C. Long, Y. Cao, T. Jiang, and Q. Zhang, “Edge computingframework for cooperative video processing in multimedia IoTsystems,” IEEE Transactions on Multimedia, vol. 20, no. 5, pp.1126–1139, 2018.

[23] X. Fei, N. Shah, N. Verba et al., “CPS data streams analyticsbased on machine learning for Cloud and Fog Computing: Asurvey,” Future Generation Computer Systems, vol. 90, pp. 435–450, 2019.

[24] H. El-Sayed, S. Sankar, M. Prasad et al., “Edge of things: Thebig picture on the integration of edge, IoT and the cloud in adistributed computing environment,” IEEE Access, vol. 6, pp.1706–1717, 2017.

[25] J. I. Benedetto, L. A. Gonzalez, P. Sanabria, A. Neyem, and J.Navon, “Towards a practical framework for code offloading inthe Internet of Things,” Future Generation Computer Systems,vol. 92, pp. 424–437, 2019.

12 Complexity

[26] D. Kumar, G. Baranwal, Z. Raza, and D. P. Vidyarthi, “A surveyon spot pricing in cloud computing,” Journal of Network andSystems Management, vol. 26, no. 4, pp. 809–856, 2018.

[27] T. Wang, X. Wei, C. Tang, and J. Fan, “Efficient multi-tasksscheduling algorithm in mobile cloud computing with timeconstraints,” Peer-to-Peer Networking and Applications, vol. 11,no. 4, pp. 793–807, 2018.

[28] L. Liu, Q. Fan, and R. Buyya, “A deadline-constrained multi-objective task scheduling algorithm in mobile cloud environ-ments,” IEEE Access, vol. 6, pp. 52982–52996, 2018.

[29] J. Liu, Y. Mao, J. Zhang, and K. B. Letaief, “Delay-optimal com-putation task scheduling for mobile-edge computing systems,”in IEEE International Symposium on Information�eory (ISIT),2016.

[30] J. Zheng, Y. Cai, Y. Wu, and X. S. Shen, “Dynamic ComputationOffloading for Mobile Cloud Computing: A Stochastic Game-Theoretic Approach,” EEE Transactions on Mobile Computing,2018.

[31] Y. Li, M. Chen, W. Dai, and M. Qiu, “Energy optimizationwith dynamic task scheduling mobile cloud computing,” IEEESystems Journal, vol. 11, no. 1, pp. 96–105, 2017.

[32] D. Rahbari, M. Nickray, and G. Heydari, “A Two-Stage Tech-nique for Quick and Low Power Offloading in IoT,” in Proceed-ings of the international conference on smart cities and internetof things, 2018.

[33] P. P. Hung and E.-N. Huh, “An adaptive procedure for taskscheduling optimization in mobile cloud computing,” Mathe-matical Problems in Engineering, vol. 2015, Article ID 969027, p.13, 2015.

[34] A. Farahzadi, P. Shams, J. Rezazadeh, and R. Farahbakhsh,“Middleware technologies for cloud of things: a survey,” DigitalCommunications and Networks, vol. 4, no. 3, pp. 176–188, 2018.

[35] M. Aazam, S. Zeadally, and K. A. Harras, “Offloading in fogcomputing for IoT: Review, enabling technologies, and researchopportunities,” Future Generation Computer Systems, vol. 87, pp.278–289, 2018.

[36] H. Flores and S. N. Srirama, “Mobile cloud middleware,” �eJournal of Systems and So�ware, vol. 92, no. 1, pp. 82–94, 2014.

[37] R. Schneider, D. Goswami, A. Masrur, M. Becker, and S.Chakraborty, “Multi-layered scheduling of mixed-criticalitycyber-physical systems,” Journal of Systems Architecture, vol. 59,no. 10, pp. 1215–1230, 2013.

[38] R. Kemp, N. Palmer, T. Kielmann, and H. Bal, “Cuckoo: acomputation offloading framework for smartphones, MobileComputing,” in Int. Conf. on Mobile Computing, Applications,and Services (MobiCASE 2010), pp. 59–79, Springer, 2010.

[39] L. Jiang, L. D. Xu, H. Cai et al., “An IoT oriented data storageframework in cloud computing platform,” IEEE Transactions onIndustrial Informatics, vol. 10, no. 2, pp. 1443–1451, 2014.

[40] D. Wu, S. Liu, L. Zhang et al., “A fog computing-basedframework for process monitoring and prognosis in cyber-manufacturing,” Journal of Manufacturing Systems, vol. 43, pp.25–34, 2017.

[41] I. Farris, A. Orsino, L. Militano, A. Iera, and G. Araniti,“Federated IoT services leveraging 5G technologies at the edge,”Ad Hoc Networks, vol. 68, pp. 58–69, 2018.

[42] O. Osanaiye, S. Chen, Z. Yan, R. Lu, K.-K. R. Choo, andM. Dlodlo, “From cloud to fog computing: A review and aconceptual live VM migration framework,” IEEE Access, vol. 5,pp. 8284–8300, 2017.

[43] H. Flores, P. Hui, S. Tarkoma, Y. Li, S. Srirama, and R. Buyya,“Mobile code offloading: from concept to practice and beyond,”IEEE Communications Magazine, vol. 53, no. 3, pp. 80–88, 2015.

[44] D. Van Le and C.-K. Tham, “Quality of service aware computa-tion offloading in an ad-hoc mobile cloud,” IEEE Transactionson Vehicular Technology, vol. 67, no. 9, pp. 8890–8904, 2018.

[45] M. Kaya, A. Kocyigit, and P. E. Eren, “An adaptive mobile cloudcomputing framework using a call graph based model,” Journalof Network and Computer Applications, vol. 65, pp. 12–35, 2016.

[46] H. Mora, J. F. Colom, D. Gil, and A. Jimeno-Morenilla, “Dis-tributed computational model for shared processing on Cyber-Physical System environments,” Computer Communications,vol. 111, pp. 68–83, 2017.

[47] H. S. Narman, M. S. Hossain, M. Atiquzzaman, and H. Shen,“Scheduling internet of things applications in cloud comput-ing,” Annals of Telecommunications, vol. 72, no. 1-2, pp. 79–93,2017.

[48] A. Malik and H. Om, “Cloud computing and internet of thingsintegration: Architecture, applications, issues, and challenges,”in Sustainable Cloud and Energy Services, pp. 1–24, 2017.

[49] X. Chen, S. Chen, X. Zeng, X. Zheng, Y. Zhang, and C.Rong, “Framework for context-aware computation offloadingin mobile cloud computing,” Journal of Cloud Computing, vol.6, no. 1, 2017.

[50] N. Mohan and J. Kangasharju, “Edge-Fog cloud: A distributedcloud for Internet of Things computations,” in Cloudification ofthe Internet of �ings (CIoT), Paris, France, 2016.

[51] M. A. Khan, “A survey of computation offloading strategies forperformance improvement of applications running on mobiledevices,” Journal of Network and Computer Applications, vol. 56,pp. 28–40, 2015.

[52] N. Mohamed, J. Al-Jaroodi, I. Jawhar, S. Lazarova-Molnar, andS. Mahmoud, “SmartCityWare: A service-oriented middlewarefor cloud and fog enabled smart city services,” IEEE Access, vol.5, pp. 17576–17588, 2017.

[53] B. Cao, S. Xia, Y. Li, and B. Li, “An incentive-based workloadassignment with power allocation in ad hoc cloud,” in IEEEInternational Conference on Communications (ICC), pp. 1–6,Paris, France, 2017.

[54] Z. Lv, T. Yin, X. Zhang, H. Song, and G. Chen, “Virtualreality smart city based onWebVRGIS,” IEEE Internet of �ingsJournal, vol. 3, no. 6, pp. 1015–1024, 2016.

[55] T. Fernandez-Carames, P. Fraga-Lamas, M. Suarez-Albela, andM. Vilar-Montesinos, “A fog computing and cloudlet basedaugmented reality system for the industry 4.0 shipyard,” Sensors,vol. 18, no. 6, p. 1798, 2018.

[56] H. Li, H. Wang, A. Xiong, J. Lai, and W. Tian, “Comparativeanalysis of energy-efficient scheduling algorithms for big dataapplications,” IEEE Access, vol. 6, pp. 40073–40084, 2018.

[57] L. Zou, A. Javed, and G. Muntean, “Smart mobile device powerconsumption measurement for video streaming in wirelessenvironments: WiFi vs. LTE,” in Proceedings of the 2017 IEEEInternational Symposium on Broadband Multimedia Systemsand Broadcasting (BMSB), pp. 1–6, Cagliari, Italy, June 2017.

[58] E. Filiopoulou, P. Mitropoulou, C. Michalakelis, and M. Niko-laidou, “The rise of cloud brokerage: Business model, profitmaking and cost savings,” in International Conference on theEconomics of Grids, Clouds, Systems, and Services, LectureNotesin Computer Science, pp. 19–32, 2017.

[59] E. Casalicchio, V. Cardellini, G. Interino, and M. Palmirani,“Research challenges in legal-rule and QoS-aware cloud service

Complexity 13

brokerage,” Future Generation Computer Systems, vol. 78, pp.211–223, 2018.

[60] Y. Jararweh, L. Tawalbeh, F. Ababneh, A. Khreishah, and F.Dosari, “Scalable cloudlet-based mobile computing model,”Procedia Computer Science, vol. 34, pp. 434–441, 2014.

Hindawiwww.hindawi.com Volume 2018

MathematicsJournal of

Hindawiwww.hindawi.com Volume 2018

Mathematical Problems in Engineering

Applied MathematicsJournal of

Hindawiwww.hindawi.com Volume 2018

Probability and StatisticsHindawiwww.hindawi.com Volume 2018

Journal of

Hindawiwww.hindawi.com Volume 2018

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawiwww.hindawi.com Volume 2018

OptimizationJournal of

Hindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com Volume 2018

Engineering Mathematics

International Journal of

Hindawiwww.hindawi.com Volume 2018

Operations ResearchAdvances in

Journal of

Hindawiwww.hindawi.com Volume 2018

Function SpacesAbstract and Applied AnalysisHindawiwww.hindawi.com Volume 2018

International Journal of Mathematics and Mathematical Sciences

Hindawiwww.hindawi.com Volume 2018

Hindawi Publishing Corporation http://www.hindawi.com Volume 2013Hindawiwww.hindawi.com

The Scientific World Journal

Volume 2018

Hindawiwww.hindawi.com Volume 2018Volume 2018

Numerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisAdvances inAdvances in Discrete Dynamics in

Nature and SocietyHindawiwww.hindawi.com Volume 2018

Hindawiwww.hindawi.com

Di�erential EquationsInternational Journal of

Volume 2018

Hindawiwww.hindawi.com Volume 2018

Decision SciencesAdvances in

Hindawiwww.hindawi.com Volume 2018

AnalysisInternational Journal of

Hindawiwww.hindawi.com Volume 2018

Stochastic AnalysisInternational Journal of

Submit your manuscripts atwww.hindawi.com