reading

Cover
Title Page
CONTRIBUTORS
Introduction
1. I.1 SUMMARY OF CHAPTERS
2. I.2 ACKNOWLEDGMENTS
3. REFERENCES
PART I: Communication and Management of Fog
1. 1 ParaDrop
  1. 1.1 INTRODUCTION
  2. 1.2 IMPLEMENTING SERVICES FOR THE PARADROP PLATFORM
  3. 1.3 DEVELOP SERVICES FOR PARADROP
  4. REFERENCES
2. 2 Mind Your Own Bandwidth
  1. 2.1 INTRODUCTION
  2. 2.2 RELATED WORK
  3. 2.3 CREDIT DISTRIBUTION AND OPTIMAL SPENDING
  4. 2.4 AN ONLINE BANDWIDTH ALLOCATION ALGORITHM
  5. 2.5 DESIGN AND IMPLEMENTATION
  6. 2.6 EXPERIMENTAL RESULTS
  7. 2.7 GATEWAY SHARING RESULTS
  8. 2.8 CONCLUDING REMARKS
  9. ACKNOWLEDGMENTS
  10. APPENDIX 2.A
  11. REFERENCES
3. 3 Socially‐Aware Cooperative D2D and D4D Communications toward Fog Networking
  1. 3.1 INTRODUCTION
  2. 3.2 RELATED WORK
  3. 3.3 SYSTEM MODEL
  4. 3.4 SOCIALLY‐AWARE COOPERATIVE D2D AND D4D COMMUNICATIONS TOWARD FOG NETWORKING
  5. 3.5 NETWORK ASSISTED RELAY SELECTION MECHANISM
  6. 3.6 SIMULATIONS
  7. 3.7 CONCLUSION
  8. ACKNOWLEDGMENTS
  9. REFERENCES
4. 4 You Deserve Better Properties (From Your Smart Devices)
  1. 4.1 WHY WE NEED TO PROVIDE BETTER PROPERTIES
  2. 4.2 WHERE WE NEED TO PROVIDE BETTER PROPERTIES
  3. 4.3 WHAT PROPERTIES WE NEED TO PROVIDE AND HOW
  4. 4.4 CONCLUSIONS
  5. ACKNOWLEDGMENT
  6. REFERENCES
PART II: Storage and Computation in Fog
1. 5 Distributed Caching for Enhancing Communications Efficiency
  1. 5.1 INTRODUCTION
  2. 5.2 FEMTOCACHING
  3. 5.3 USER‐CACHING
  4. 5.4 CONCLUSIONS AND OUTLOOK
  5. REFERENCES
2. 6 Wireless Video Fog
  1. 6.1 INTRODUCTION
  2. 6.2 RELATED WORK
  3. 6.3 SYSTEM OPERATION AND NETWORK MODEL
  4. 6.4 PROBLEM FORMULATION AND COMPLEXITY
  5. 6.5 VBCR: A DISTRIBUTED HEURISTIC FOR LIVE VIDEO WITH COOPERATIVE RECOVERY
  6. 6.6 ILLUSTRATIVE SIMULATION RESULTS
  7. 6.7 CONCLUDING REMARKS
  8. REFERENCES
3. 7 Elastic Mobile Device Clouds
  1. 7.1 INTRODUCTION
  2. 7.2 DESIGN SPACE WITH EXAMPLES
  3. 7.3 FEMTOCLOUD PERFORMANCE EVALUATION
  4. 7.4 SERENDIPITY PERFORMANCE EVALUATION
  5. 7.5 CHALLENGES
  6. REFERENCES
