Fog and Edge Computing E-Book
117,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Wiley Series on Parallel and Distributed Computing
- Sprache: Englisch
A comprehensive guide to Fog and Edge applications, architectures, and technologies
Recent years have seen the explosive growth of the Internet of Things (IoT): the internet-connected network of devices that includes everything from personal electronics and home appliances to automobiles and industrial machinery. Responding to the ever-increasing bandwidth demands of the IoT, Fog and Edge computing concepts have developed to collect, analyze, and process data more efficiently than traditional cloud architecture.
Fog and Edge Computing: Principles and Paradigms provides a comprehensive overview of the state-of-the-art applications and architectures driving this dynamic field of computing while highlighting potential research directions and emerging technologies.
Exploring topics such as developing scalable architectures, moving from closed systems to open systems, and ethical issues rising from data sensing, this timely book addresses both the challenges and opportunities that Fog and Edge computing presents. Contributions from leading IoT experts discuss federating Edge resources, middleware design issues, data management and predictive analysis, smart transportation and surveillance applications, and more. A coordinated and integrated presentation of topics helps readers gain thorough knowledge of the foundations, applications, and issues that are central to Fog and Edge computing. This valuable resource:
- Provides insights on transitioning from current Cloud-centric and 4G/5G wireless environments to Fog Computing
- Examines methods to optimize virtualized, pooled, and shared resources
- Identifies potential technical challenges and offers suggestions for possible solutions
- Discusses major components of Fog and Edge computing architectures such as middleware, interaction protocols, and autonomic management
- Includes access to a website portal for advanced online resources
Fog and Edge Computing: Principles and Paradigms is an essential source of up-to-date information for systems architects, developers, researchers, and advanced undergraduate and graduate students in fields of computer science and engineering.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 794
Veröffentlichungsjahr: 2019
Ähnliche
Table of Contents
Cover
List of Contributors
Preface
Organization of the Book
Acknowledgments
Part I: Foundations
1 Internet of Things (IoT) and New Computing Paradigms
1.1 Introduction
1.2 Relevant Technologies
1.3 Fog and Edge Computing Completing the Cloud
1.4 Hierarchy of Fog and Edge Computing
1.5 Business Models
1.6 Opportunities and Challenges
1.7 Conclusions
References
2 Addressing the Challenges in Federating Edge Resources
2.1 Introduction
2.2 The Networking Challenge
2.3 The Management Challenge
2.4 Miscellaneous Challenges
2.5 Conclusions
References
3 Integrating IoT + Fog + Cloud Infrastructures: System Modeling and Research Challenges
3.1 Introduction
3.2 Methodology
3.3 Integrated C2F2T Literature by Modeling Technique
3.4 Integrated C2F2T Literature by Use‐Case Scenarios
3.5 Integrated C2F2T Literature by Metrics
3.6 Future Research Directions
3.7 Conclusions
Acknowledgments
References
4 Management and Orchestration of Network Slices in 5G, Fog, Edge, and Clouds
4.1 Introduction
4.2 Background
4.3 Network Slicing in 5G
4.4 Network Slicing in Software‐Defined Clouds
4.5 Network Slicing Management in Edge and Fog
4.6 Future Research Directions
4.7 Conclusions
Acknowledgments
References
5 Optimization Problems in Fog and Edge Computing
5.1 Introduction
5.2 Background / Related Work
5.3 Preliminaries
5.4 The Case for Optimization in Fog Computing
5.5 Formal Modeling Framework for Fog Computing
5.6 Metrics
5.7 Optimization Opportunities along the Fog Architecture
5.8 Optimization Opportunities along the Service Life Cycle
5.9 Toward a Taxonomy of Optimization Problems in Fog Computing
5.10 Optimization Techniques
5.11 Future Research Directions
5.12 Conclusions
Acknowledgments
References
Part II: Middlewares
6 Middleware for Fog and Edge Computing: Design Issues
6.1 Introduction
6.2 Need for Fog and Edge Computing Middleware
6.3 Design Goals
6.4 State‐of‐the‐Art Middleware Infrastructures
6.5 System Model
6.6 Proposed Architecture
6.7 Case Study Example
6.8 Future Research Directions
6.9 Conclusions
References
7 A Lightweight Container Middleware for Edge Cloud Architectures
7.1 Introduction
7.2 Background/Related Work
7.3 Clusters for Lightweight Edge Clouds
7.4 Architecture Management – Storage and Orchestration
7.5 IoT Integration
7.6 Security Management for Edge Cloud Architectures
7.7 Future Research Directions
7.8 Conclusions
References
8 Data Management in Fog Computing
8.1 Introduction
8.2 Background
8.3 Fog Data Management
8.4 Future Research and Direction
8.5 Conclusions
References
9 Predictive Analysis to Support Fog Application Deployment
9.1 Introduction
9.2 Motivating Example: Smart Building
9.3 Predictive Analysis with FogTorchΠ
9.4 Motivating Example (continued)
9.5 Related Work
9.6 Future Research Directions
9.7 Conclusions
References
10 Using Machine Learning for Protecting the Security and Privacy of Internet of Things (IoT) Systems
10.1 Introduction
10.2 Background
10.3 Survey of ML Techniques for Defending IoT Devices
10.4 Machine Learning in Fog Computing
10.5 Future Research Directions
10.6 Conclusions
References
Part III: Applications and Issues
11 Fog Computing Realization for Big Data Analytics
11.1 Introduction
11.2 Big Data Analytics
11.3 Data Analytics in the Fog
11.4 Prototypes and Evaluation
11.5 Case Studies
11.6 Related Work
11.7 Future Research Directions
11.8 Conclusions
References
12 Exploiting Fog Computing in Health Monitoring
12.1 Introduction
12.2 An Architecture of a Health Monitoring IoT‐Based System with Fog Computing
12.3 Fog Computing Services in Smart E‐Health Gateways
12.4 System Implementation
12.5 Case Studies, Experimental Results, and Evaluation
12.6 Discussion of Connected Components
12.7 Related Applications in Fog Computing
12.8 Future Research Directions
12.9 Conclusions
References
13 Smart Surveillance Video Stream Processing at the Edge for Real‐Time Human Objects Tracking
13.1 Introduction
13.2 Human Object Detection
13.3 Object Tracking
13.4 Lightweight Human Detection
13.5 Case Study
13.6 Future Research Directions
13.7 Conclusions
References
14 Fog Computing Model for Evolving Smart Transportation Applications
14.1 Introduction
14.2 Data‐Driven Intelligent Transportation Systems
14.3 Mission‐Critical Computing Requirements of Smart Transportation Applications
14.4 Fog Computing for Smart Transportation Applications
14.5 Case Study: Intelligent Traffic Lights Management (ITLM) System
14.6 Fog Orchestration Challenges and Future Directions
14.7 Future Research Directions
14.8 Conclusions
References
15 Testing Perspectives of Fog‐Based IoT Applications
15.1 Introduction
15.2 Background
15.3 Testing Perspectives
15.4 Future Research Directions
15.5 Conclusions
References
16 Legal Aspects of Operating IoT Applications in the Fog
16.1 Introduction
16.2 Related Work
16.3 Classification of Fog/Edge/IoT Applications
16.4 Restrictions of the GDPR Affecting Cloud, Fog, and IoT Applications
16.5 Data Protection by Design Principles
16.6 Future Research Directions
16.7 Conclusions
Acknowledgment
References
17 Modeling and Simulation of Fog and Edge Computing Environments Using iFogSim Toolkit
17.1 Introduction
17.2 iFogSim Simulator and Its Components
17.3 Installation of iFogSim
17.4 Building Simulation with iFogSim
17.5 Example Scenarios
17.6 Simulation of a Placement Policy
17.7 A Case Study in Smart Healthcare
17.8 Conclusions
References
Index
End User License Agreement
List of Tables
Chapter 2
Table 2.1 Network challenges, their causes and potential solutions in federating...
Table 2.2 Management challenges, the need for addressing them, and potential sol...
Chapter 3
Table 3.1 Summary of systematic search results.
Table 3.2 Articles about modelling of IoT, fog, and cloud integration.
Table 3.3 Scenarios presented in articles.
Table 3.4 Metrics observed in articles.
Chapter 4
Table 4.1 Acronyms and abbreviations.
Table 4.2 Network‐aware virtual machines management.
Table 4.3 Virtual machine migration planning.
Table 4.4 Virtual network functions management projects.
Chapter 5
Table 5.1 Notation overview.
Table 5.2 Classification of the work of Do et al. [21] according to the presente...
Table 5.3 Classification of the work of Sardellitti et al. [22] according to the...
Table 5.4 Classification of the work of Mushunuri et al. [23] according to the p...
Chapter 6
Table 6.1 Middleware features in fog and edge architectures.
Chapter 7
Table 7.1 Speed and power consumption of the Raspberry Pi cluster. Adapted from ...
Table 7.2 Approximate costs of the Raspberry Pi cluster.
Table 7.3 Time comparison – listing the overall, the mean, and the maximal time ...
Table 7.4 Comparison of the power consumption while idling and under load.
Table 7.5 Power consumption of the Raspberry Pi cluster while idling and under l...
Chapter 9
Table 9.1 Hardware specification for different VM types.
Table 9.2 QoS profiles associated to the communication links.
Table 9.3 Eligible deployments generated by FogTorchΠ for Q1 and Q2.
14
Table 9.4 Result of FogTorchΠ for the VR Game.
Chapter 10
Table 10.1 OWASP IoT attack surface areas.
Table 10.2 Categorization of ML solutions for IOT security.
Table 10.3 Categorization of ML solutions for outlier detection.
Table 10.4 Where data should be processed.
Table 10.5 ML Use cases for fog computing.
Table 10.6 Machine‐learning algorithms at different fog layers.
Chapter 11
Table 11.1 Data analytics using a fog‐engine and the cloud.
Table 11.2 Comparison of various schemes with and without a fog‐engine, where ba...
Table 11.3 List of IOT solutions from five major cloud providers.
Chapter 12
Table 12.1 Energy consumption of the sensor node with and without running AES.
Chapter 14
Table 14.1 Application use cases for data‐driven intelligent transportation appl...
Table 14.2 Performance comparison of cloud and fog computing models in smart tra...
Table 14.3 Computing requirements of intelligent traffic light management (ITLM)...
Chapter 15
Table 15.1 Outline of the work done to test smart homes.
Table 15.2 Outline of the work done to test smart health.
Table 15.3 Outline of the work done to test smart transport.
Table 15.4 Summary of limitations and research directions for smart home.
Table 15.5 Summary of limitations and research directions for smart health.
Table 15.6 Summary of limitations and research directions for smart transport.
List of Illustrations
Chapter 1
Figure 1.1 IoT applications and environments with supporting computing p...
Figure 1.2 FEC nodes supports five basic mechanisms—storage, compute, ac...
Figure 1.3 Hierarchy of fog and edge computing.
Chapter 2
Figure 2.1 Networking and management challenges in federating edge resou...
Figure 2.2 Fog computing with SDN as the network orchestrator.
Figure 2.3 Resource and modeling challenges in federating edge resources...
Chapter 3
Figure 3.1 Integration of IoT devices with fog and cloud computing.
Figure 3.2 Systematic review steps. Adapted from [8].
Figure 3.3 The most approaches used to model the integration among cloud...
Equation 3.1 Scheme proposed in [10].
Equation 3.2 Energy consumption model presented in [17].
Equation 3.3 Billing model presented in [15].
Equation 3.4 Calculate of energy consumption between IoT and c...
Equation 3.5 Calculate of energy consumption between IoT and f...
Equation 3.6 Reliability equation presented in [16].
Figure 3.4 Petri Net model proposed in [26]. © Elsevier. Reproduced with...
Petri Net model presented in [29]. © Elsevier. Reproduced with the pe...
Equation 3.7 Objective function used in ILP model presented in [28].
Figure 3.6 Markov model presented in [21]. Adapted from [21].
Figure 3.7Figure 3.7 Fuzz‐ontology model proposed in [13]. © Elsevier. Rep...
Chapter 4
Figure 4.1 Generic 5G slicing framework.
Figure 4.2 Taxonomy of network‐aware VM/VNF Management in software‐defin...
Chapter 5
Figure 5.1 Number of (a) papers and (b) citations in fog computing.
Figure 5.2 Number of (a) papers and (b) citations about optimization in ...
Figure 5.3 Three‐layer model of fog computing.
Figure 5.4 Total execution time of an example computation offloading sce...
Chapter 6
Figure 6.1 Fog and edge computing devices.
Figure 6.2 Fog and edge computing architecture.
Chapter 7
Figure 7.1 Edge cloud architecture.
Figure 7.2 Simplified container orchestration plan for the ski resort ca...
Figure 7.3 Overall orchestration flow.
Figure 7.4 Blockchain‐based IoT orchestration and security management.
Figure 7.5
Provenance model
. Adapted from W3C. “PROV Model Primer,” Ap...
Figure 7.6 Blockchain‐based tracking of an orchestration plan.
Figure 7.7 Architecture of the blockchain integration.
Chapter 8
Figure 8.1 Structure of data management in fog computing.
Figure 8.2 Basic data management diagram in fog computing.
Figure 8.3 Data life cycle in fog computing.
Figure 8.4 A simple sequence diagram of an e‐health application.
Figure 8.5 Proposed architecture.
Figure 8.6 Interaction of the main process in proposed architecture.
Chapter 9
Figure 9.1 Fog application of the motivating example.
1
Figure 9.2 Fog infrastructure of the motivating example.
4
Figure 9.3 Bird's‐eye view of FogTorchΠ.
Figure 9.4 Pseudocode of the exhaustive search algorithm.
Figure 9.5 Search space to find eligible deployments of
A
to
I
.
Figure 9.6 Pseudocode for the backtracking search.
Figure 9.7 Pseudocode of the Monte Carlo simulation in FogTorchΠ.
Figure 9.8 Bernoulli sampling function example.
Figure 9.9 Results for Q1(a) and Q1(b).
15
Figure 9.10 Results
16
for Q2.
Figure 9.11 VR Game application.
Figure 9.12 VR Game infrastructure.
18
Chapter 10
Figure 10.1 IoT system with threats and protections annotated.
Figure 10.2 Privacy vulnerabilities in IoT
Figure 10.3 Privacy threats with entities and information flows in IoT. ...
Figure 10.4 DDoS attack.
Figure 10.5 Ensemble machine learning.
Figure 10.6 Fog computing security at multiple layers.
Chapter 11
Figure 11.1 Typical data analytics flow.
Figure 11.2 Deployment of FE in a typical cloud‐based computing system. ...
Figure 11.3 Data analytics using a fog‐engine before offloading to the c...
Figure 11.4 (a) General architecture of fog‐engine; (b) A detailed archi...
Figure 11.5 Various configurations of fog‐engine: (a) as a broker; (b) a...
Figure 11.6 Fog‐engine collects data and communicates with the cloud.
Figure 11.7 Data transmission time between FEs and cloud for various pac...
Figure 11.8 The deployment of fog‐engines in the system pipeline.
Figure 11.9 Architecture of the smart nutrition monitoring system.
Figure 11.10 Prototype of the smart nutrition monitoring system.
Chapter 12
Figure 12.1 Architecture of remote real‐time health‐monitoring IoT syste...
Figure 12.2 Fog services in a smart gateway.
Figure 12.3 Acceleration and angular velocity changes during a fall.
Figure 12.4 Multilevel threshold based fall detection algorithm.
Figure 12.5 SVM of 3‐D acceleration and SVM of 3‐D angular velocity.
Figure 12.6 Real‐time ECG monitoring and preprocess ECG data at fog.
Figure 12.7 RMS of HRV features in different window lengths and differen...
Figure 12.8 ROC curves of
No pain
and
Pain
classification.
Chapter 13
Figure 13.1 Edge‐fog‐cloud‐based hierarchy smart surveillance architectu...
Figure 13.2 Haar‐like features: (a) two rectangular features; (b) three ...
Figure 13.3 (a) Histogram of oriented gradients; (b) representation of H...
Figure 13.4 An example of multi‐detection for a single object.
Figure 13.5 Object tracking methods.
Figure 13.6 Different motion constrains.
Figure 13.7 KCF tracking process.
Figure 13.8 Convolutional filter vs. separable depthwise convolutional f...
Figure 13.9 Results of Haar cascaded human detection.
Figure 13.10 Performance of HOG+SVM algorithm.
Figure 13.11 Example of light version CNN for human object detection.
Figure 13.12 An example of multi‐object tracking.
Figure 13.13 An example of object tracker phase in and out.
Figure 13.14 An example of re‐tracking after target lost.
Chapter 14
Figure 14.1 Key components of a data‐driven ITS [12].
Figure 14.2 Topology of FOG computing paradigm for smart transportation ...
Figure 14.3 Data/Control Flow among FCNs in Layer 2
Figure 14.4 An orchestration scenario for intelligent traffic management...
Figure 14.5 Functional elements of a typical fog orchestrator showing th...
Figure 14.6 The conceptual framework for BD
2
A and optimization of ITLM b...
Chapter 16
Figure 16.1 Data management in fog environments.
Chapter 17
Figure 17.1 Interactions among IoT‐enabled systems, fog and cloud compu...
Figure 17.2 High‐level view of interactions among iFogSim components.
Figure 17.3 Master–worker application model.
Figure 17.4 Sequential unidirectional dataflow application model.
Figure 17.5 Network topology for the placement policy.
Figure 17.6 Application model for the placement policy.
Figure 17.7 Flowchart of the application placement policy.
Figure 17.8 Fog environment for IoT‐enabled healthcare case study.
Figure 17.9 Application model for IoT‐enabled healthcare case study.
Guide
Cover
Table of Contents
Begin Reading
Pages
iii
vi
5
xix
xx
xxi
xxii
xxiii
xxiv
xxv
xxvii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
1
2
3
4
5
6
Wiley Series On Parallel and Distributed Computing
Series Editor: Albert Y. Zomaya
A complete list of titles in this series appears at the end of this volume.
Fog and Edge Computing
Principles and Paradigms
Edited by Rajkumar Buyya and Satish Narayana Srirama
Copyright
This edition first published 2019
© 2019 John Wiley & Sons, Inc
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Rajkumar Buyya and Satish Narayana Srirama to be identified as the authors of the editorial material in this work has been asserted in accordance with law.
Registered Office
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA
Editorial Office
111 River Street, Hoboken, NJ 07030, USA
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of Warranty
While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging‐in‐Publication Data
Names: Buyya, Rajkumar, 1970‐ editor. | Srirama, Satish Narayana, 1978‐
editor.
Title: Fog and edge computing : principles and paradigms / edited by Rajkumar
Buyya, Satish Narayana Srirama.
Description: Hoboken, NJ, USA : John Wiley & Sons, Inc., 2019. | Series:
Wiley series on parallel and distributed computing | Includes
bibliographical references and index. |
Identifiers: LCCN 2018054742 (print) | LCCN 2018057015 (ebook) | ISBN
9781119525011 (Adobe PDF) | ISBN 9781119525066 (ePub) | ISBN 9781119524984
(hardcover)
Subjects: LCSH: Cloud computing. | Electronic data processing–Distributed
processing.
Classification: LCC QA76.585 (ebook) | LCC QA76.585 .F63 2019 (print) | DDC
004.67/82–dc23
LC record available at https://lccn.loc.gov/2018054742
Cover design by Wiley
Cover image: © Shaxiaozi/iStock.com
List of Contributors
Zoltán Ádám Mann
University of Duisburg‐Essen
Germany
e‐mail: [email protected]
Edison Albuquerque
Universidade de Pernambuco
Brazil
e‐mail: [email protected]
Mohammad Saad Alam
Aligarh Muslim University
India
e‐mail: [email protected]
Ahmet Cihat Baktir
Bogazici University
Turkey
e‐mail: [email protected]
Ayan Banerjee
Arizona State University
USA
e‐mail: [email protected]
M. M. Sufyan Beg
Aligarh Muslim University
India
e‐mail: [email protected]
Antonio Brogi
University of Pisa
Italy
e‐mail: [email protected]
Rajkumar Buyya
University of Melbourne
Australia
e‐mail: [email protected]
Vinaya Chakati
Arizona State University
USA
e‐mail: [email protected]
Chii Chang
University of Tartu
Estonia
e‐mail: [email protected]
Priyanka Chawla
Lovely Professional University
India
e‐mail: [email protected]
Rohit Chawla
Apeejay College
India
e‐mail: [email protected]
Yu Chen
Binghamton University
USA
e‐mail: [email protected]
Qinghua Chi
University of Melbourne
Australia
e‐mail: [email protected]
Nabil El Ioini
Free University of Bozen‐Bolzano
Italy
e‐mail: [email protected]
Patricia Takako Endo
Universidade de Pernambuco
Dublin City University
Ireland
e‐mail: [email protected]
Cem Ersoy
Bogazici University
Turkey
e‐mail: [email protected]
Leylane Ferreira
Universidade Federal de Pernambuco
Brazil
e‐mail: [email protected]
Matheus Ferreira
Universidade de Pernambuco
Brazil
e‐mail: [email protected]
Stefano Forti
University of Pisa
Italy
e‐mail: [email protected]
Tuan Nguyen Gia
University of Turku
Finland
e‐mail: [email protected]
Sandeep Kumar S. Gupta
Arizona State University
USA
e‐mail: [email protected]
Sven Helmer
Free University of Bozen‐Bolzano
Italy
e‐mail: [email protected]
M. Muzakkir Hussain
Aligarh Muslim University
India
e‐mail: [email protected]
Ahmad Ibrahim
University of Pisa
Italy
e‐mail: [email protected]
Bahman Javadi
Western Sydney University
Australia
e‐mail: [email protected]
Mingzhe Jiang
University of Turku
Finland
e‐mail: [email protected]
Judith Kelner
Universidade Federal de Pernambuco
Brazil
e‐mail: [email protected]
Attila Kertesz
University of Szeged
Hungary
e‐mail: [email protected]‐szeged.hu
Theo Lynn
Dublin City University
Ireland
e‐mail: [email protected]
Aniket Mahanti
University of Auckland
New Zealand
e‐mail: [email protected]
Redowan Mahmud
University of Melbourne
Australia
e‐mail: [email protected]
Farhad Mehdipour
New Zealand School of Education and STEM Fern Ltd.
Auckland
New Zealand
e‐mail: [email protected]
Lorenzo Miori
Free University of Bozen‐Bolzano
Italy
e‐mail: [email protected]
Melody Moh
San Jose State University
USA
e‐mail: [email protected]
Seyed Yahya Nikouei
Binghamton University
USA
e‐mail: [email protected]
Tina Samizadeh Nikoui
Islamic Azad University
Iran
e‐mail: [email protected]
Atay Ozgovde
Galatasaray University
Turkey
e‐mail: [email protected]
Claus Pahl
Free University of Bozen‐Bolzano
Italy
e‐mail: [email protected]
Madhurima Pore
Arizona State University
USA
e‐mail: [email protected]
Amir Masoud Rahmani
Islamic Azad University & University of Human Development
Iran
e‐mail: [email protected]
Robinson Raju
San Jose State University
USA
e‐mail: [email protected]
Guillermo Ramirez‐Prado
Unitec Institute of Technology
Auckland
New Zealand
e‐mail: [email protected]
Djamel Sadok
Universidade Federal de Pernambuco
Brazil
e‐mail: [email protected]
Julian Sanin
Free University of Bozen‐Bolzano
Italy
e‐mail: Julian.Sanin@stud‐inf.unibz.it
Guto Leoni Santos
Universidade Federal de Pernambuco
Brazil
e‐mail: [email protected]
Cagatay Sonmez
Bogazici University
Turkey
e‐mail: [email protected]
Satish Narayana Srirama
University of Tartu
Estonia
e‐mail: [email protected]
Hooman Tabarsaied
Islamic Azad University
Iran
e‐mail: [email protected]
Adel Nadjaran Toosi
University of Melbourne
Australia
e‐mail: [email protected]
Sz. Varadi
University of Szeged
Hungary
e‐mail: [email protected]‐szeged.hu
Blesson Varghese
Queen's University Belfast
UK
e‐mail: [email protected]
G. Gultekin Varkonyi
University of Szeged
Hungary
e‐mail: [email protected]‐szeged.hu
David von Leon
Free University of Bozen‐Bolzano
Italy
e‐mail: [email protected]
Ronghua Xu
Binghamton University
USA
e‐mail: [email protected]
Preface
The Internet of Things (IoT) paradigm promises to make “things” such as physical objects with sensing capabilities and/or attached with tags, mobile objects such as smart phones and vehicles, consumer electronic devices, and home appliances such as refrigerators, televisions, and healthcare devices as part of the Internet environment. In cloud‐centric IoT (CIoT) applications, the sensor data from these “things” is extracted, accumulated, and processed at the public/private clouds, leading to significant latencies. Fog computing addresses this issue in developing real‐time IoT applications, by mainly utilizing proximity‐based computational resources across the IoT layers such as gateways, cloudlets, and network switches/routers. A similar approach of utilizing proximity resources in the telecommunication domain is mobile edge computing.
To realize the full potential of fog and edge computing and similar paradigms, researchers and practitioners need to address several challenges and develop suitable conceptual and technological solutions for tackling them. These include development of scalable architectures, moving from closed systems to open systems, dealing with privacy and ethical issues involved in data sensing, storage, processing, and actions, designing interaction protocols, and autonomic management.
The primary purpose of this book is to capture the state‐of‐the‐art in fog and edge computing, their applications, architectures, and technologies. The book also aims to identify potential research directions and technologies that will facilitate insight generation in various domains from smart home, smart cities, science, industry, business, and consumer applications. We expect the book to serve as a reference for larger audiences such as system architects, practitioners, developers, new researchers, and graduate‐level students. This book also comes with an associated website (hosted at http://cloudbus.org/fog/book/) containing pointers to advanced on‐line resources.
Organization of the Book
This book contains chapters authored by several leading experts in the fields of IoT, cloud, and fog computing. The book is presented in a coordinated and integrated manner, starting with the fundamentals and followed by the middleware and technological solutions to implement fog and edge‐related applications.
The contents of the book are organized into three parts:
Foundations
Middlewares
Applications and Issues
Part I focuses on Foundations and is made up of five chapters. The first chapter, “Internet of Things (IoT) and New Computing Paradigms,” discusses the IoT paradigm along with CIoT limitations. The relevant technologies and new computing paradigms that address these limitations such as fog computing, edge computing and mist computing, are discussed along with their main advantages and basic mechanisms. The hierarchy of fog and edge computing environments is discussed, and the opportunities and challenges offered by fog and edge computing are discussed thoroughly. The challenges along with their future research directions are further structured into networking, management, and resource and modeling challenges, in Chapter 2, “Addressing the Challenges in Federating Edge Resources.” The use of modelling techniques and the relevant literature to represent and evaluate an integrated cloud‐to‐things system comprising cloud computing, fog computing, and the IoT is reviewed in Chapter 3, “Integrating IoT + Fog + Cloud Infrastructures: System Modeling and Research Challenges.” The state‐of‐the‐art literature on network slicing in 5G, edge/fog, and cloud computing is reviewed in Chapter 4, “Management and Orchestration of Network Slices in 5G, Fog, Edge, and Clouds.” Part I concludes with a discussion of generic conceptual framework for optimization problems in fog computing, based on consistent, well‐defined, and formalized notation for constraints and optimization objectives, in Chapter 5, “Optimization Problems in Fog and Edge Computing.”
Part II focuses on Middlewares and is made up of five chapters. Chapter 6, “Middleware for Fog and Edge Computing: Design Issues,” discusses different aspects of the design of middleware for Fog and Edge computing along with a proposed architecture. Chapter 7, “A Lightweight Container Middleware for Edge Cloud Architectures,” discusses the core principles of an edge cloud reference architecture that is based on containers as the packaging and distribution mechanism. The chapter also provides experimental results with Raspberry Pi clusters to validate the proposed architectural solution. Chapter 8, “Data Management in Fog Computing,” proposes the conceptual architecture for the data management in fog computing environments. The chapter also provides a review of the fog data management, along with future research directions. Chapter 9, “Predictive Analysis to Support Fog Application Deployment,” discusses FogTorchΠ prototype that supports application deployment in the fog. The prototype permits expression of processing capabilities, predicts QoS attributes, and estimates operational costs of a fog infrastructure, along with processing and QoS requirements of an application. Chapter 10, “Using Machine Learning for Protecting the Security and Privacy of Internet of Things (IoT) Systems,” reviews the machine learning (ML) techniques for defending IoT devices, along with a discussion on scope of ML in fog computing.
Part III focuses on Applications and relevant issues and is made up of seven chapters. Chapter 11, “Fog Computing Realization for Big Data Analytics,” discusses a fog‐engine prototype that can be deployed in the traditional centralized data analytics platform to realize the data analytics in the fog environment. Smart home and smart nutrition monitoring system case studies are provided, which conceptually utilize the fog‐engine. Chapter 12, “Exploiting Fog Computing in Health Monitoring,” discussed fog computing services in smart e‐health gateways. The proposed system is implemented and evaluated with a remote ECG (electrocardiogram) monitoring case study. Chapter 13 discussed “Smart Surveillance Video Stream Processing at the Edge for Real‐Time Human Objects Tracking.” The computations and algorithms used at the fog and edge levels to create such automated surveillance system are discussed and compared. Chapter 14, “Fog Computing Model for Evolving Smart Transportation Applications,” identified the computing needs of the data‐driven transportation architecture and devised a fog‐assisted cloud‐based computational platform for smart transportation applications, in the context of intelligent traffic management system (ITSM) use case. Chapter 15 discussed and reviewed “Testing Perspectives of Fog‐Based IoT Applications,” in the smart home, smart health, and smart transport domains. Chapter 16, “Legal Aspects of Operating IoT Applications in the Fog,” classified fog/edge/IoT applications, analyzed the latest restrictions introduced by the General Data Protection Regulation (GDPR), and discussed how these legal constraints affect the design and operation of IoT applications in fog and cloud environments. Another critical issue related to fog application development is that it is very costly due to the fact that the fog computing environment incorporates IoT devices, fog nodes, and cloud datacenters, along with a huge amount of IoT data. To address this, Chapter 17 discussed “Modeling and Simulation of Fog and Edge Computing Environments Using iFogSim Toolkit.” iFogSim simulator components are discussed and installation details are provided, along with detailed guidelines to model the fog environment.
Acknowledgments
First and foremost, we are grateful to all the contributing authors for their time, effort, and understanding during the preparation of the book.
We thank Albert Zomaya, editor of Wiley book series on parallel and distributed computing, for his enthusiastic support, enabling us to easily navigate through Wiley's publication process.
Raj would like to thank his family members, especially Smrithi, Soumya, and Radha Buyya, for their love, understanding, and support during the preparation of the book. Satish would like to thank his wife, Gayatri, and parents (S. Lakshminarayana and Lolakshi) for their love and support and his new born daughter, Meghana, for the pleasantness she brought into the family.
Finally, we would like to thank the staff at Wiley, particularly Brett Kurzman (senior editor) and Victoria Bradshaw (editorial assistant). They were wonderful to work with!
Rajkumar Buyya
The University of Melbourne and Manjrasoft Pty Ltd, Australia
Satish Narayana Srirama
The University of Tartu, Estonia
Part IFoundations
1Internet of Things (IoT) and New Computing Paradigms
Chii Chang Satish Narayana Srirama and Rajkumar Buyya
1.1 Introduction
The Internet of Things (IoT) [1] represents a comprehensive environment that interconnects a large number of heterogeneous physical objects or things such as appliances, facilities, animals, vehicles, farms, factories etc. to the Internet, in order to enhance the efficiency of the applications such as logistics, manufacturing, agriculture, urban computing, home automation, ambient assisted living, and various real‐time ubiquitous computing applications.
Commonly, an IoT system follows the architecture of the Cloud‐centric Internet of Things (CIoT) in which the physical objects are represented in the form of Web resources that are managed by the servers in the global Internet [2]. Fundamentally, in order to interconnect the physical entities to the Internet, the system will utilize various front‐end devices such as wired or wireless sensors, actuators, and readers to interact with them. Further, the front‐end devices have the Internet connectivity via the mediate gateway nodes such as Internet modems, routers, switches, cellular base stations, and so on. In general, the common IoT system involves three major technologies: embedded systems, middleware, and cloud services, where the embedded systems provide intelligence to the front‐end devices, middleware interconnects the heterogeneous embedded systems of front‐end devices to the cloud and finally, the cloud provides comprehensive storage, processing, and management mechanisms.
Although the CIoT model is a common approach to implement IoT systems, it is facing the growing challenges in IoT. Specifically, CIoT faces challenges in BLURS—bandwidth, latency, uninterrupted, resource‐constraint, and security [3].
Bandwidth
. The increasingly large and high‐frequent rate data produced by objects in IoT will exceed the bandwidth availability. For example, a connected car can generate tens of megabytes' data per second for the information of its route, speeds, car‐operating condition, driver's condition, surrounding environment, weather etc. Further, a self‐driving vehicle can generate gigabytes of data per second due to the need for real‐time video streaming. Therefore, fully relying on the distant Cloud to manage the things becomes impractical.
Latency
. Cloud faces the challenges of achieving the requirement of controlling the end‐to‐end latency within tens of milliseconds. Specifically, industrial smart grids systems, self‐driving vehicular networks, virtual and augmented reality applications, real‐time financial trading applications, healthcare, and eldercare applications cannot afford the causes derived from the latency of CIoT.
Uninterrupted
. The long distance between cloud and the front‐end IoT devices can face issues derived from the unstable and intermittent network connectivity. For example, a CIoT‐based connected vehicle will be unable to function properly due to the disconnection occurred at the intermediate node between the vehicle and the distant cloud.
Resource‐constrained
. Commonly, many front‐end devices are resource‐constrained in which they are unable to perform complex computational tasks and hence, CIoT systems usually require front‐end devices to continuously stream their data to the cloud. However, such a design is impractical in many devices that operate with battery power because the end‐to‐end data transmission via the Internet can still consume a lot of energy.
Security
. A large number of constraint front‐end devices may not have sufficient resources to protect themselves from the attacks. Specifically, outdoor‐based front‐end devices, which rely on the distant cloud to keep them updated with the security software, can be attackers' targets, in which the attackers are capable of performing a malicious activity at the edge network where the front‐end devices are located and the cloud does not have full control on it. Furthermore, the attacker may also damage or control the front‐end device and send false data to the cloud.
The growing challenges of CIoT raised a question—what can be done to overcome the limitation of current cloud‐centric architecture?
In the last decade, several approaches have tried to extend the centralized cloud computing to a more geo‐distributed manner in which the computational, networking, and storage resources can be distributed to the locations that are much closer to the data sources or end‐user applications. For example, the geo‐distributed cloud‐computing model [4] tends to partition the portions of processes to the data centers near the edge network. Further, the mobile cloud computing model [5] introduced the physical proximity‐based cloud computing resources provisioned by the local wireless Internet access point providers. Moreover, academic research projects [6] have experimented with the feasibility of the mobile ad hoc network (MANET)‐based cloud using the advanced RISC machine (ARM)‐powered devices. Among the various approaches, the industry‐led fog computing architecture, which was first introduced by Cisco research [7], has gained the most attention.
Fog computing architecture [8] covers a broad range of equipment and networks. In general, it is a conceptual model that address all the possibilities to extend the cloud to the edge network of CIoT, from the geo‐distributed data center, intermediate network nodes to the extreme edge where the front‐end IoT devices are located. Figure 1.1 illustrates different network computing paradigms supporting IoT‐enabled smart systems and applications. To enumerate, the general CIoT paradigm (mark 1) manages the smart systems entirely at the distant central cloud datacenter in which the IoT devices act as simple sensory data collectors or actuators and leave the processes and decision‐making to the cloud. The generic edge computing paradigm (mark 2) distributes certain tasks to the IoT devices or the co‐located computers within the same subnet of the IoT devices. Such tasks can be data classification, filtering, or signal converting, for example. Fog computing paradigm (marks 3 and 4) utilizes a hierarchical‐based distributed computing model that supports horizontal scalability of the computational resources.
Figure 1.1IoT applications and environments with supporting computing paradigms.
For example, a fog‐enabled IoT system can distribute the simple data classification tasks to the IoT devices and assign the more complicated context reasoning tasks at the edge gateway devices. Further, for the analytics tasks that involve terabytes of data, which requires higher processing power, the system can further move the processes to the resources at the core network such as the data centers of wide area network (WAN) service providers or it can utilize the cloud. Certainly, the decision of where the system should assign the tasks among the resources across different tiers depends on efficiency and adaptability. For example, smart systems may need to assign certain decision‐making tasks to the edge devices in order to provide timely notification about the situation, such as the patient's condition in the smart healthcare, the security state of the smart home, the traffic condition of the smart city, the water supply condition of smart farming, or the production line operation condition of a smart factory.
The industry has seen fog as the main trend for the practical IoT systems, and the leading OpenFog consortium has established collaboration with major industrial standard parties such as European Telecommunications Standards Institute (ETSI) multi‐access edge computing (MEC) and IEEE Standard for fog computing and networking [9] to hasten the fog. Furthermore, the fog market research report [10] stated that the market value of fog will grow from $3.7 billion by 2019 up to $18.2 billion by 2022 across different fields, where the top five utilization domains of fog will be energy/utilities, transportation, healthcare, industry, and agriculture.
In this chapter, we discuss foundations of computing paradigms for realizing emerging IoT applications, especially fog and edge computing, their background, characteristics, architectures and open challenges. Section 1.2 presents related technologies to fog and edge computing. Section 1.3 describes how fog and edge can improve CIoT. Section 1.4 explains the hierarchy of fog and edge computing environments. Section 1.5 illustrates the business models of fog and edge computing. Section 1.6 provides the information regarding to the opportunities and challenges in fog and edge computing. Finally, Section 1.7 summarizes the content of the chapter.
1.2 Relevant Technologies
The notion of having computational resources near the data sources may seem not new. Particularly, the term—edge computing appeared in 2004 to illustrate a system that distributes program methods and the corresponding data to the network edge towards enhancing performance and efficiency [11]. Similarly, the notion of having virtualization technology‐based computing resources within the Wi‐Fi subnet was introduced in 2009 [5]. However, the real industrial interest in extending computational resources to the edge network only started after the introduction of fog computing for IoT. Prior to that, applying utility cloud at the edge network was more or less a research topic in academia without explicit definition or architecture and with minor industrial involvement. In contrast, the industry has invested in fog computing architecture by establishing OpenFog consortium founded by ARM Holdings, Cisco, Dell, Intel, Microsoft, Princeton University, and over 60 members from major industrial and academic partners in the world. Further, in collaboration with international standard organizations such as ETSI and IEEE, fog has become a major trend in general information and communication technology (ICT) today.
In last several years, researchers have been using different terminologies to illustrate the similar architectures with fog. For example, the author of virtual machine (VM)‐based cloudlet [5] tended to use edge computing to describe the notion of the cloud at the edge. Moreover, the author's later work indicated that fog is a part of edge computing [12]. On the other hand, OpenFog consortium has specifically differentiated the two terminologies. Explicitly, the initial objective of cloudlet was to provide the mobile application a substitution from the distant cloud, in which the mobile applications can offload computing‐intensive tasks to the nearby cloudlet VM machines co‐located within the same Wi‐Fi subnet. By contrast, the initial introduction of fog computing aimed to complete the cloud by extending the cloud to the network gateways themselves. In essence, cloudlet can be seen as one of the practical approaches for fog computing when the co‐located physical server machines are available.
Certain other works have been describing multi‐access edge computing (MEC; formerly mobile edge computing) as an exchangeable term with fog. Essentially, ETSI introduced MEC as a standard from the perspective of telecommunication, in which ETSI specifies the application programming interface (API) standards about how telecommunication companies can provide computing virtualization‐based service to their clients based on extending the existing infrastructure used in network function virtualization (NFV), which has been already implemented in existing equipment such as cellular base transceiver stations (BTSs). Although it is inaccurate to describe MEC as an exchangeable term with fog, according to the recent collaboration between OpenFog and ETSI, MEC will become a practical approach to hasten the realization of fog computing [13].
Mist computing was an alternative term to fog in the earlier stages. However, recent works have described mist as a subset of fog. Accordingly, mist elaborates the need of distributing computing mechanism to the extreme edge of IoT, where the IoT devices are located, in order to minimize the communication latency between IoT devices in milliseconds [14–16]. Essentially, the motivation of mist computing is to grant the IoT devices with the capability of self‐awareness in terms of self‐organizing, self‐managing, and several self‐* mechanisms. Therefore, the IoT devices will be able to continuously operate even when the Internet connection is unstable.
In general, mist devices may sound similar to the embedded services or mobile Web services [17] in which the application services are hosted in heterogeneous resource‐constrained devices such as sensors, actuators, and mobile phones. However, mist emphasizes the capability of self‐awareness and situation‐awareness in which it allows dynamic and remotely (re)deploying software program code to the devices based on the situation and context changes [14]. Such a feature shares similarity with fog in providing a platform that allows flexible software deployment and reconfigurations.
Realizing that, the fog requires the support of all the related edge computing technologies. In other words, one is unable to deploy and manage fog without integrating edge computing technologies. Therefore, in the rest of this chapter, we use the term fog and edge computing (FEC) to describe the whole domain.
1.3 Fog and Edge Computing Completing the Cloud
FEC provides a complement to the cloud in IoT by filling the gap between cloud and things toward providing service continuum [3]. This section describes the advantages of FEC and addresses the question of how it achieves these advantages.
1.3.1 Advantages of FEC: SCALE
In particular, FEC offers five main advantages, which can be exemplified by SCALE—security, cognition, agility, latency, and efficiency [8].
1.3.1.1 Security
FEC supports additional security to IoT devices to ensure safety and trustworthiness in transactions. For example, today's wireless sensors deployed in outdoor environments often require a remote wireless source code update in order to resolve the security‐related issues. However, due to various dynamic environmental factors such as unstable signal strength, interruptions, constraint bandwidth etc., the distant central backend server may face challenges to perform the update swiftly and, hence, increases the chance of cybersecurity attack. On the other hand, if the FEC infrastructure is available, the backend can configure the best routing path among the entire network via various FEC nodes in order to rapidly perform the software security update to the wireless sensors.
1.3.1.2 Cognition
FEC enables the awareness of the objectives of their clients toward supporting autonomous decision‐making in terms of where and when to deploy computing, storage, and control functions. Essentially, the awareness of FEC, which involves a number of mechanisms in terms of self‐adaptation, self‐organization, self‐healing, self‐expression, and so forth [16], shifts the role of IoT devices from passive to active smart devices that can continuously operate and react to customer requirements without relying on the decision from the distant Cloud.
1.3.1.3 Agility
FEC enhances the agility of the large scope IoT system deployment. In contrast to the existing utility Cloud service business model, which relies on the large business holder to establish, deploy, and manage the fundamental infrastructure, FEC brings the opportunity to individual and small businesses to participate in providing FEC services using the common open software interfaces or open Software Development Kits (SDKs). For examples, the MEC standard of ETSI and the Indie Fog business model [18] will hasten the deployment of large‐scope IoT infrastructures.
1.3.1.4 Latency
The common understanding of FEC is to provide rapid responses for the applications that require ultra‐low latency. Specifically, in many ubiquitous applications and industrial automation, the system needs to collect and process the sensory data continuously in the form of the data stream in order to identify any event and to perform timely actions. Explicitly, by applying FEC, these systems are capable of supporting time‐sensitive functions. Moreover, the softwarization feature of FEC, in which the behavior of physical devices can be fully configured by the distant central server using software abstraction, provides a highly flexible platform for rapid re‐configuration of the IoT devices.
1.3.1.5 Efficiency
FEC enhances the efficiency of CIoT in terms of improving performance and reducing the unnecessary costs. For example, by applying FEC, the ubiquitous healthcare or eldercare system can distribute a number of tasks to the Internet gateway devices of the healthcare sensors and utilize the gateway devices to perform the sensory data analytics tasks. Ideally, since the process happens near the data source, the system can generate the result much faster. Further, since the system utilizes gateway devices to perform most of the tasks, it highly reduces the unnecessary cost of outgoing communication bandwidth.
1.3.2 How FEC Achieves These Advantages: SCANC
The high‐level description of the advantages provided by FEC leads to a question: How does FEC provide these advantages? To answer the question, here, we describe the five basic mechanisms supported by FEC‐enabled devices (FEC node; see Figure 1.2). Specifically, the mechanisms can be termed as SCANC, which corresponds to storage, compute, acceleration, networking, and control.
Figure 1.2FEC nodes supports five basic mechanisms—storage, compute, acceleration, networking, and control.
1.3.2.1 Storage
The mechanism of storage in FEC corresponds to the temporary data storing and caching at the FEC nodes in order to improve the performance of information or content delivery. For example, content service providers can perform multimedia content caching at the FEC nodes that are most close to their customers in order to improve the quality of experience [19]. Further, in connected vehicle scenarios, the connected vehicles can utilize the roadside FEC nodes to fetch and to share the information collected by the vehicles continuously.
1.3.2.2 Compute
FEC nodes provide the computing mechanisms mainly in two models—infrastructure or platform as a service (I/PaaS) and software as a service (SaaS). In general, FEC providers offer I/PaaS based on two approaches—hypervisor virtual machines (VMs) or containers engines (CEs), which enable flexible platforms for FEC clients to deploy the customized software they need in a sandbox environment hosted in FEC nodes. Besides the I/PaaS, the SaaS is also promising in FEC service provision [3]. To enumerate, SaaS providers can offer two types of services—on‐demand data processing (ODP) and context as a service (CaaS). Specifically, an ODP‐based service has pre‐installed methods that can process the data sent from the client in the request/response manner. Whereas, the CaaS‐based service provides a customized data provision method in which the FEC nodes can collect and process the data to generate meaningful information for their clients.
1.3.2.3 Acceleration
FEC provides acceleration with a key concept—programmable. Fundamentally, FEC nodes support acceleration in two aspects—networking acceleration and computing acceleration.
Networking acceleration
. Initially, most network operators have their own configuration for message routing paths and their clients are unable to request their own customized routing tables. For example, an Internet service provider (ISP) in East Europe may have two routing paths with different latency to reach a Web server located in Central Europe, and the path a client will be on is based on the ISP's load balancing setting, which in many cases is not the optimal option for the client. On the other hand, FEC supports a network acceleration mechanism based on network virtualization technology, which enables FEC nodes to operate multiple routing tables in parallel and to realize a software‐defined network (SDN). Therefore, the clients of the FEC nodes can configure customized routing path for their applications in order to achieve optimal network transmission speed.
Computing acceleration
. Researchers in fog computing have envisioned that the FEC nodes will provide computing acceleration by utilizing advanced embedded processing units such as graphics processing units (GPUs) or field programmable gate arrays (FPGA) units
[8]
. Specifically, utilizing GPUs to enhance the process of complex algorithms has become a common approach in general cloud computing. Therefore, it is foreseeable that FEC providers may also provide the equipment that contains middle‐ or high‐performance independent GPUs. Further, FPGA units allow users to redeploy program codes on them in order to improve or update the functions of the host devices. Particularly, researchers in sensor technologies
[20]
have been utilizing FPGA for runtime reconfiguration of sensors for quite some time. Further, in comparison with GPUs, FPGA has the potential to be a more energy‐efficient approach for providing the needed acceleration based on allowing clients to configure their customized code on the FEC nodes.
1.3.2.4 Networking
Networking of FEC involves vertical and horizontal connectivities. Vertical networking interconnects things and cloud with the IP networks; whereas, horizontal networking can be heterogeneous in network signals and protocols, depending on the supported hardware specification of the FEC nodes.
Vertical networking
. FEC nodes enable the vertical network using IP network‐based standard protocols such as the request/response‐based TCP/UDP sockets, HTTP, Internet Engineering Task Force (IETF) –Constraint Application Protocol (CoAP) or publish‐subscribe‐based Extensible Messaging and Presence Protocol (XMPP), OASIS – Advanced Message Queuing Protocol (AMQP; ISO/IEC 19464), Message Queue Telemetry Transport (MQTT; ISO/IEC PRF 20922), and so forth. Specifically, the IoT devices can operate server‐side functions (e.g. CoAP server) that allow FEC nodes, which act as the proxy of cloud, to collect data from them and then forward the data to the cloud. Further, FEC nodes can also operate as the message broker of publish‐subscribe‐based protocol that allows the IoT devices to publish data streams to the FEC nodes and enable the cloud backend to subscribe the data streams from the FEC nodes.
Horizontal networking
. Based on various optimization requirements such as energy efficiency or the network transmission efficiency, IoT systems are often using heterogeneous cost‐efficient networking approaches. In particular, smart home, smart factories, and connected vehicles are commonly utilizing Bluetooth, ZigBee (based on IEEE 802.15.4), and Z‐Wave on the IoT devices and connecting them to an IP network gateway toward enabling the connectivity between the devices and the backend cloud. In general, the IP network gateway devices are the ideal entities to host FEC servers since they have the connectivity with the IoT devices in various signals. For example, the cloud can request that an FEC server hosted in a connected car communicate with the roadside IoT equipment using ZigBee in order to collect the environmental information needed for analyzing the real‐time traffic situation.
1.3.2.5 Control
The control mechanism supported by FEC consists of four basic types – deployment, actuation, mediation, and security:
Deployment control
allows clients to perform customizable software program deployment dynamically. Further, clients can configure FEC nodes to control which program the FEC node should execute and when it should execute it. Further, FEC providers can also provide a complete FEC network topology as a service that allows clients to move their program from one FEC node to another. Moreover, the clients may also control multiple FEC nodes to achieve the optimal performance for their applications.
Actuation control
represents the mechanism supported by the hardware specification and the connectivities between the FEC nodes and the connected devices. Specifically, instead of performing direct interaction between the cloud and the devices, the cloud can delegate certain decisions to FEC nodes to directly control the behavior of IoT devices.
Mediation control
corresponds to the capability of FEC in terms of interacting with external entities owned by different parties. In particular, the connected vehicles supported by different service providers can communicate with one another, though they may not have a common protocol initially. With the softwarization feature of FEC node, the vehicles can have on‐demand software update toward enhancing their interoperability.
Security control
is the basic requirement of FEC nodes that allows clients to control the authentication, authorization, identity, and protection of the virtualized runtime environment operated on the FEC nodes.
1.4 Hierarchy of Fog and Edge Computing
In general, from the perspective of central cloud in the core network, CIoT systems can deploy FEC servers at three edge layers – inner‐edge, middle‐edge, and outer‐edge (see Figure 1.3). Here, we summarize the characteristics of each layer.
Figure 1.3Hierarchy of fog and edge computing.
1.4.1 Inner‐Edge
Inner‐edge (also known as near‐the‐edge [4]) corresponds to countrywide, statewide, and regional WAN of enterprises, ISPs, the data center of evolved packet core (EPC) and metropolitan area network (MAN). Initially, service providers at inner‐edge only offer the fundamental infrastructures for connecting local networks to the global Internet. However, the recent needs in improving the quality of experience (QoE) of Web services have motivated the geo‐distributed caching and processing mechanism at the network data centers of WAN. For example, in the commercial service aspect, Google Edge Network (peering.google.com) collaborates with ISPs to distribute data servers at the ISPs' data centers in order to improve the response speed of Google's cloud services. Further, many ISPs (e.g. AT&T, Telstra, Vodafone, Deutsche Telekom etc.) are aware that many local businesses require low latency cloud and hence, they have offered local cloud within the country. Based on the reference architecture of fog computing [8], the WAN‐based cloud data centers can be considered as the fog of inner‐edge.
1.4.2 Middle‐Edge
Middle‐edge corresponds to the environment of the most common understanding of FEC, which consists of two types of networks—local area network (LANs) and cellular network. To summarize, LANs include ethernet, wireless LANs (WLANs) and campus area network (CANs). The cellular network consists of the macrocell, microcell, picocell, and femtocell. Explicitly, middle‐edge covers a broad range of equipment to host FEC servers.
1.4.2.1 Local Area Network
The emerging Fog computing architecture introduced by Cisco's research [7] was utilizing Internet gateway devices (e.g. Cisco IR829 Industrial Integrated Router) to provide the similar model as utility Cloud services in which the gateway devices provide virtualization technologies that allow the gateway devices to support FEC mechanisms mentioned previously. Further, it is also an ideal solution to utilize the virtualization technology‐enabled server computers located within the same subnet of LAN or CAN (i.e. within the one‐hop range between the IoT device and the computer) with the FEC nodes. Ordinarily, such an approach is also known as local cloud, local data center or cloudlet.
1.4.2.2 Cellular Network
The idea of providing FEC mechanisms derived from the existing network virtualization technologies that have been used in various cellular networks. In general, most developed cities have wide coverage of cellular networks provided by numerous types of BTSs, which are the ideal facilities to serve as roadside FEC hosts for various mobile IoT use cases such as connected vehicles, mobile healthcare, and virtual or augmented reality, which require rapid process and response on the real‐time data stream. Therefore, major telecommunication infrastructure and equipment providers such as Nokia, ADLink, or Huawei have started providing MEC‐enabled hardware and infrastructure solutions. Accordingly, it is foreseeable that in the near future, cellular network‐based FEC will be available in a broad range of related equipment, from macrocell and microcell BTSs to the indoor cellular extension equipment such as picocell and femtocell [21]
