Mobile Edge Computing - Hindawi Publishing...

Wireless Communications and Mobile Computing

Mobile Edge Computing

Lead Guest Editor: Robert HsuGuest Editors: Shangguang Wang, Anna Kobusinska, and Yan Zhang

Wireless Communications and Mobile Computing


Lead Guest Editor: Robert HsuGuest Editors: ShangguangWang, Anna Kobusinska,and Yan Zhang

Copyright © 2018 Hindawi. All rights reserved.

This is a special issue published in “Wireless Communications and Mobile Computing.” All articles are open access articles distributedunder the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, pro-vided the original work is properly cited.

Editorial Board

Javier Aguiar, SpainWessam Ajib, CanadaMuhammad Alam, ChinaEva Antonino-Daviu, SpainShlomi Arnon, IsraelLeyre Azpilicueta, MexicoPaolo Barsocchi, ItalyAlessandro Bazzi, ItalyZdenek Becvar, Czech RepublicFrancesco Benedetto, ItalyOlivier Berder, FranceAna M. Bernardos, SpainMauro Biagi, ItalyDario Bruneo, ItalyJun Cai, CanadaZhipeng Cai, USAClaudia Campolo, ItalyGerardo Canfora, ItalyRolando Carrasco, UKVicente Casares-Giner, SpainDajana Cassioli, ItalyLuis Castedo, SpainIoannis Chatzigiannakis, GreeceLin Chen, FranceYu Chen, USAHui Cheng, UKLuca Chiaraviglio, ItalyErnestina Cianca, ItalyRiccardo Colella, ItalyMario Collotta, ItalyMassimo Condoluci, SwedenBernard Cousin, FranceTelmo Reis Cunha, PortugalIgor Curcio, FinlandLaurie Cuthbert, MacauDonatella Darsena, ItalyPham Tien Dat, JapanAndré de Almeida, BrazilAntonio De Domenico, FranceAntonio de la Oliva, SpainGianluca De Marco, ItalyLuca De Nardis, ItalyAlessandra De Paola, ItalyLiang Dong, USA

Trung Q. Duong, SwedenMohammed El-Hajjar, UKOscar Esparza, SpainMaria Fazio, ItalyMauro Femminella, ItalyManuel Fernandez-Veiga, SpainGianluigi Ferrari, ItalyIlario Filippini, ItalyJesus Fontecha, SpainLuca Foschini, ItalyA. G. Fragkiadakis, GreeceSabrina Gaito, ItalyÓscar García, SpainManuel García Sánchez, SpainL. J. García Villalba, SpainJosé A. García-Naya, SpainMiguel Garcia-Pineda, SpainA.-J. García-Sánchez, SpainPiedad Garrido, SpainVincent Gauthier, FranceCarlo Giannelli, ItalyCarles Gomez, SpainJuan A. Gomez-Pulido, SpainKe Guan, ChinaDaojing He, ChinaPaul Honeine, FranceSergio Ilarri, SpainAntonio Jara, SwitzerlandXiaohong Jiang, JapanMinho Jo, Republic of KoreaShigeru Kashihara, JapanDimitrios Katsaros, GreeceMinseok Kim, JapanMario Kolberg, UKNikos Komninos, UKJuan A. L. Riquelme, SpainPavlos I. Lazaridis, UKTuan Anh Le, UKXianfu Lei, ChinaHoa Le-Minh, UKJaime Lloret, SpainMiguel López-Benítez, UKMartín López-Nores, SpainJavier D. S. Lorente, Spain

Tony T. Luo, SingaporeMaode Ma, SingaporeImadeldin Mahgoub, USAPietro Manzoni, SpainÁlvaro Marco, SpainGustavo Marfia, ItalyFrancisco J. Martinez, SpainDavide Mattera, ItalyMichael McGuire, CanadaNathalie Mitton, FranceKlaus Moessner, UKAntonella Molinaro, ItalySimone Morosi, ItalyKumudu S. Munasinghe, AustraliaEnrico Natalizio, FranceKeivan Navaie, UKThomas Newe, IrelandWing Kwan Ng, AustraliaTuan M. Nguyen, VietnamPetros Nicopolitidis, GreeceGiovanni Pau, ItalyRafael Pérez-Jiménez, SpainMatteo Petracca, ItalyNada Y. Philip, UKMarco Picone, ItalyDaniele Pinchera, ItalyGiuseppe Piro, ItalyVicent Pla, SpainJavier Prieto, SpainRüdiger C. Pryss, GermanyJunaid Qadir, PakistanSujan Rajbhandari, UKRajib Rana, AustraliaLuca Reggiani, ItalyDaniel G. Reina, SpainAbusayeed Saifullah, USAJose Santa, SpainStefano Savazzi, ItalyHans Schotten, GermanyPatrick Seeling, USAMuhammad Z. Shakir, UKMohammad Shojafar, ItalyGiovanni Stea, ItalyEnrique Stevens-Navarro, Mexico

Zhou Su, JapanLuis Suarez, RussiaVille Syrjälä, FinlandHwee Pink Tan, SingaporePierre-Martin Tardif, CanadaMauro Tortonesi, Italy

Federico Tramarin, ItalyReza Monir Vaghefi, USAJuan F. Valenzuela-Valdés, SpainAline C. Viana, FranceEnrico M. Vitucci, ItalyHonggang Wang, USA

Jie Yang, USASherali Zeadally, USAJie Zhang, UKMeiling Zhu, UK

Contents

Mobile Edge ComputingChing-Hsien Hsu , Shangguang Wang , Yan Zhang, and Anna KobusinskaEditorial (3 pages), Article ID 7291954, Volume 2018 (2018)

A Taxonomy for Management and Optimization of Multiple Resources in Edge ComputingKlervie Toczé and Simin Nadjm-TehraniReview Article (23 pages), Article ID 7476201, Volume 2018 (2018)

AIMING: Resource Allocation with Latency Awareness for Federated-Cloud ApplicationsJie Wei , Ao Zhou, Jie Yuan, and Fangchun YangResearch Article (11 pages), Article ID 4593208, Volume 2018 (2018)

Detection Performance of Packet Arrival under Downclocking for Mobile Edge ComputingZhimin Wang, Qinglin Zhao , Fangxin Xu, Hongning Dai , and Yujun ZhangResearch Article (7 pages), Article ID 9641712, Volume 2018 (2018)

Centralized Connectivity for Multiwireless Edge Computing and Cellular Platform: A Smart VehicleParking SystemAamir Shahzad , Jae-young Choi , Naixue Xiong , Young-Gab Kim , and Malrey LeeResearch Article (23 pages), Article ID 7243875, Volume 2018 (2018)

Data Processing Delay Optimization in Mobile Edge ComputingGuangshun Li , Jiping Wang , Junhua Wu , and Jianrong SongResearch Article (9 pages), Article ID 6897523, Volume 2018 (2018)

Method of Resource Estimation Based on QoS in Edge ComputingGuangshun Li , Jianrong Song , Junhua Wu , and Jiping WangResearch Article (9 pages), Article ID 7308913, Volume 2018 (2018)

Cloud/Fog Computing SystemArchitecture and Key Technologies for South-NorthWater TransferProject SafetyYaoling Fan , Qiliang Zhu, and Yang LiuResearch Article (6 pages), Article ID 7172045, Volume 2018 (2018)

Sample Selected Extreme Learning Machine Based Intrusion Detection in Fog Computing andMECXingshuo An, Xianwei Zhou, Xing Lü, Fuhong Lin , and Lei YangResearch Article (10 pages), Article ID 7472095, Volume 2018 (2018)

http://orcid.org/0000-0002-2440-2771http://orcid.org/0000-0001-7245-1298http://orcid.org/0000-0002-7300-3603http://orcid.org/0000-0002-1485-0802http://orcid.org/0000-0002-8888-7464http://orcid.org/0000-0003-4873-5631http://orcid.org/0000-0001-6165-4196http://orcid.org/0000-0001-7705-8778http://orcid.org/0000-0003-0265-545Xhttp://orcid.org/0000-0001-9671-7425http://orcid.org/0000-0002-0394-4635http://orcid.org/0000-0001-9585-8808http://orcid.org/0000-0002-1256-6795http://orcid.org/0000-0001-6147-0637http://orcid.org/0000-0003-3574-7510http://orcid.org/0000-0001-8723-2389http://orcid.org/0000-0002-6225-4482http://orcid.org/0000-0001-6147-0637http://orcid.org/0000-0002-6225-4482http://orcid.org/0000-0001-8723-2389http://orcid.org/0000-0003-3574-7510http://orcid.org/0000-0003-4126-3272http://orcid.org/0000-0002-1485-7908http://orcid.org/0000-0002-5287-5226

EditorialMobile Edge Computing

Ching-Hsien Hsu ,1 ShangguangWang ,2 Yan Zhang,3 and Anna Kobusinska4

1School of Mathematics and Big Data, Foshan University, China2Beijing University of Posts and Telecommunications, China3University of Oslo, Norway4Poznan University of Technology, Poland

Correspondence should be addressed to Ching-Hsien Hsu; [email protected]

Received 13 May 2018; Accepted 13 May 2018; Published 27 June 2018

Copyright © 2018 Ching-Hsien Hsu 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.