PART III: Applications of Fog
1. 8 The Role of Fog Computing in the Future of the Automobile
  1. 8.1 INTRODUCTION
  2. 8.2 CURRENT AUTOMOBILE ELECTRONIC ARCHITECTURES
  3. 8.3 FUTURE CHALLENGES OF AUTOMOTIVE E/E ARCHITECTURES AND SOLUTION STRATEGIES
  4. 8.4 FUTURE AUTOMOBILES AS FOG NODES ON WHEELS
  5. 8.5 DETERMINISTIC FOG NODES ON WHEELS THROUGH REAL‐TIME COMPUTING AND TIME‐TRIGGERED TECHNOLOGIES
  6. 8.6 CONCLUSION
  7. REFERENCES
2. 9 Geographic Addressing for Field Networks
  1. 9.1 INTRODUCTION
  2. 9.2 GEOGRAPHIC ADDRESSING
  3. 9.3 SAGP: WIRELESS GA IN THE FIELD
  4. 9.4 GEOROUTING: EXTENDING GA TO THE CLOUD
  5. 9.5 SGAF: A MULTI‐TIERED ARCHITECTURE FOR LARGE‐SCALE GA
  6. 9.6 THE AT&T LABS GEOCAST SYSTEM
  7. 9.7 TWO GA APPLICATIONS
  8. 9.8 CONCLUSIONS
  9. REFERENCES
3. 10 Distributed Online Learning and Stream Processing for a Smarter Planet
  1. 10.1 INTRODUCTION: SMARTER PLANET
  2. 10.2 ILLUSTRATIVE PROBLEM: TRANSPORTATION
  3. 10.3 STREAM PROCESSING CHARACTERISTICS
  4. 10.4 DISTRIBUTED STREAM PROCESSING SYSTEMS
  5. 10.5 DISTRIBUTED ONLINE LEARNING FRAMEWORKS
  6. 10.6 WHAT LIES AHEAD
  7. ACKNOWLEDGMENT
  8. REFERENCES
4. 11 Securing the Internet of Things
  1. 11.1 INTRODUCTION
  2. 11.2 NEW IOT SECURITY CHALLENGES THAT NECESSITATE FUNDAMENTAL CHANGES TO THE EXISTING SECURITY PARADIGM
  3. 11.3 A NEW SECURITY PARADIGM FOR THE INTERNET OF THINGS
  4. 11.4 SUMMARY
  5. ACKNOWLEDGMENT
  6. REFERENCES
Index
WILEY SERIES ON INFORMATION AND COMMUNICATION TECHNOLOGY
End User License Agreement

List of Tables

Chapter 02
1. TABLE 2.1 Number of Devices at Each Gateway
Chapter 03
1. TABLE 3.1 The Preference Lists of Nodes Based on the Physical Graph and Social Graph in Figure 3.2
Chapter 05
1. TABLE 5.1 The Average User Throughput Comparison Between the Cluster‐Based and ITLinQ Delivery Schemes
Chapter 06
1. TABLE 6.1 Symbols Used in the Paper
2. TABLE 6.2 Baseline Parameters of the Simulation
Chapter 07
1. TABLE 7.1 A Summary of Different System Assumptions
2. TABLE 7.2 FemtoCloud Experimental Device’s Characteristics
3. TABLE 7.3 FemtoCloud Experiment Tasks Characteristics and Evaluation Parameters
4. TABLE 7.4 FemtoCloud Experiment Parameters
5. TABLE 7.5 Prototype Performance Measurements
Chapter 10
1. TABLE 10.1 Data Management Systems and Their Support for SPA Requirements
2. TABLE 10.2 Example of Streams Programming to Realize Congestion Prediction Application Flowgraph
Chapter 11
1. TABLE 11.1 Ways to Determine the Trustworthiness of Another Device

List of Illustrations