1. Introduction

The advent of mobile cloud computing has increased expec-tations for optimal and reliable services and support formobile users. The large pool of cloud resources and ser-vices has enabled the emergence of many novel applica-tions for smart environments. However, the state of theart of mobile cloud computing turns into a problem forcommunication-intensive applications, which need to meetthe delay requirements. The problem becomes even moreintense in smart cities or Internet of Things. Current cloudcomputing paradigm is unable to meet the requirements oflow latency, location awareness, and mobility support.

Mobile edge computing (MEC) is emerging as a verypromising computation architecture by pushing computationand storage closer to end users with both strategicallydeployed and opportunistic processing and storage resources.Such mechanism is essentially different from the traditionalcloud computing. MEC aims to enable millions of connectedmobile devices to execute the real-time applications directlyat the network edge. The distinguishing features of MECare its closeness to end users, mobility support, and densegeographical deployment of the MEC servers.

This special issue aims at presenting the current state-of-the-art research and future trends on various aspectsof mobile edge computing techniques for cloud-based IoTapplications and attempts to build highly adaptive smartenvironments that can automatically adapt behaviors to theamount of available resources.Themain areas covered by thisspecial issue or main topics cover methodologies, modeling,analysis, and newly introduced applications. Besides the

latest research achievements, this special issue also dealswith innovative commercial management systems, innova-tive commercial applications ofMEC technology, and experi-ence in applying recent research advances to real-world problems.

Papers selected for this special issue represent recentprogress in the field, including works on communicationtechnologies, cloud and fog computing, information security,mobile social networks, and machine learning. All of thesepapers not only provide novel ideas and state-of-the-arttechniques in the field, but also stimulate future research inthe sustainable environment.

2. Architecture and Resource Management

Recently, the edge computing paradigm has attracted interestfrom both industry and researchers, carrying the promise ofa new communication era in which industry can meet therising performance needs of future applications. The paperby K. Toczé and S. Nadjm-Tehrani, entitled “A Taxonomyfor Management and Optimization of Multiple Resources inEdge Computing”, presented terminology and architecturesto characterize current works within the field of edge com-puting. This work reviews a wide range of recent articlesand categorizes relevant aspects in terms of resource type,objective of resource management, resource location, andresource use. The authors tried to provide an overview, notfrom a cloud perspective or an IoT device perspective butwith a focus on edge resource management. Taxonomy andanalysis of this paper can be used to identify some gaps in theexisting research.

HindawiWireless Communications and Mobile ComputingVolume 2018, Article ID 7291954, 3 pageshttps://doi.org/10.1155/2018/7291954

http://orcid.org/0000-0002-2440-2771http://orcid.org/0000-0001-7245-1298https://doi.org/10.1155/2018/7291954

2 Wireless Communications and Mobile Computing

The paper by J. Wei et al., entitled “AIMING: ResourceAllocation with Latency Awareness for Federated-CloudApplications”, proposed a novel resource allocation approachfrom the perspective of application providers with differ-ent types of resources taken into consideration, aiming tominimize the latency constrained by monetary overhead inthe context of federated-cloud. The network resources aredeployed and selected according to k-means clustering. Thetotal latency among data-centers is optimized under the con-straint of budget based on binary quadratic programming.Experimental results show that the classification is moreaccurate and effective than graph theory.

Aiming at QoS and user satisfaction, the paper by G.Li et al., entitled “Method of Resource Estimation Based onQoS in Edge Computing”, uses weighted Euclidean distancesimilarity to classify multiple QoS attribute resources andregression-Markov chain prediction method to analyse thechange of the load state of the candidate resources. Penaltyfactor and Grey incidence matrix for improving accuracyof similarity matching were introduced. Effectiveness ofthe matching method was validated through simulation.The authors proved that regression-Markov chain predictionmethod can improve the prediction accuracy.

3. Performance Monitoring and Security

In mobile edge computing, edge nodes access resources andservices via application servers such as LTE base stationand wireless access point. The paper by Z. Wang et al.,entitled “Detection Performance of Packet Arrival underDownclocking for Mobile Edge Computing”, investigated anovel downclocking technique for low-powerWiFi networks.Thiswork theoretically studied the crucial impact of tolerancethreshold, correlation threshold, and energy ratio thresholdon the packet detection performance. Extensive Monte Carloexperiments show that the proposed theoreticalmodel is withhigh accuracy. This study can help system developers setreasonable system parameters for WiFi downclocking.

With the development of Internet of Things (IoT), theamount of data transmission shows a trend of exponentialincrement.The paper by G. Li et al., entitled “Data ProcessingDelay Optimization in Mobile Edge Computing”, proposeda three-layer network model, which combines cloud com-puting and edge computing. In edge computing layer, acomputational scheme of mutual cooperation between theedge devices was presented to reduce the communicationdelay. In cloud computing layer, a balanced transmissionmethod to solve the data transmission delay from edgedevices to cloud servers was introduced. Experimental resultsshow that the proposed architecture can effectively reducedata processing delay and perform better than both the singleedge node and traditional cloud computing.

Because there aremany attacks against the fog computingnetwork, to effectively handle security threats in fog comput-ing system, the paper byX.An et al., entitled “Sample SelectedExtreme Learning Machine Based Intrusion Detection inFog Computing and MEC”, proposed a new lightweightintrusion detection system, called Sample Selected ExtremeLearning Machine. In the proposed architecture, classifiers

are deployed on fog nodes for intrusion detection. Trainingdata sets are stored in the cloud server, so that fog nodes donot need to handle large amounts of data sets. In addition,sample selection process is performed in the training phase inorder to improve the classifier algorithm so that it can becomemore lightweight. Experimental results verified that theproposed architecture performswell in intrusion detection interms of accuracy and training time.

4. Tools and Applications

Water conservancy engineering presents the national fun-damental industry and is vital in national economic devel-opment. The construction of water conservancy projects isgenerally large in scale, with high investment, wide geograph-ical distribution, and decentralized management and in along construction period and contains a large amount ofinformation. The paper by Y. Fan et al., entitled “Cloud/FogComputing System Architecture and Key Technologies forSouth-North Water Transfer Project Safety”, proposed a newsafety system architecture for water conservancy engineeringbased on cloud/fog computing. The proposed architectureconsidered project safety, water quality safety, and humansafety. Using IoT devices, fog computing layer was con-structed between cloud server and safety detection devicesin water conservancy projects. Technologies such as real-time sensing, intelligent processing, and information inter-connectionwere developed.The IoT big data in water conser-vancy engineering with dense geographical distribution wereapplied based on multilevel requirements and integrated intoa resource integration platform for deployment.

The smart parking system is considered as an importantpart of the smart city, where many advanced technologiessuch as the Internet of Things have been ubiquitously de-ployed in various sectors. The paper by A. Shahzad et al.,entitled “Centralized Connectivity for Multiwireless EdgeComputing and Cellular Platform: A Smart Vehicle ParkingSystem”, aims to manage massive crowd of vehicles andprovide better performance for parking searching, reserva-tion, and management. This study comprised several park-ing points systematically spread over several locations andtraceable over the available graphical map, and the overallinformation is easily accessible using smart devices. Theproposed architecture is a novel solution for deployingautomated smart vehicle parking system.

5. Conclusions

All of the above papers address either technical issues in com-munication technologies or information security or proposenovel applicationmodels in the various cloud/fog andmobilecomputing fields. They also trigger further related researchand technology improvements in application of mobile edgecomputing. Honorably, this special issue serves as a land-mark source for education, information, and reference toprofessors, researchers, and graduate students interested inupdating their knowledge of cloud, mobile edge computing,Internet of Things, and novel application models for futureinformation services and systems.

Wireless Communications and Mobile Computing 3

This special issue of this journal covers different aspects ofthe problem, from both the theoretical and the practical side.After a large open call, an international editorial committeeselected eight research papers. Each paper was reviewed by atleast 3 reviewers.

Acknowledgments

The guest editors are deeply indebted to numerous reviewersfor their professional effort, insight, and hard work put intocommenting on the selected articles that reflect the essenceof this special issue. We are grateful to all authors for theircontributions and for undertaking two-cycle revisions oftheir manuscripts, without which this special issue could nothave been produced.

Ching-Hsien HsuShangguang Wang

Yan ZhangAnna Kobusinska

Review ArticleA Taxonomy for Management and Optimization ofMultiple Resources in Edge Computing

Klervie Toczé and Simin Nadjm-Tehrani

Department of Computer and Information Science, Linköping University, Linköping, Sweden

Correspondence should be addressed to Klervie Toczé; [email protected]

Received 16 November 2017; Revised 11 March 2018; Accepted 17 April 2018; Published 4 June 2018

Academic Editor: Anna Kobusinska

Copyright © 2018 Klervie Toczé and Simin Nadjm-Tehrani.This is an open access article distributed under the Creative CommonsAttribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work isproperly cited.

Edge computing is promoted to meet increasing performance needs of data-driven services using computational and storageresources close to the end devices at the edge of the current network. To achieve higher performance in this new paradigm, onehas to consider how to combine the efficiency of resource usage at all three layers of architecture: end devices, edge devices, andthe cloud. While cloud capacity is elastically extendable, end devices and edge devices are to various degrees resource-constrained.Hence, an efficient resource management is essential to make edge computing a reality. In this work, we first present terminologyand architectures to characterize current works within the field of edge computing. Then, we review a wide range of recent articlesand categorize relevant aspects in terms of 4 perspectives: resource type, resource management objective, resource location, andresource use.This taxonomy and the ensuing analysis are used to identify some gaps in the existing research. Among several researchgaps, we found that research is less prevalent on data, storage, and energy as a resource and less extensive towards the estimation,discovery, and sharing objectives. As for resource types, the most well-studied resources are computation and communicationresources. Our analysis shows that resource management at the edge requires a deeper understanding of how methods applied atdifferent levels and geared towards different resource types interact. Specifically, the impact of mobility and collaboration schemesrequiring incentives are expected to be different in edge architectures compared to the classic cloud solutions. Finally, we findthat fewer works are dedicated to the study of nonfunctional properties or to quantifying the footprint of resource managementtechniques, including edge-specific means of migrating data and services.

1. Introduction

Recently, the edge computing paradigm, which consistsin having network nodes with computational and storageresources close to the devices (mobile phones, sensors) atthe edge of the current network, has attracted interest fromboth industry and researchers, carrying the promise of a newcommunication era in which industry can meet the risingperformance needs of future applications.

Indeed, with a forecast of 9 billion mobile subscriptionsin the world by 2022, of which 90% will include mobilebroadband, coupled to an eightfold increase in mobile trafficand 17.6 billion of Internet of Things (IoT) devices alsosending data [1], there will be a considerable strain put on thenetwork.The current network technologies need to undergo aparadigm shift in order to handle this situation [2].Therefore,

the aim is to avoid overwhelming the network up to thecloud and, when possible, move some computing and dataanalysis closer to the users to enable better scalability [3].Thus, the main idea of edge (or fog) computing is to haveintermediate computing facilities between the end devicesand the current cloud. As suggested by Mehta et al. [4], thiswould also enable the current telecom network operators toreduce their operational costs.

In addition to this, moving computing and storage to theedge of the network has other benefits [3] such as reducingthe latency and jitter [5], which is especially important forreal-time applications such as self-driving cars. Moreover, itenables more privacy for the users by making it possible tokeep private data at the edge and enforce privacy policies forthe data sent to the cloud (such as blurring sensitive info ona video [2]). Finally, edge networking makes the applications

HindawiWireless Communications and Mobile ComputingVolume 2018, Article ID 7476201, 23 pageshttps://doi.org/10.1155/2018/7476201

http://orcid.org/0000-0002-7300-3603http://orcid.org/0000-0002-1485-0802https://doi.org/10.1155/2018/7476201


more resilient by being able to process requests at the edgeeven if the central cloud is down.

In order to achieve this and to make edge computinga reality and a success, there is a need for an efficientresource management at the edge. Indeed, mobile devicesor IoT devices are resource-constrained devices, whereasthe cloud has almost unlimited but far away resources.Providing and/or managing the resources at the edge willenable the end device to spare resources (e.g., stored energyin batteries) and speed up computation and allows usingresources it does not possess. Moreover, keeping data closeto where it was generated enables better control, especiallyfor privacy-related issues. Finally, being located close to theuser, edge computingmakes it possible to increase the qualityof provided services through the use of profiling within alocal context, without compromising the privacy or havingto handle a large number of users. This is known as contextadaptation.

Even though this is still an emerging research area, there isa lot of work ongoing under different denominations includ-ing mobile cloud computing [6], fog computing [7], edgecomputing [3], mobile edge computing [8], path computing[9], mobile edge cloud [10], mobile edge network [4], infinitecloud [11], follow-me cloud [12], mobile follow-me cloud[13], multitier cloud federations [14], small cell cloud [15],fast moving personal cloud [16], CONCERT [17], distributedclouds [18], and femtoclouds [19, 20].

Independently of the terminology chosen, which mightfollow the current naming trend, a common concept here isan intermediate level between the device and the traditionalcloud. It is possible to find in the literature numerous surveysabout those paradigms in general [6, 10, 21–25], specificaspects of them such as security [8, 26], or specific techniquessuch as Software-Defined Networking (SDN) [27]. However,those typically do not consider the resource aspect. Theexisting surveys about resources either consider it at a highlevel [28] or consider only resource/service provisioningmetrics [29].

One area that is of high importance and is present inmany use-cases in edge computing is offloading. This is theidea of executing a task on a device other than the currentexecution target. This other device has typically more pow-erful computational capacities or fewer energy constraints.Resource management is tightly connected to offloadingsince in order to take a decision to offload, one needs tohave knowledge about system resources. This knowledge isprovided by resource management techniques. For example,resource discovery can be used as an input for taking anoffloading decision, while resource allocation techniques canbe used to perform the offloading decision. To the best of ourknowledge, existing surveys about resource management foroffloading at the edge focus on an end device perspective [30,31], on the resource allocation part of resource management[32, 33], or on a single-user/multiuser perspective [34].

We aim to complement those surveys by providing amorecomprehensive perspective.That is, (a)we consider allocationas one among five resource management objectives, (b) weconsider edge resources in addition to end device or cloudresources, (c) we address multiple types of resources and

interrelations amongst them, and (d) we review aspectsrelated to locality and what the resource is intended for.

In selecting the survey papers, works considering directinteractions from a device to a cloud [35] or focusing on cloudperformance by offloading to the edge [36] are not consid-ered. However, offloading between edge devices or from theedge to the cloud when edge resources are also consideredis included. All included papers consider the notion of edgewhich we attempt to characterize by defining edge-specificarchitectural instances. This will be done independently ofthe terminology the authors chose to use. This paper is asubstantial extension of our previous much shorter review[37].

In the remaining parts of this paper, we will first presentthe terminology used, define edge-specific architectures, andpresent the proposed taxonomy in Section 2. The taxonomyis then exemplified by an extensive review of papers, whichare categorized using the taxonomy elements introduced,namely, resource type (Section 3), resource managementobjective (Section 4), resource location (Section 5), andresource use (Section 6). We then discuss research challengesin Section 7 and conclude the paper in Section 8.

2. Architectures and Research Taxonomy

Edge computing is an innovative area bringing togetherdiverse business sectors such as telecommunication actors,vehicle vendors, cloud providers, and emerging applicationor device providers, for example, for augmented reality.Therefore, the terminology used in research works is diverseand is still evolving andmultiple architectures are considered.

In this section, we present first the relevant terminologyassociated with edge computing which will be used in therest of the paper. Then, we discuss the current architecturesused and present an architectural breakdown that will bethe basis for classifying existing research. Finally, we presentour proposed research taxonomy and use it to classify thesurveyed works.

2.1. Terminology. Following the development of the IoT, it isnowadays not only computers or smartphones which can beconnected to the network but also a large variety of thingssuch as cars, sensors, drones, robots, or home appliances. Inthis survey, all those objects located at the user end of thenetwork which produce data or need cloud/edge resourceswill be called end devices.

Devices installed at the edge specifically for edge comput-ing purposes are called edge devices. We also include underthis term the devices that are already now connecting the enddevices to the rest of the network, for example, home routers,gateways, access points, or base stations, which are becomingincreasingly powerful [38].

Finally, physical components of the cloud are referred toby the term cloud devices.

We use those network device classifications to createdifferent levels in the network: the device level, the edge level,and the cloud level. Resources that are managed are used toperform tasks at some level of the architecture. These can becomposed to provide a service to the user.