Chapter 0
1. Figure I.1 Fog architectures and applications. Supported by such architectures.
Chapter 01
1. Figure 1.1 The fully implemented ParaDrop platform on the Wi‐Fi home gateway, which shares its resources with two wireless devices including a security camera and environment sensor.
2. Figure 1.2 The dashed box shows the block diagram representation of a “chute” installed on a ParaDrop‐enabled access point. Each chute hosts a stand‐alone service and has its own network subnet.
3. Figure 1.3 An example Chute.struct file, which is used to specify the key configuration parameters of a chute that hosts a stand‐alone service. Parameters such as CPU, memory, disk requirements, and network configurations are specified as JSON key–value pairs. ParaDrop provides chute configuration templates to developers, which can customized based on application requirements.
4. Figure 1.4 The primary Chute.struct component for the SecCam chute.
5. Figure 1.5 The Chute.files component lists the files required for the SecCam chute.
6. Figure 1.6 The Chute.resource component specifies the resource consumption limits for the SecCam chute.
7. Figure 1.7 The Chute.runtime component for the SecCam chute.
8. Figure 1.8 The Chute.traffic component allows users to access data within the SecCam chute.
Chapter 02
1. Figure 2.1 Hierarchical edge‐based bandwidth allocation.
2. Figure 2.2 System architecture. Dashed lines represent traffic flow, and solid lines represent rate and credit information.
3. Figure 2.3 Screenshots of the web interface. (a) Usage tracking and (b) traffic priorities and device/OS classification.
4. Figure 2.4 Receive buffer model.
5. Figure 2.5 Our rate limiting algorithm is (a) more accurate than tc and (b, c) more graceful than rate limiting. We average all results over 10 runs, 60 seconds each, and show 95% confidence intervals.
6. Figure 2.6 YouTube playback performance improves as α₁/α₂ increases and YouTube receives higher prioritization over wget.
7. Figure 2.7 With our credit sharing scheme, all gateways (a) achieve comparable cumulative rates by (b) actively saving and spending credits at different times.
8. Figure 2.8 With our credit sharing scheme, users achieve similar utility gains over equal sharing over 1 week.
9. Figure 2.9 Despite their uncertain future budgets, with our online algorithm gateways (a) achieve comparable cumulative rates by (b) saving and spending credits at different times over 1 week.
Chapter 03
1. Figure 3.1 An illustration of cooperative D2D and D4D communication for cooperative networking. In sub‐figure (a), device R serves as the relay for the D2D communication between devices S and D. In sub‐figure (b), device R serves as the relay for the cellular communication between device S and the base station. In both cases, the D2D communication between devices S and R is part of cooperative networking.
2. Figure 3.2 An illustration of the social trust model for cooperative D2D communications. In the physical domain, different devices have different feasible cooperation relationships subject to physical constraints. In the social domain, different devices have different assistance relationships based on social trust among the devices.
3. Figure 3.3 Illustrative smart grid IoT devices. (a) Our outlet device with a Texas Instrument Microcontroller Board and XBee radio module; (b) Raspberry Pi to emulate a smartmeter or controller device.
4. Figure 3.4 The physical–social graph based on the physical graph and social graph in Figure 3.2. For example, there exists an edge between nodes 1 and 3 in the physical–social graph since they can serve as the feasible relay for each other and also have social trust toward each other.
5. Figure 3.5 An illustration of direct and indirect reciprocity.
6. Figure 3.6 The physical‐coalitional graph based on the physical graph and social graph in Figure 3.7. For example, there exists an edge between nodes 1 and 2 in the physical‐coalitional graph since they can serve as the feasible relay for each other and have no social trust toward each other.
7. Figure 3.7 An illustration of the resulting graphs at each iteration t of the core relay selection algorithm. (a) , (b) , (c) , and .
8. Figure 3.8 The reciprocal relay selection cycles identified by the core relay selection algorithm in Figure 3.7.
9. Figure 3.9 System throughput with the number of nodes and different social network density.
10. Figure 3.10 Average size of the reciprocal relay selection cycles in the social trust and social reciprocity‐based relay selection with and different social network density.
11. Figure 3.11 System throughput of nodes and different distance threshold δ for relay detection.
12. Figure 3.12 The number of social links of the social graphs based on real trace Brightkite.
13. Figure 3.13 Average system throughput with different number of nodes.
14. Figure 3.14 Normalized energy efficiency with different number of nodes.
15. Figure 3.15 Average number of iterations of the NARS mechanism.
16. Figure 3.16 Average running time of the NARS mechanism.
Chapter 04
1. Figure 4.1 BlueSeal information flow permission screenshot.
2. Figure 4.2 AsyncTask code snippet.
3. Figure 4.3 AsyncTask flow.
4. Figure 4.4 Simplified Android architecture.
5. Figure 4.5 Android sensor architecture.
6. Figure 4.6 RTDroid architecture.
7. Figure 4.7 RTDroid sensor architecture.
8. Figure 4.8 Performance comparison between RTDroid and Android.
9. Figure 4.9 Storage API virtualization and its example extension.
Chapter 05
1. Figure 5.1 System model for femtocaching.
2. Figure 5.2 (a) Grid network with nodes (black circles) with minimum separation . (b) An example of single‐cell layout and the interference avoidance TDMA scheme. In this figure, each square represents a cluster. The grey squares represent the concurrent transmitting clusters. The highlighted circular area is the disk where the protocol model allows no other concurrent transmission. r is the worst‐case transmission range and Δ is the interference parameter. We assume a common r for all the transmitter–receiver pairs. In this particular example, the TDMA parameter is , which means that each cluster can be activated every nine transmission scheduling slot durations.
3. Figure 5.3 Comparison between the normalized theoretical result (solid lines) and normalized simulated result (dashed lines) in terms of the minimum throughput per user versus outage probability. The throughput is normalized by C_r so that it is independent of the link rate. We assume , , and and reuse factor . The parameter γ_r for the Zipf distribution varies from 0.1 to 0.6, which are shown from the rightmost curves to the leftmost curves. The theoretical curves show the plots of the dominating term in (5.14) divided by C_r.
4. Figure 5.4 A deterministic view of the optimality condition for treating interference as noise.
5. Figure 5.5 Comparison of the achievable spectral reuse of cached ITLinQ and interference avoidance for the case of and .
6. Figure 5.6 Comparison of CDF of the achievable rates of users under the cluster‐based and ITLinQ schemes in the small library regime.
7. Figure 5.7 Comparison of CDF of the achievable rates of users under the cluster‐based and ITLinQ schemes in the large library regime.
8. Figure 5.8 Simulation results for the throughput–outage trade‐off for different schemes under the realistic indoor/outdoor propagation environment (for details, see Ref. [29]). For harmonic broadcasting with only the m′ most popular files, solid line: ; dash–dot line: ; dash line: . We have , , , and .
9. Figure 5.9 Potential spectral gain of blind index coding.
10. Figure 5.10 Illustration of the example of three users, three files, and , achieving 1/2 transmissions in term of file. We divide each file into six packets (e.g., A is divided into A₁, …, A₆). User 1 requests A, user 2 requests B, and user 3 requests C. The cached packets are shown in the rectangles under each user. For the delivery phase, user 1 transmits , user 2 transmits , and user 3 transmits . The normalized number of transmissions is , which is also information theoretically optimal for this network [16].
Chapter 06
1. Figure 6.1 Illustration of wireless fog. The source node pulls the video stream from the streaming cloud and broadcasts the stream to other clients within the fog in a multihop manner.
2. Figure 6.2 A representation of a wireless streaming mesh, with nodes arranged according to their shortest distance to the source node.
3. Figure 6.3 Slot‐based operations. “pkt” stands for “packet”.
4. Figure 6.4 An example beacon packet format for the case that . The beacon contains one bitmap for video packet availability and a bitmap for each buffered NC packet. IDs of any downstream nodes are also appended in UIX beacon exchange. For different sizes, bitmap lengths can be adjusted accordingly. R is a reserved 1‐bit field.
5. Figure 6.5 Flowchart of NC‐based cooperative recovery.
6. Figure 6.6 Flowchart of video packet forwarding.
7. Figure 6.7 Loss rate versus network size.
8. Figure 6.8 Network traffic versus network size.
9. Figure 6.9 Video PSNR versus network size.
10. Figure 6.10 Network traffic vs. link loss rate.
11. Figure 6.11 VBCR network traffic composition.
12. Figure 6.12 Number of parents for each node.
13. Figure 6.13 Histogram of the number of parents in VBCR.
Chapter 07
1. Figure 7.1 Mobile cluster stability spectrum.
2. Figure 7.2 Elastic mobile‐device clouds architecture.
3. Figure 7.3 Impact of device arrival rate and presence time. (a) Computational throughput, (b) network utilization, and (c) computational resource utilization.
4. Figure 7.4 Impact of cluster stability. (a) Computational throughput, (b) network utilization, and (c) computational resource utilization.
5. Figure 7.5 Impact of task characteristics. (a) Computational resource utilization and (b) network utilization.
6. Figure 7.6 Robustness to estimation errors. (a) Computational resource utilization and (b) network utilization.
7. Figure 7.7 A comparison of Serendipity’s performance benefits. The average job completion times with their 95% confidence intervals are plotted. We use two data traces, Haggle and RollerNet, to emulate the node contacts and three input sizes for each. (a) 10 tasks, (b) 100 tasks, and (c) 300 tasks.
8. Figure 7.8 The load distribution of Serendipity nodes when there are 100 tasks total, each of which takes 2 Mb input data. (a) RollerNet and (b) Haggle.
9. Figure 7.9 The impact of wireless bandwidth on the performance of Serendipity. The average job completion times are plotted when the bandwidth is 1, 5.5, 11, 24, and 54 Mb/s, respectively. (a) RollerNet and (b) Haggle.
10. Figure 7.10 The impact of node mobility on Serendipity. We generate the contact traces for 10 nodes in a area. In (a) we set the node speed to be 5 m/s, while in (b) we use Levy Walk as the mobility model.
11. Figure 7.11 The impact of node numbers on the performance of Serendipity. We analyze the impact of both node number and node density by fixing the activity area and setting it proportional to the node numbers, respectively. (a) Fixed active area and (b) fixed node density.
12. Figure 7.12 Serendipity’s performance with multiple jobs executed simultaneously. The job arrival time follows a Poisson distribution with varying arrival rates. (a) RollerNet and (b) Haggle.
13. Figure 7.13 A job example where both PNP‐block B and C are disseminated to Serendipity nodes after A completes. Their task positions in the nodes’ task lists are shown blow the DAG.
14. Figure 7.14 The importance of assigning priorities to PNP‐blocks.
Chapter 08
1. Figure 8.1 The future automobile as fog computing on wheels.
2. Figure 8.2 Traditional E/E automobile architecture.
3. Figure 8.3 Example of an automotive ECU, the TTA drive platform from TTTech (inner structure and with automotive‐grade housing).
4. Figure 8.4 The IoT virtuous information cycle.
5. Figure 8.5 Example of automotive network.
6. Figure 8.6 Example of communication schedule in time‐triggered communication.
7. Figure 8.7 Future automotive E/E architecture.
8. Figure 8.8 Classical system architecture versus virtualization.
9. Figure 8.9 Ethernet frame format.
10. Figure 8.10 (a) Example of network and (b) communication scenario of the IEEE 802.1Qbv “time‐aware shaper.”
11. Figure 8.11 Example of vehicle‐wide virtualization (VWV).
Chapter 09
1. Figure 9.1 Sender, geocast region, and forwarding zone.
2. Figure 9.2 Example of a geocast propagated via SAGP.
3. Figure 9.3 Pictorial proof idea showing why SAGP only uses O(lg n) transmissions per geocast in dense scenarios. The originator is somewhere to the left of the diagram; the intuition is that, on average, successive transmissions will occur at devices approximately half way to the CGR.
4. Figure 9.4 Example SAGP geocast propagation, with arrows showing the useful relays.
5. Figure 9.5 Packet transmission in the georouter tier.
6. Figure 9.6 A notional example of a large‐scale GA system built by bridging together many individual GA tiers. Rectangles represent georouter tiers, while dashed ovals represent geocast tiers.
7. Figure 9.7 An example propagation across multiple tiers using bridging. Starting at A, the packet first traverses the geocast tier around A, then up through the georouter tier, and then back “down” into the georouter tier near the geocast region. Finally, it traverses that tier to reach the GR.
8. Figure 9.8 Schematic diagram of the AT&T Labs Geocast System.
9. Figure 9.9 Screen capture of the PSCommander smartphone application.
10. Figure 9.10 The FCOP problem illustrated. (a) The general monitoring problem and (b) the common operating picture special case.
11. Figure 9.11 Graph of bytes per second used by the FCOP algorithm in a dense scenario, divided by n lg n versus number of devices n.
12. Figure 9.12 Typical iTron game, showing both real‐world and virtual‐world views.
13. Figure 9.13 Final screenshot of the championship iTron match played at the culmination of a multi‐week iTron teaching unit in a NJ high school Physical Education class. It was played at a larger scale, and players exploited different terrain types.
Chapter 10
1. Figure 10.1 Smarter transportation: individuals and city.
2. Figure 10.2 Distributed learning needed for real‐time signage update.
3. Figure 10.3 From logical operator flowgraphs to deployment.
4. Figure 10.4 Possible trade‐offs with parallelism and placement.
5. Figure 10.5 Flow of information toward learner 1 at time slot n for a binary tree network.
6. Figure 10.6 System model described in Section 10.5.2.
7. Figure 10.7 A comparison between the proposed algorithm and the combine‐then‐adapt (CTA) scheme in terms of information dissemination and weight update rule. Unlike diffusion, in the proposed approach the weight vectors do not need to be disseminated.
8. Figure 10.8 A generic speed sensor i must detect collisions in real time and inform the drivers (left). To achieve this goal sensor i receives the observations from the other sensors, and the flow of information is represented by a directed graph (right).
9. Figure 10.9 Illustration of the considered notations.
Chapter 11
1. Figure 11.1 Fog computing and fog‐based security services to help protect resource‐constrained devices and systems.
2. Figure 11.2 Hierarchical crowd attestation.