2.2. Current Status of Edge Architectures. There is currentlyno standard architecture for edge computing, although in-dustry and research initiatives exist, such as the Open EdgeComputing (http://openedgecomputing.org/) community,the Open Fog Consortium (https://www.openfogconsortium.org/), and a European Telecommunications Standards Insti-tute (ETSI) standardization group working on MultiaccessEdge Computing (http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing). Current stan-dardization efforts coming from the ETSI group have beenreviewed in detail by Mao et al. [34] and Mach and Becvar[33]. Mao et al. [34] also present edge standardization effortswithin the 5G standard.

Therefore, current research on edge computing is usingseveral different architectures and there is ongoing workfor defining edge computing architectures. Recent surveysfocus on presenting these architectures. For example, Liu etal. [10] review different architectures for mobile edge cloudservers and networks, and Mach and Becvar [33] present anoverview of proposed solutions enabling computation to bebrought close to the end device within the field of mobileedge computing. The approach chosen by Mouradian et al.[39] is to classify the architectures depending on whetherthey are application-specific or not. They also elaborate onarchitectural challenges according to 6 criteria includingscalability and heterogeneity. Our classification of the devicetypes above is consistent with all the surveys on architectureso far.

2.3. Used Breakdown of Architectures. In this survey, wechoose to classify the different architectures into three maincategories inspired by the work of Mtibaa et al. [40] andpresented in Figure 1. Those categories are technology-independent and aim at visualizing three high-level variantsof the edge computing concept that the current works areusing.

The first category, named edge server and depicted in Fig-ure 1(a), is a generic architecture, where devices are connectedto an edge server, which itself is connected to the rest of thenetwork, including the cloud. In this type of architecture, theedge server is at a fixed physical location and has relativelyhigh computational power, though it remains less powerfulthan a conventional data center used in the cloud computingparadigm. Moreover, there is a clear separation between thedevice level and the edge level. In the literature, such edgeservers are named, for example, cloudlets [41, 42], micro datacenters [43, 44], nano data centers [45], or local cloud [46].They can be located, for example, in shops and enterprisesor colocated with the base stations of the telecom accessnetwork. Indeed, in the ongoing work on what the fifthgeneration (5G) of telecommunication networks will looklike, a cloud radio access network (C-RAN) is envisaged[47, 48], with connections to other edge computing areas suchas mobile cloud computing [49].

The second category, named coordinator device anddepicted in Figure 1(b), is an architecture, where one enddevice acts as a coordinator between the other end devices.It also acts as a proxy towards an edge device and/or thecloud if such connectivity is needed.The difference between a

coordinator device and an edge server is that the coordinatordevice can be mobile and has less computational power andbandwidth than an edge server. In this architecture category,the border between the device level and the edge level isnot a sharp one, as the coordinator level providing edgefunctionality is actually an end device. Solutions using thiscategory of architecture are named, for example, fog colonieswith a control node [50], vehicular clouds with a cluster head[51], and local clouds with a local resource coordinator [52].It is interesting to note here that the term local cloud, whichwas already used for describing a part of the edge serverarchitecture category described in the previous paragraph, isused to describe various architectural solutions, illustratingwell the fact that the terminology used in edge computing isnot yet set.

The last category, named device cloud and depicted inFigure 1(c), is an architecture, where the end devices commu-nicate with each other to find needed resources and deliverthe wanted services.The devices might communicate with anedge device connected to the cloud if needed but this is notnecessary. In this architecture category, the device level andthe edge level are thus merged. Research works consideringthis category of architecture call it opportunistic computing[53], cooperation-based mobile cloud computing [54, 55], ortransient clouds [56].

While all these architectures need to be populated withdedicated resourcemanagement elements, there is no generalagreement about where to place the needed policies. A recentproposal for a generic software architecture that encompassesthe edge server version in Figure 1(a) is an enabler forevaluation of multiple resource management policies withincommon testbeds [57].

2.4. Taxonomy of Edge Resource Management. In addition toclassifying the reviewed papers according to the architecturecategory they consider, we also present a taxonomy ofresource management at the edge. This taxonomy, illustratedin Figure 2, aims at getting an overview of state-of-the-artresearch in this area and presents four main aspects: resourcetype, objective of resource management, resource location,and resource use.

The two first aspects were constructed by reviewing thecurrent type of resources used and the objective for which theyare used in the literature. The two last aspects are based onmutually exclusive pairs for describing the resource locationand the use of the resource.

In the coming sections, wewill describe the different partsof the taxonomy and how the surveyed works can be placedin the four above contexts, as well as the architectural modelsdescribed.

3. Resource Type

The first step in evaluating the benefit of an edge solution isto decide what are the resource types that can be managed ina better way compared to a centralized system.

An obvious justification for using edge architectures isreducing the response time, which can be done if com-putation and communication resources are provided and

http://openedgecomputing.org/https://www.openfogconsortium.org/https://www.openfogconsortium.org/http://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computinghttp://www.etsi.org/technologies-clusters/technologies/multi-access-edge-computing


Cloud level

Edge level

Device level

Cloud devices

Edge device

Enddevice

(a) Edge server

Cloud level

Edge level

Device level

Cloud devices

Edge device

Edge andend device

Enddevice

(b) Coordinator device

Cloud level

Edge levelDevice level

Cloud devices

Edge device

C

Enddevice

(c) Device cloud

Figure 1: Categories of architectures used in edge computing.

used adequately. Storage as a resource is also a concern,since local storage may benefit security or timeliness dueto customized fetching and secure storing mechanisms. Aless obvious type of resource is having access to a specialtype of data (e.g., availability of sensors) that provides localbenefits in an application. Examples are the use of camerasor location sensors. The amount and type of data capturedin turn affect computation and communication resources(how often to shuffle data and how much to process or filterbefore shuffling) and implicitly the choice of where and how

much of other resources to deploy. The fifth category weconsider is energy as a resource, which is clearly influencedby the amount of computation, communication, storage, anddata capturing that goes on. Finally, some works considerresources in a generic way using abstract terms such as“Virtual Resource Value” or just as unitless elements in amodel.

Table 1 summarizes the surveyed papers in terms of theirmapping to the architectural choices in Figure 1. It also showswhich resource is focused onwithin eachwork, either specific


Resource management at the edge

Resource type Objective Resourcelocation Resource use

Computation

Communication

Storage

Data

Energy

Generic

Resourceestimation

Resourcediscovery

Locallycentralized

Distributed

Resourceallocation

Withinarchitecture

Functionality inapplication

Placement

Migration

Scheduling

Single level

Multilevel

Application-specific

Application-agnostic

Resourcemobility

Nonfunctionalproperties

Resourcesharing

Stationary

Mobile

Dynamiccoalitions

Staticcoalitions

Resourceoptimization

Figure 2: A taxonomy of resource management at the edge.

or generic. As it can be seen, the vast majority of the surveyedarticles focus on several resources.Therefore, this section willpresent the common combinations of resources describedabove and presented in Figure 2.

3.1. Single Resource Focus. Even though the majority of thesurveyed papers choose to focus on several resources, somepapers focus on only one resource type. We present thosepapers in this subsection and then move on to multiresourcecases.

3.1.1. Generic. When focusing on a single resource type, mostof the works use a generic one, which is used as an abstractionfor actual resources.

The abstraction used varies in various articles. For exam-ple, Penner et al. [56] work with device capabilities as anabstraction when proposing resource assignment algorithms.Other works, such as Aazam et al. [43, 58], define a newconceptual unit. “Virtual Resource Value” is the unit forany resource, which is then mapped to physical resourcesaccording to the type of service and current policies of thecloud service provider.

Sometimes the abstraction is at an even higher level:Wang et al. [77] use generic cost functions that can be usedto model many aspects of performance such as monetary

cost, service access latency, amount of processing resourceconsumption, or a combination of these. When proposing amethod for online service placement, they, however, analyzeits performance for a subset of cost functions related toresource consumption with the claim that this subset is stillgeneral.

3.1.2. Energy. Some works focus solely on energy, which isespecially important at the edge since devices, in particularend devices, are often resource-constrained. For example,Mtibaa et al. [83] perform offloading between end devices inorder to maximize the group lifetime.

Still considering only energy but with another perspec-tive, Borylo et al. [65] classify data centers in two categories(green and brown depending on which source of energy theyuse) and then use a latency-aware policy to choose a datacenter for serving a request.

3.1.3. Other. There are works that consider a minimumcomputational resource unit per device. For example, Frickeret al. [69] use servers as an abstraction (one request occupiesone server).

Data as a resource, in addition to sensor data mentionedearlier, can also be seen as content. Gomes et al. [13] proposean algorithm for content migration at the edge, together


Table 1: Surveyed articles according to architecture category from Figure 1 and resource type.

Article Computation Communication Storage Data Energy Generic

Edge server

Liu et al. [59] � �Confais et al. [60] � �Aazam et al. [43] �Arkian et al. [61] � � �

Aazam and Hu [58] �Fan et al. [62] � �Oueis [63] � � �

Tang et al. [64] � �Borylo et al. [65] �

Yousaf and Taleb [48] � � �Wang et al. [49] � �Gu et al. [66] � � �

Tärneberg et al. [67] � �Plachy et al. [68] � �Gomes et al. [13] �Fricker et al. [69] �

Rodrigues et al. [70] � �Zhang et al. [71] � �

Bittencourt et al. [72] � �Zamani et al. [73] � �Valancius et al. [45] � � �Chen and Xu [74] � � �Wang et al. [75] � � �Yi et al. [76] � �

Wang et al. [77] �Sardellitti et al. [78] � � �Singh et al. [44] � �

Coordinator device

Nishio et al. [52] � � � �Skarlat et al. [50] � � � �Borgia et al. [79] � � �

Athwani and Vidyarthi [80] � � �Arkian et al. [51] � � �Penner et al. [56] �Bianzino et al. [81] � �Habak et al. [20] � � �

Device cloud

Liu et al. [54] � �Mascitti et al. [53] � �Liu et al. [55] � �

Meng et al. [46] � �Qi et al. [82] � �

Mtibaa et al. [83] �

with mobility prediction as an enabler within their newmobile follow-me cloud architecture. This work builds uponthe initial follow-me cloud proposal by Taleb and Ksentini[12].

3.2. Multiple Resource Focus. All other surveyed articles arefocusing on multiple resource types. In this section, wegroup the papers according to the different combinations ofresources they consider.

3.2.1. Computation and Communication. The most commoncombination of resource types studied is computational andcommunicational resources together. Thus, we begin byconsidering works that study this combination and in onecase together with data.

Liu et al. [59] considerwireless bandwidth and computingresource when deciding to handle a request either in acloudlet or in the cloud. Another example is the work byBittencourt et al. [72], who consider bandwidth between the


cloud and cloudlet, as well as cloudlet processing capabilitieswhen evaluating different scheduling strategies.

Computational resources can be addressed at a physicallevel, for example, discussing CPU cycles, or at a conceptuallevel, for example, use of virtual machines (VMs) as resourceelements. In the surveyed articles, Wang et al. [49] considerCPU cycles, Singh et al. [44] considerMillions of Instructionsper Second (MIPS), and Rodrigues et al. [70] consider thenumber of processors per cloudlet. At a conceptual level,Zamani et al. [73] consider different computing resourcesbased on the average number of tasks completed per unit oftime, and Plachy et al. [68] allocate computational resourcesin the form of VMs.

Sometimes the VMs are used as a means to ensure that atask can run given enough underlying resources in the devicehosting the VM, for example, in the work by Tärneberg et al.[67].

Instead of using VMs, Yi et al. [76] adopt lightweight OS-level virtualization and a container technique, arguing thatresource isolation can be provided at a much lower cost usingOS-level virtualization. They also pinpoint that the creationand destruction of container instances are much faster andthus enable the deployment of an edge computing platformwith minimal efforts.

As in Section 3.1.3, some works consider a minimumresource unit that corresponds to a device. For example,Meng et al. [46] consider one vehicle as the minimal comput-ing resource unit. Vehicles are aggregated in a resource pooltogether with communication resources and resource unitsfrom the cloud and the edge.

Communication power needed can be considered as apart of the cost when sharing resources [64]. In contrast,communication can be characterized by a delay term impact-ing the task completion time, like [44, 53, 73].

Finally, Habak et al. [20] consider computation, commu-nication, and data in femtoclouds. The data considered givesinformation about task dependencies in order to determinein which order the tasks need to be executed and which onescan be run in parallel.

3.2.2. Computation, Communication, and Storage. Otherworks, in addition to the computation and communicationresource types, also include storage in their study.

For example, Arkian et al. [51] tackle resource issuesin vehicular clouds by considering all three resource types.Elsewhere, crowdsensing is tackled with the same resourceconsiderations [61].

Another example is the work by Skarlat et al. [50],where they model service demands and a specific kind ofresource (sensor data) as well as the computational andstorage resources. In this work, communication is consideredas a delay term.

VMs can also be considered as an encapsulation of theabove three resources in methods that ensure the underlyingresources in the device hosting the VM are adequate [66].

Still considering virtualization, Wang et al. [75] pro-pose a system architecture where applications’ requests con-tain computing complexity and storage space requirements.Those requirements are then translated by a SDN controller

node into computing power requirements, bandwidth vol-umes, or requirements on security groups. When trying toallocate more computing and bandwidth resources in anemergency situation, their system will do it by creating newVMs.

Finally, in addition to considering computation, com-munication, and storage, Yousaf and Taleb [48] emphasizethe fact that different resources should not be considered inisolation as there are interactions between them. Thus, theydescribe and use the concept of resource affinity in theirscheme.

3.2.3. Computation, Communication, and Energy. Anothercombination studied by several of the surveyed articles iscomputation, communication, and energy resource types.

Athwani and Vidyarthi [80] aim at making resourcediscovery energy-efficient in order to save battery. Nishio etal. [52] consider energy efficiency in their algorithms but at amore general level, without battery life considerations.

Oueis [63] focuses on energy-efficient communicationwith the aim of minimizing the communication powerneeded. Similarly, when studying edge collaboration in ultra-dense small base stations networks with trust considerations,Chen and Xu [74] consider computing (CPU cycles persecond), communication as radio-access provisioning, andenergy used for both transmission and computation.

Sardellitti et al. [78] propose an algorithmic frameworkto solve the joint optimization problem of radio and com-putational resources with the aim of minimizing the overallenergy consumption of the users while meeting latencyconstraints. They first present a solution for the single-usercase and then consider the case of offloading with multiplecells in a centralized and a distributed manner.

When considering energy as a resource, a comprehen-sive discussion of interactions between multiple actions ismapped to energy apportionment policies by Vergara et al.[84]. However, since this work considers edge-/cloud-specificapportionments as one amongmany application areas, that is,addresses energy sharing in a much wider context, we do notfurther consider it in our classifications.

3.2.4. Combinations Including Generic Resources. We nowconsider generic resources in association with other resourcetypes, such as energy or communication.

First, Liu et al. [54] consider abstract tasks and resourcesto address energy efficiency. They switch between a central-ized and a flooding mode depending on energy consumptionwhile keeping the expected value of RIA (Resource Informa-tion Availability), which is their quality metric. Qi et al. [82]choose to abstract resources as services and consider energyconsumption in the end device when taking an offloadingdecision.

Regarding communication, Liu et al. [55] use the notionof generic resource (when referring to a combination ofbandwidth and CPU available for sharing) as well as concretebandwidth when nodes are at contact range. Borgia et al.[79] consider data-centric service providers having storage,computing, and networking capabilities but in their evalua-tion abstract away the storage and computing resources by


only considering the extent to which services are waiting forresources on the provider side.

3.2.5. Other Combinations. Not all works considering com-putation also consider communication. Less common com-binations including computational resources are those withenergy and data.

With regard to energy, Fan et al. [62] present a virtualmachine migration scheme that aims at using as much greenenergy as possible in the context of green cloudlet networks.

Data and computation are the focus of Zhang et al. [71]who studied distributed data sharing and processing in orderto use data coming from different stakeholders for new IoTapplications and propose a new computing paradigm calledFirework.

Less common combinations including communicationresources include storage and energy resource types.

Confais et al. [60] present how a storage service can beprovided for fog/edge infrastructure, based on the InterPlan-etary File System, and scale-out network-attached systems.Their aim is to propose a service similar to the Amazon Sim-ple Storage Service solution (https://aws.amazon.com/fr/s3/)for the edge.

Adding energy to storage and communications resources,Valancius et al. [45] consider energy-efficient algorithmswhen introducing a new distributed data center infrastruc-ture for delivering Internet content and services.

Finally, Bianzino et al. [81] study the trade-off betweenbandwidth and energy consumption when an end devicehas access to multiple networking interfaces and can switchbetween them. They aim at energy efficiency but use anabstract model of power usage based on the amount of databeing shuffled.

3.3. Summary of Resource and Architecture Choices. In thissection, we have presented the surveyed articles dependingon their resource focus. Examining the collection of papersabove, resource studies so far seem to focus on computationand communication resources to a greater extent. Moreover,data as a resource is a potential not extensively explored.Similarly, energy is underrepresented among resources stud-ied.

Furthermore, it is noticeable that storage is not the mainfocus of attention. It could be due to the fact that the cloudis available as a fall-back in many cases. It could also bethe case that persistent data storage is not the main focusof most of the applications considered at the edge. Rather,the service or completed task is the main purpose. Anotherreason could be that presently there are not many critical usecases with latency-constrained storage, but this may changewhen more and more IoT devices appear in the field. Analternative explanation could be that the authors choose tofocus on a reduced set of resources for ease of presentationthinking that the work can be extended to other resourcessuch as storage. Such claims, however, have to be consideredwith care as this is ignoring the fact that there could beinteractions between resources as studied byYousaf andTaleb[48].

Some resources are dealt with mainly as physical ele-ments, whereas others naturally lend themselves to be definedin abstract ways. For example, sensors are present in theend devices, which can produce useful data needed for thecompletion of the task (as in [50, 52, 56, 71]), whereasbandwidth (throughput) is a natural abstraction for dis-tinguishing between different radio interfaces or differentphysical environments (abstracting the impacts of reducedsignal strength, interference, etc.).

Moreover, when using a generic resource representation,it is easier to combine several resource types or to combineresources with other performance-related considerations,one example being the generic cost function in the workby Wang et al. [77]. In their performance analysis, theydefine local and migration resource consumption that can berelated, for example, to CPU and bandwidth occupation orthe sum of them.

Another point to note is that the first architecturalinstance (edge server) is themost predominant structure usedin the surveyed papers.

4. Objective

A major classification represented in this taxonomy is theobjective of resource management. Resource management atthe edge can be decomposed into several areas addressingdifferent problems, as shown in the branches under objectivein Figure 2. In Table 2, we present which surveyed articleaddresses which problem(s) and we describe those problemsin the following subsections. As it can be seen in the table,one surveyed work can address several of the areas.

The resource management objective is orthogonal to theresource types presented in Section 3 but a discussion ofthe relationship between objectives of resource managementand resource types is conducted in our summary in Sec-tion 4.6.

4.1. Resource Estimation. One of the first requirements inresource management is the ability to estimate how manyresources will be needed to complete a task or to carry aload. This is important, especially for being able to han-dle fluctuations in resource demand while maintaining agood quality of service (QoS) for the user. On the sup-ply side, resources at the edge can be mobile and thusbecome unreachable, which makes them less reliable thanresources in a data center. On the demand side, user mobilityimplies that there can be sudden user churn, with thecorresponding dynamic requests having to be handled by theedge.

In their work, Liu et al. [54] use the average of historicaldata in order to predict the characteristics of resource distri-bution andusage for the next time slot.The term fog is used byAazam et al. [43] who propose that it can be used to performfuture resource consumption estimation as a first step forallocating resources in advance.They formulate an estimationmechanism that takes into account the reliability of thecustomer, using what they call the relinquish probability. Inanother article, Aazam and Huh [58] present the same idea

https://aws.amazon.com/fr/s3/


Table 2: Surveyed articles according to architecture category from Figure 1 and objective of resource management.

ObjectiveResourceestimation

Resourcediscovery

Resourceallocation

Resourcesharing

Resourceoptimization

Edge server

Liu et al. [59] � �Confais et al. [60] �Aazam et al. [43] �Arkian et al. [61] � �

Aazam and Hu [58] �Fan et al. [62] � �Oueis [63] � �

Tang et al. [64] �Borylo et al. [65] �

Yousaf and Taleb [48] � �Wang et al. [49] � �Gu et al. [66] � �

Tärneberg et al. [67] � �Plachy et al. [68] �Gomes et al. [13] �Fricker et al. [69] �

Rodrigues et al. [70] � �Zhang et al. [71] �

Bittencourt et al. [72] �Zamani et al. [73] � � �Valancius et al. [45] � �Chen and Xu [74] �Wang et al. [75] �Yi et al. [76] � �

Wang et al. [77] � � �Sardellitti et al. [78] � �Singh et al. [44] �

Coordinator device

Nishio et al. [52] � �Skarlat et al. [50] � � �Borgia et al. [79] �

Athwani and Vidyarthi [80] � � �Arkian et al. [51] � � �Penner et al. [56] �Bianzino et al. [81] � �Habak et al. [20] � � � �

Device cloud

Liu et al. [54] � � �Mascitti et al. [53] �Liu et al. [55] � �

Meng et al. [46] � �Qi et al. [82] � �

Mtibaa et al. [83] � � � �

but with an emphasis on how different customers can becharged for the service. Another work by Mtibaa et al. [83]estimates power consumption in order to maximize devicelifetime.

Wang et al. [77] use a look-ahead window for predictioninto the future in order to minimize cost over time. Theystudy the optimal size for such a window and propose analgorithm using binary search to find this size which they


Placement

14

Migration

7

Scheduling

3 Multiperspective

6

Figure 3: Distribution of resource allocation approaches in the surveyed articles.

evaluate as accurate as it gives results close to the size givingthe lowest cost. However, the actual prediction mechanism isassumed to be available.

With respect to computational resources, Habak et al.[20] are estimating the task requirements within a jobanalyzer. They evaluate the sensitivity of their mechanismsto estimation errors and find that the pipeline job modelis insensitive to such errors, whereas the general parallelpath model starts exhibiting a significant increase of jobcompletion time if the estimation error variance exceeds 30%.

There are of course many earlier works that use sophisti-cated prediction mechanisms for estimating future loads incloud environments (e.g., [85]) but our focus has been onedge-related papers and instances of estimation therein.

4.2. Resource Discovery. As opposed to the estimation prob-lem that relates to the demand side, resource discovery isabout the supply side. A management system needs to knowwhich resources are available for use, where they are located,and how long they will be available for use (especially if theresource providing device is moving or it is battery-driven).This area is especially important at the edge, where everyresource is not under the control of the system at all times,so the supply is volatile.

The collaboration at the edge can take the formof clusters,as advocated by Athwani and Vidyarthi [80]. They presentan algorithm for forming clusters of devices and performingresource discovery within the cluster. Their strategy is thateach member of the cluster will inform the cluster headabout their available resources and all requests for resourcesare handled by the cluster head. From their evaluation withrespect to energy consumption and delay, they conclude thatmaintaining the cluster consumes extra energy, especially ifthe devices are very mobile. Arkian et al. [51] also presenta solution using clusters and an algorithm for selecting thecluster head, that is, the vehicle that will be responsible formaintaining the vehicular cloud resources. They use fuzzylogic and a reinforcement learning technique. In order toselect the best vehicle, they need to know which vehiclepossesses the best communication to the edge node locatedon the road-side, hence performing resource discovery. Thisis done in a similar way to earlier work [80]; that is, each

potential cluster head node sends a message to the edge nodein order to evaluate the link quality before doing the selection.Therefore, those works use a locally centralized strategy forresource discovery.

However, using a locally centralized strategy comes atthe cost of the necessity to regularly update the nodegathering the resource information. Such updates are costly,for example, in terms of energy consumption, as studiedby Liu et al. [54]. They propose an algorithm enabling aswitch between a locally centralized mode and a distributedmode. In the locally centralized mode, end devices propagatetheir resource information/request to a specific node. Inthe distributed mode, end devices look for resources in theneighboring devices by using ad hoc WLAN. They qualifytheir strategy as adaptive as it takes into account the currentcharacteristics of resource distribution and usage in thenetwork. When evaluating the energy consumption of twovariants of the adaptive strategy, these perform close to theideal energy consumption (10% to 13% more energy) andboth perform better than strategies using only a distributedor locally centralized mode.

Finally, Zamani et al. [73] use a framework called Comet-Cloud, which performs resource discovery for video analysisand compare the benefit gained to a solution in the cloud.

4.3. Resource Allocation. Resource allocation can be tackledfrom two different perspectives: where to allocate (bothinitially, but also where and when to perform a migrationif needed) and when and how much to allocate. Among thedominant approaches to allocation, we find the followingthree perspectives: placement (14 articles), migration (7 arti-cles), and scheduling (3 articles), as well as a multiperspectiveone (6 articles) as shown in Figure 3.

In what follows, we group papers that have a singleperspective under Sections 4.3.1, 4.3.2, and 4.3.3 and thenmove on to papers where several perspectives are present.

4.3.1. Placement. Most of the surveyed works emphasize thefirst perspective, that is, where should the task be executedand the resource allocated for the best possible execution.The definition of best execution varies depending on theconsidered system and the focus of the research.


Load distribution to achieve lower latency has attractedattention in a number of surveyed works, and it can be seenas an instance of placement. Fricker et al. [69] propose anoffloading strategy between edge data centers under highloads that show the benefit of having a larger data centeras back-up for a small one. Latency is also the focus of astudy by Borylo et al. [65] who investigate dynamic resourceprovisioning.They present a policy in which the edge can usethe cloud in compliance with the latency requirements of theedge but enables better energy efficiency by using resourcesin data centers powered by green energy.

Also focusing on energy, Mtibaa et al. [83] propose apower balancing algorithm inwhich a device decideswhetherto offload and to which other device depending on the energyleft in the devices’ batteries. In a single-hop scenario, theirsolution extended the time before the first device of the groupruns out of battery by 60% (from 40 minutes to 2 hours)compared to a greedy solution.

Oueis [63] tackles the issue of load distribution andresource allocation in small cell clusters. She formulates ajoint computational and communication resource allocationand optimization problem in amultiuser case with a focus onlatency and power efficiency. Similarly, Sardellitti et al. [78]study an offloading problemwhen the end users are separatedinto two groups: those who need computation offloading andthose who do not.They propose a method to jointly optimizecommunication and computation resources, where both usergroups compete for communication resources but only thefirst group competes for computation resources. They firstpresent an algorithm for the single-user case and then twoalgorithms for the multiple cells case, a centralized one, and adistributed version to mitigate the communication overheadinduced by the centralized approach.

Valancius et al. [45] propose a content placement strategy,where the content is movies. The focus is first on finding theoptimal number of replicas of the data to be stored and thenon placing the replicas on available gateways. Similarly, Qiet al. [82] present an allocation scheme, where the resource(coming from either a cloudlet or a cloud) is chosen for eachtask. The aim is to pick the resource from the most suitablelocation when the user is moving.

Wang et al. [77] study service placement in a systemcomposed of edge server nodes and traditional cloud nodes.Simulation results with real-world traces from San Franciscotaxis show that the proposed approach is close to the case ofonline placement when the future is known, outperformingedge-only or cloud-only solutions. Similarly, Skarlat et al. [50]present a service placement problem for IoT services.

Mascitti et al. [53] present an algorithm where an enddevice can choose to either use a resource from a node itis directly in contact with or compose different resourcesfrom different nodes in order to complete its task. Comingfrom the same research group, Borgia et al. [79] present aframework where the decision is taken to obtain a servicefrom a local group of end devices or from the cloud, basedon an estimation of the time required to obtain the service.

Confais et al. [60] propose a storage mechanism wherethe objects to be stored are primarily placed locally attheir creation but can then be copied to another location

if another edge site is requiring access to it. In vehicularnetworks where resources are mobile, placement has to takeaccount of changes in location. Meng et al. [46] present aresource allocation scheme that can manage resources froma vehicular cloud, the edge, or the cloud. Their focus is onminimizing delays for the users.

In the application domain of healthcare, Gu et al. [66]include VM placement in their optimization problem foranalyzing data.Their two-phase solution has a nearly optimalsolution and outperforms a greedy strategy with regard tocost.

4.3.2. Migration. Still considering where the task should beexecuted, when it comes to virtual entities such as services,applications, tasks, and VMs, the focus could also be on howthey can be moved during execution if the new location isbetter, that is, on migration.

For example, Tärneberg et al. [67] study application-driven placement and present a system model for mobilecloud network with a dynamic placement algorithm thatguarantees application performance, minimizes cost, andtackles resource asymmetry problems. Plachy et al. [68]propose a cooperative and dynamicVMplacement algorithmassociated with another cooperative algorithm for selectinga suitable communication path. They use VM migration tosolve user mobility problems.

Other works focus specifically on the problem of migrat-ing resources. For example, Gomes et al. [13] present acontent-relocation algorithm for migrating the content ofcaches present in edge devices.This needs a prediction of usermobility.

With respect to virtual computational resources, Fan et al.[62] andRodrigues et al. [70] focus onVMmigration butwithdifferent optimization objectives (increase the use of greenenergy and minimize delays, resp.). Yousaf and Taleb [48]propose a VMmigration (and VMmanagement) system thattakes into account the relationship between resource unitswhen making migration decisions. They present this work inthe context of 5G but it should be applicable to all physicalmachines hosting VMs.

Finally, Penner et al. [56] introduce the term transientcloud and concentrate on task assignment towards a givennode. They present a collaborative computing platform thatallows nearby devices to form an ad hoc network and providethe ability to balance the assignments among themselves.Thismay be considered as a form of migration.

4.3.3. Scheduling. While there is a huge body of researchesavailable on when and howmany resources to allocate withinnetworking and cloud-specific areas, our goal here was toidentify examples where scheduling decisions are at the edgelevel in the sense of our terminology in Section 2.1.

Regarding when to allocate resources, Bittencourt etal. [72] study the impact of three different fog schedulingstrategies on application QoS (concurrent, first come-firstserved, and delay-priority). For two applications studied,when more than four users are moved between cloudlets,the concurrent strategy exhibits a lot longer delays than the


sequential ones. However, this same strategy is using thenetwork a lot less than the other two.

With the same focus, Singh et al. [44] consider onlyscheduling for tasks with a private tag. Those can only beexecuted on the local edge server and will be rejected if notenough resources are available. In their algorithm, tasks areconsidered in an earliest-deadline-first manner.

Regarding how many resources to allocate, Wang etal. [49] propose a joint cost-effective resource allocationbetween the mobile cloud computing infrastructures and thecloud radio access network infrastructure. If the need ofthe application is greater than the available computationalresources, then they reduce the amount given to each virtualmachine so that it fits the total amount available and adaptthe data rate accordingly. They show that joint optimizationwith respect to cost and energy performs better compared toseparate cost- and energy-optimization strategies.

Similarly, Wang et al. [75] propose elastic resource allo-cation for video-surveillance systems. The elasticity comesfrom an algorithm they propose to handle some emergencysurveillance event (like tracking a criminal) that requiresa sudden increase of computation and communicationresources to make sure that all the possible images areanalyzed within a reasonable timeframe. When such anemergency event happens, network bandwidth allocation isreconfigured and computing resources are reallocated (bylaunching new VMs in the impacted zone and balancing theworkload on nodes). When experimenting in their physicaltestbed, they verified that data propagation round-trip timeis about 5 times lower with edge nodes close to the camerascompared to the cloud. They also found that the time forlaunching new VMs in the emergency mode is between oneand two minutes, which they claim is acceptable in such ascenario.

When addressing scheduling, the surveyed articles mostoften do it at the same time as placement or migration, whichis the topic of the next subsection.

4.3.4. Multiple Perspectives. A work that tackles both per-spectives is by Liu et al. [59]. It presents a multiresourceallocation system that first decides whether the requestshould be served or rejected (admission control) and thenwhere to run it (edge or cloud level) and finally how muchbandwidth and computing resources should be allocatedfor this task. To do that, they use Semi-Markov DecisionProcesses and their aim is to maximize system benefit whileguaranteeing QoS for the users. To measure the benefit, theyuse blocking probability and service time as metrics. Whenevaluating, they compare to two greedy strategies and showthat their proposal outperforms the first one and providesa 90% reduction of the blocking probability with only aslight increase of service time compared to the second greedystrategy, which would be acceptable for congested situations.

In the context of video analysis, Zamani et al. [73] alsostudied those two perspectives. Their scheduling is basedon identified chunks of video, applying two alternatives:minimizing computation time or minimizing computationcosts. Their placement is done after resource discovery usingCometCloud. In their evaluation, they showed that the

solution using edge accepts more tasks and in particularmore high-value tasks than a solution using only the cloud.Hence, the overall value obtained from the processed datais maximized at the same time as the throughput of theinfrastructure.

Also in the area of video analytics, Yi et al. [76] investi-gate three task prioritizing schemes for scheduling the taskrequests at a receiving edge node. Their solution, using theflow job shop model and applying a well-known approach(Johnson’s rule), aims at minimizing the makespan. Theirsimulations compared the approach with other strategies(Short IO First, Longest CPU Last) and found that responsetime was improved. Their work also includes a secondperspective, by investigating three task placement schemesfor collaboration within the edge level (Shortest Transmis-sion Time First, Shortest Queue Length First, and ShortestScheduling Latency First). Using their testbed, they foundthat the Shortest Scheduling Latency First achieves the bestperformance in terms of task completion time.

Singh et al. [44] consider both placement and schedulingwith respect to semiprivate or public tasks (in addition towhat was mentioned in the last subsection for private tasks).Those tasks are placed after a decision is taken for the privateones. Still considering Earliest Deadline First, the placementstrategy is to try first one’s own edge and then one’s owncloud and if they are overloaded go to some external edge andthen to an external cloud. In the evaluation, they show that,for tasks having tight deadlines, their system RT-SANE willcomplete a lot more tasks before their deadline than a cloud-only solution.

How many resources are to be allocated to a given IoTdata generator is a topic of discussion by Arkian et al. [61],in which they first mathematically model deployment andcommunication costs on various fog nodes and then decideonplacement ofVMs to achieve lowest costs. Analyzingmon-etary costs for compute nodes, their fog solution decreasedthe cost by over 33% compared to using a cloud solution. Forrouting and storagemonetary cost, the decrease is about 20%.

Habak et al. [20] first consider placement for deciding inwhich end device a task will be run. They use a path-basedassignment policy with the aim of minimizing the overheadof transmitting data needed for task execution between enddevices. In the evaluation, this translates into performingbetter than two other baseline solutions in terms of servicecompletion time. Then, they also consider scheduling of thecomputation resource. This should be done in a predictableway so that the part of the system distributing the tasks canmake good decisions.They propose a fair queuing based taskpick-up that ensures a fair execution of the tasks belonging todifferent services. Moreover, they implement an early pick-up mechanism to enhance the previous mechanism so that atask with an urgent deadline but belonging to a service witha lower priority can be executed before a higher priority taskif this one still meets its deadline.

While this is not the focus of the survey and as such isnot included in the table, Dong et al. [86] study offloadingand Earliest Deadline First scheduling within end devices.They find that one of their proposed approaches maintainsgood predictability for twice higher CPU utilization than


widely used approaches, while keeping energy consumptionreasonable.

4.4. Resource Sharing. Resources on end devices are het-erogeneous and most of the time scarce, and edge devicesalso have limited resources compared to (almost infinite)resources in the cloud. Sharing resources between devices orbetween end and edge devices aims at tackling three differentissues: not having the needed resource at all in the devicewhere the task is initiated, not having enough of it, or usingother devices’ resources in order to get a faster completion ofthe task.

Sharing resources is typically realized by poolingresources in the local vicinity of client nodes.This can extendto the edge domain (clustering edge servers) or remain at enddevices. The latter is investigated by Skarlat et al. in so-calledfog colonies [50], by Arkian et al. within vehicular clusters[51], or by Bianzino et al. [81] for uploading data streams inpresence of mobility.

We can classify the surveyed articles into two categoriesaccording to whether they include how to form the groupsof devices that will share resources or if they assume that theformation is already done and focus on the actual sharing.We call these two categories dynamic coalitions and staticcoalitions, respectively.

Starting with dynamic coalitions, Chen and Xu [74] andBianzino et al. [81] include the formation of device coalitions.Chen and Xu [74] do it using a coalition game incorporatingtrust considerations. When the supply matches the demand,they found that using a coalition can lead up to 40% lowerweighted cost (including latency and monetary considera-tions) compared to a noncooperative scenario. When thereis overload or light workload, it is either not possible or notneeded to collaborate and the gain is very low. Bianzino etal. [81] express resource sharing as an optimization problem,where the aim is to create as few and large groups as possibleto minimize the number of high-energy interfaces that willbe used. They evaluate that their algorithm leads to over60% energy saving of the total energy consumed by the enddevices.

Still using dynamic coalitions, Arkian et al. [51] and Ath-wani and Vidyarthi [80] propose methods to create clusters.The former compare their method to an earlier baselineand achieve 3 times lower service discovery delay and 4,5times lower service consumption delay for a small number(50) of vehicles. The latter show that energy consumption issimilar to a centralized approach, while the delay is closer toa flooding approach (i.e., low in both cases).

However, creating and maintaining a group of devicesthat can share their resources has a cost, for example,shown by Athwani and Vidyarthi [80] who concluded thatmaintaining the cluster consumes extra energy, especially ifthe devices are very mobile. This is why it is beneficial to dothe resource sharing in two phases, where the first phase isdeciding whether the device gains more by working aloneor joining a coalition, and the second one is deciding ifthe device will consume others’ resources [81, 87]. Yu et al.[87] show that their cooperative solution improves user QoS(defined by how much computing and how many bandwidth

resources are allocated to a user) by 75%. However, this paperis using traditional cloud resources and not edge, so it is notincluded in the tables.

Moving to static coalitions, Skarlat et al. [50] considerresources shared between two neighbor fog colonies andachieve a 35% reduction of execution cost compared to acloud-only strategy. Regarding data, a resource that manystakeholders may be interested in sharing, Zhang et al. [71]present a data sharing framework called Firework. Theyinclude two case studies, including the search for a personwith the help of multiple cameras from different owners.

Some researchers, such as Liu et al. [55], try to exploitopportunistic contacts between the devices, creating aresource sharing mechanism that enables faster task com-pletion. They propose different models for calculating tasklatencies and their approximation algorithm performs betterthan two other strategies. Similarly, Mtibaa et al. [83] definethree mobile device clusters (one hop, two hops, and oppor-tunistic) that can share their resources. Their aim is to shareresources in order to get the longest possible network lifetime,that is, saving as much energy as possible through offloadingto another device so that the devices can stay on longer. Theyidentify two important topological factors: number of hopsand disconnection rate due to mobility.

Resource sharing can perhaps speed up the executionof a task, but Nishio et al. [52] argue that this is notbringing any advantage for the user if we do not considertask dependencies in order to provide a service to the user.They provide the example of a GPS service: if the best routecalculation is very fast but the downloading of themap is not,the service to the user will not get faster as both are needed.Habak et al. [20] consider sharing of end device resourcesbelonging to a femtocloud in order to execute tasks. In theirsystem, the owner of the end device can configure howthey want to share resources via their personalized resourcesharing policies.

Finally, even if resource sharing can bring benefits fora group of end devices, it is not obvious that users willagree to share their resources, especially if they are alwayson the providing side. Therefore there is a need to developincentives for resource sharing such as works by Tang et al.[64], Bianzino et al. [81], andChen andXu [74].The followingmechanisms are provided in the above works, respectively:

(a) A double bidding mechanism for demander andsupplier of resources where the focus is on how toencourage mobiles with resources to share them

(b) A mechanism for lending energy to vicinity nodeswhich is rewarded and can be used in future scenarioswhen the lending node itself needs energy

(c) Payment incentives for lending out resources

On the same topic, Habak et al. [20] performed a pi-lot study to identify effective incentive mechanisms. Theystudied the willingness of around 50 students to share theirresources in 4 scenarios and found out that they would agreeto share their resources if they are getting compensation (e.g.,money) for it or if the reason for the computation taking placeis significant (e.g., emergencies).


4.5. Resource Optimization. A fifth objective pursued in thesurveyed works is to optimize the resource use at the edge.This is usually a joint objective together with one of thepreviously described objectives. Which aspect should beoptimized and the associated constraints vary among thesurveyed works but the three main ones are QoS (oftenunderstood as latency), energy, and operational cost. How theoptimization problem is formulated and solved also varies,and we present those variations in this section.

First, some articles consider selecting the optimum solu-tion by comparing the results from different candidates andselecting the minimum/maximum value depending on theobjective. For example, Yousaf and Taleb [48] select the valuemaximizing the resource utilization, Athwani and Vidyarthi[80] use theminimumvalue of a custom function to select thecluster head, and Mtibaa et al. [83] select the configurationmaximizing the estimated remaining energy.

Another group of works solve their optimization problemusing linear programming [45, 59] or an approximation basedon linear programming [55].

A third group of works use integer linear programming[50, 81] or mixed-integer linear programming [62]. Qi et al.[82] formulate their task allocation problem using integerprogramming and solve it by a self-adaptive learning parti-cle swarm optimization algorithm. First formulating usingmixed-integer nonlinear programming, Arkian et al. [61]then linearize the problem and solve it using mixed-integerlinear programming. Gu et al. [66] do the same and thenuse heuristics. Using a different approach, Yi et al. [76] firstformulate a mixed-integer nonlinear programming problembut then relax the integer constraints and use sequentialquadratic programming for solving.

Some works focus on convex problems, like Wang etal. [77] who use an approximation algorithm in the onlinecase and Nishio et al. [52] who use a heuristic. Starting withnonconvex problems, Oueis [63] casts them into convex onesand Wang et al. [49] first use a Weighted Minimum MeanSquare Error-based method on their nonconvex problem toobtain a convex problem that they apply the block coor-dinate descent method to for solving. Finally, Sardellitti etal. [78] have an optimization problem in the multiple-cellscase which is nonconvex and they solve it by developinga method based on Successive Convex Approximation forthe centralized approach. For the distributed approach, theychoose the approximation functions in a way that allowsdecomposition in smaller subproblems solvable in parallel.

A further group of works propose their own algorithmor heuristic. Tärneberg et al. [67] approximate an exhaustivesearch approach yielding an optimal solution but havingexponential computation complexity with an iterative localsearch algorithm finding a local optimal solution. Zamaniet al. [73] implement an optimization strategy where con-straints on computation time and cost are enforced using anadmission control strategy. Wang et al. [77] present a binarysearch algorithm for finding the optimal look-ahead windowsize, and Habak et al. [20] propose an algorithm in order todo deadline-based optimization when a helper has to handlemultiple tasks belonging to different services. Finally, Liuet al. [54] propose a heuristic algorithm that uses different

statistics to estimate the energy that is going to be consumedin each of the two possible modes during a time slot andchooses which mode to use depending on this and otherparameters.

Other methods can be used to compare heuristics withbaselines or to solve a formulation in a custom form. Inthe offline case, Wang et al. [77] show that their problemis equivalent to the shortest-path problem and solve it byusing dynamic programming. Meng et al. [46] solve Bellmanequations recursively, Rodrigues et al. [70] use integrationtechniques, and Arkian et al. [51] consider fuzzy logic and Q-learning.

4.6. Summary of Objectives in Resource Management. Byfar, the most active area of research in the edge resourcemanagement is resource allocation, as visible in Table 2.This is followed by optimization as a goal, where we see agreat majority of papers present. Among the objectives fromour taxonomy, resource estimation and resource discoveryare least studied. Resource sharing, to the extent it is used,is well represented among the second and third types ofarchitectures in Figure 1, that is, coordinator device anddevice clouds, but not in the first type of architecture (edgeserver).

Somewhat surprisingly, while scheduling is a major topicin cloud systems, the edge-specific literature does not con-sider it as the main problem, as evident from fewer worksaddressing scheduling compared to placement and migra-tion. Where autoscaling is mentioned in an edge context,authors typically deal with offloading to the cloud, whichwas not the focus of our work. There are several excellentsurveys already covering these. The work by Wang et al. [88]addressing autoscaling and the edge is among few exceptions,so we did not create a special category for this type of work.

While the previous breakdown was done in a resourceindependent manner, it is also interesting to consider theresource type studied with regard to the resource man-agement objectives. Table 3 thus combines the informationcontained in Tables 1 and 2 to give us this view. Notsurprisingly, most of the articles consider computation andcommunication for resource allocation and optimization.Quite expected as well, the proportion of resource sharingarticles (from Table 2) considering energy as a resource(45% according to Table 3) is higher than the proportion of,for example, resource allocation articles considering energy(23%), as an incentive to share resources is when you considerenergy-constrained devices. It is interesting to note that, inthe surveyed works, resource estimation is most often donefor a generic resource type and that none of the articlescombined resource estimation and storage and resourcediscovery and data.

5. Resource Location

Computing at the edge differentiates itself from regular cloudcomputing with the fact that resources used can belong todifferent levels. It is indeed not uncommon to use resourcesat the edge level primarily but also from the cloud level if


Table 3: Surveyed articles according to resource type and objective of resource management.

ObjectiveResourceestimation

Resourcediscovery Resource allocation Resource sharing Resource optimization

Resourcetype

Computation [20] [51, 73, 80] [20, 44, 46, 48–50, 53, 59, 61–63, 66–70, 72, 73, 75, 76, 78] [20, 50–52, 64, 71, 74, 80][20, 46, 48–52, 59, 61–63,66, 67, 70, 73, 76, 78, 80]

Communication [20] [51, 73, 80][20, 44–46, 48–50, 53, 59–

61, 63, 66–68, 70, 72, 73, 75, 76, 78, 79]

[20, 50–52, 55, 64, 74, 80, 81]

[20, 45, 46, 48–52, 55, 59, 61, 63, 66, 67,70, 73, 76, 78, 80, 81]

Storage [51] [45, 48, 50, 60, 61, 66, 75] [50, 51] [45, 48, 50, 51, 61, 66]Data [20] [13, 20, 50, 79] [20, 50, 52, 71] [20, 50, 52]

Energy [54, 83] [54, 80] [45, 62, 63, 65, 78, 82, 83] [52, 74, 80, 81, 83] [45, 52, 54, 62, 63, 78, 80–83]

Generic [43, 54,58, 77] [54] [56, 77, 79, 82] [55] [54, 55, 77, 82]

required. Moreover, end devices and sometimes edge devicesdo not have to be stationary as in a data center. Note that herewe make a distinction between mobility on the

Mobile Edge Computing - Hindawi Publishing...

Documents

Transcript of Mobile Edge Computing - Hindawi Publishing...