Pages

This edition first published 2017
© 2017 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 permision to reuse material from this title is available at http://www.wiley.com/go/permissions.

The right of Mung Chiang, Bharath Balasubramanian, and Flavio Bonomi to be identified as 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 author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. It is sold on the understanding that the publisher is not engaged in rendering professional services and neither the publisher nor the author shall be liable for damages arising herefrom. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

The advice and strategies contained herein may not be suitable for every situation. In view of ongoing research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. No warranty may be created or extended by any promotional statements for this work. Neither the publisher nor the author shall be liable for any damages arising herefrom.

Library of Congress Cataloging‐in‐Publication Data

Names: Chiang, Mung, editor. | Balasubramanian, Bharath, editor. | Bonomi,
Flavio, editor.
Title: Fog for 5G and IoT/edited by Mung Chiang, Bharath Balasubramanian, Flavio Bonomi.
Description: Hoboken, NJ, USA : John Wiley & Sons Inc., 2017. | Includes
bibliographical references and index.
Identifiers: LCCN 2016042091| ISBN 9781119187134 (cloth) | ISBN 9781119187172 (epub) | ISBN 9781119187158 (epdf)
Subjects: LCSH: Electronic data processing–Distributed processing. | Distributed shared memory. | Storage area networks (Computer networks) | Mobile computing. | Internet of things. | Cloud computing.
Classification: LCC QA76.9.D5 F636 2017 | DDC 004.67/82–dc23
LC record available at https://lccn.loc.gov/2016042091

Cover image: Cultura/Seb Oliver/Gettyimages
Cover design by Wiley