🌫️ Chapter 14 — Edge Computing & Fog Computing Cheat Sheet

Big Picture: As IoT and mobile devices explode, centralizing everything in the cloud creates latency, bandwidth, and privacy bottlenecks. The solution is to push intelligence closer to where data is born — via Edge, Fog, and Mist computing.

🗺️ Part 1 — The Computing Spectrum (Where Does Processing Happen?)

IoT Device / Sensor
       ↓ (Mist Computing — on the device itself)
Edge Node / Gateway / Access Point
       ↓ (Edge Computing — one hop away)
Fog Node / Local Server / Cloudlet
       ↓ (Fog Computing — intermediate layer)
Cloud Data Center
       ↓ (Cloud Computing — centralized, far away)

🧑‍🍳 Analogy: Mist = cook at your table; Edge = kitchen on your floor; Fog = restaurant kitchen nearby; Cloud = central factory producing all food.

📡 Part 2 — 5G & 6G: Why Network Speed Matters for Edge

Edge computing unleashes the full potential of 5G by combining ultra-low latency with local processing.

Use Cases by Generation

What 5G + Edge Enables Together

• VR/AR — instant rendering without cloud round-trip
• Gamification — real-time interactive games
• Drone control — sub-millisecond response loops
• Connected cars — V2X (vehicle-to-everything) low-latency decisions
• Real-time collaboration — simultaneous multi-user interaction

🖥️ Part 3 — Edge Computing

What is Edge Computing?

• Processing and computing client data closer to the data source (sensors, gateways, base stations)
• Goal: minimize latency and bandwidth usage
• Data stays local → enhances privacy and security

🍱 Analogy: Edge = a mini kitchen on each floor of an office building — food (data) gets prepared right where people work, instead of everyone going to one giant kitchen in the basement (centralized cloud).

Edge Computing Architecture (3 Layers)

Layer 1: Device Layer
  → Sensors & Controllers (data originates here)

Layer 2: Edge Layer (the key addition)
  → Edge Node / Server
  → Data Processing & Reduction
  → Data Caching & Buffering
  → Control Response
  → Virtualization

Layer 3: Cloud Layer
  → Big data processing
  → Data warehousing & long-term storage

The Edge Layer exists to reduce latency — process what you can locally, send only what's necessary to the cloud.

Edge vs. Cloud

Edge Pros & Use Cases

Key Difference from Fog

Edge = computing happens directly on or physically next to the devices/sensors Fog = computing happens at an intermediate layer (local server, router, cloudlet) between edge and cloud

🌁 Part 4 — Mist Computing (Extreme Edge)

What is Mist Computing?

• Also called "nano-edge" computing
• Pushes computation to the extreme edge — onto end devices themselves (smart sensors, microcontrollers, embedded systems)
• Devices perform preprocessing or lightweight analytics entirely on-board
• Supports autonomous decision-making without any upstream communication

🧠 Analogy: Mist = a person making instant decisions on the spot. Fog = their supervisor nearby for complex decisions. Cloud = HQ far away for strategic decisions.

Characteristics

• Often battery-powered or resource-constrained devices
• Computation via microchips or microcontrollers → very limited processing power
• Supports fail-safe operations — works even with no connectivity

Mist Pros & Use Cases

Mist + Fog Relationship

• Complementary, not competing:
  • Computationally heavy tasks → Fog (gateway)
  • Simple, lightweight tasks → Mist (end device)

🌫️ Part 5 — Fog Computing (Deep Dive)

What is Fog Computing?

• Term coined by Cisco in 2014
• The layer below the cloud — manages connections between cloud and network edge
• Brings cloud capabilities down to the ground (just as fog in nature is closer to earth than clouds)

🏭 Analogy: Fog = a network of local warehouses spread across a city, handling deliveries close to customers. Cloud = the central factory doing large-scale production.

Key Characteristics of Fog

• Extends cloud computing to the network edge
• Low latency + location awareness
• Handles volume, variety, velocity of IoT data
• Sends only the right data up to the cloud for big data analytics
• Wide geographic distribution
• Strong presence of streaming and real-time applications
• Heterogeneous connected objects
• Communicates directly with mobile devices
• Predominantly wireless access

Fog as a Platform

Fog = the distributed, hierarchically organized platform where the Internet meets the physical world at Machine-to-Machine (M2M) scale.

🧱 Part 6 — Fog Computing Platform Architecture

FC Software Stack

Business Applications
├── Cloud Infrastructure Software  (Portals, Services, Resources)
├── Fog Management Software        (Lifecycle mgmt, Orchestration, APIs/SDKs)
├── Fog Infrastructure Software    (Execution env, OS, Virtual network functions)
└── Fog Hardware                   (Networking, Compute, Storage)
           ↕
         Things (IoT Devices)

Cross-cutting: Policy/Security | Analytics & Data Models

Technology Components

Fog uses policy-based orchestration on top of the resource virtualization layer + exposes APIs for app development.

Hardware/Software Layers

Key Software Components

🌿 Part 7 — Fog Computing Taxonomy

Main branches of fog computing design space:

🌍 Part 8 — Benefits of Fog Computing

Industries Using Fog

Energy | Manufacturing | Construction | Oil & Gas | Transportation | Finance | Telecom | Healthcare | Retail | Smart Cities | Agriculture

What Fog Enables

Fog distributes core functions:

• Computation, Storage, Communication, Control, Decision Making

Fog helps devices:

• Measure, Monitor, Process, Analyze, React

Fog Advantages Summary

Fog Disadvantages

☁️ Part 9 — Cloud vs. Fog Comparison

Performance & Security

Data at rest = stored in DB/file | Data in transit/motion/flight = being transferred over network

Architecture & Connectivity

📊 Part 10 — How Fog Helps Cloud (Both Directions)

Pushing Intelligence Up → Cloud Challenges

Pushing Intelligence Down → Endpoint Challenges

🔄 Part 11 — IoT + Fog: Data Flow Today vs. Tomorrow

IoT with Fog Architecture (3 Layers)

Layer 1: Device
  → Local data collection (sensors, actuators)

Layer 2: FOG (IOx)
  → Local data analysis and filtering
  → Apply: Rules, Patterns, Actions
  → Data Reduction, Control Response, Data Virtualization

Layer 3: Cloud / Data Center
  → Non-real-time action
  → Long-term storage
  → Machine learning, historic/predictive analysis
  → Sends back: Rule and Pattern Updates

Data Flow Evolution

⚖️ Part 12 — Fog Computing vs. MEC vs. Cloudlet

Common to all three: Computing at the edge + virtualization supported

⚠️ Intra-node offloading is also possible — a single node can have multiple internal compute units, requiring internal load balancing and scheduling too. (Final Exam topic!)

OpenFog Consortium

Founded by: ARM, Cisco, Dell, Intel, Microsoft, Princeton University
Mission: Drive industry and academic leadership in fog computing architecture, testbed development, and interoperability deliverables that seamlessly leverage cloud and edge for end-to-end IoT.

🔁 Part 13 — Offloading: F2F and F2C ⚠️ Final Exam Topic!

Overview

When a fog node gets overloaded (e.g., >80% utilization), it offloads to:

🚦 Rule of thumb: Real-time response → F2F first. Global scale or heavy compute → F2C.

Load Monitoring: Utilization Formula

$\boxed{\rho_i = \frac{L_i}{C_i}}$

• $L_i$ = Current load of fog node $F_i$
• $C_i$ = Capacity of fog node $F_i$
• $\rho_i$ = Utilization ratio (like CPU usage %)

Load Status:

• Overloaded: $\rho_i > \tau_{\text{high}}$
• Underloaded: $\rho_i < \tau_{\text{low}}$

💻 Analogy: $\rho_i$ = CPU usage % in your Mac Activity Monitor. If it spikes past a threshold, delegate tasks to a less busy neighbor.

📐 Part 14 — F2F Load Sharing: 4-Step Mechanism ⚠️ Final Exam!

Step 1: Load Monitoring

• Each fog node periodically computes its own utilization: $\rho_i = \frac{L_i}{C_i}$
• Enables real-time system-wide awareness

Step 2: Neighbor Discovery

• Define the neighbor set (only low-latency neighbors considered): $\mathcal{N}_i = {F_j \mid \text{latency}(i,j) < \delta}$
• $\delta$ = maximum acceptable latency threshold

Step 3: Decision Rule

• If $F_i$ is overloaded → find a neighbor that is underloaded: $\exists F_j \in \mathcal{N}_i \text{ such that } \rho_j < \tau_{\text{low}}$

Step 4: Optimal Target Selection

$\boxed{F_j^* = \arg\min_{F_j \in \mathcal{N}_i} \left(\alpha \cdot \rho_j + \beta \cdot \text{latency}_{i,j}\right)}$

• $\alpha$ = weight for load balancing (how much you care about CPU balance)
• $\beta$ = weight for latency minimization (how much you care about speed)
• Choose the neighbor that minimizes the combined weighted cost

Task Offloading

$\boxed{\mathcal{T}: F_i \rightarrow F_j^*}$

Task $\mathcal{T}$ is migrated from overloaded $F_i$ to optimal neighbor $F_j^*$.

⚠️ Load is redistributed within the fog layer first — not sent to the cloud immediately.

F2F Load Sharing Strategies

🔐 Part 15 — Secure Task Offloading: Blockchain-Based (F2F) ⚠️ Final Exam: Design Algorithm as Sequence Diagram / Pseudocode!

Source: R. Roshan et al., GLOBECOM 2020

Why Blockchain for Fog Security?

Standard fog offloading has a trust problem — how does one fog node know another is legitimate before offloading sensitive tasks to it?
Solution: Use blockchain + smart contracts as a decentralized trust layer.

Phase 1: Joining & Registration on Blockchain

New Fog Node Joins Network
        ↓
Registers with unique credentials on the Blockchain
        ↓
Identity + Registration Timestamp stored as a transaction
        ↓
Smart Contracts used to:
   • Authenticate fog nodes
   • Handle communication between fog nodes

• Every node that joins the fog network also joins the blockchain
• Smart Contracts = programmable policies stored on blockchain → automate authentication + communication rules

Phase 2: Secure Fog Node Selection (Rank System)

When a fog node needs to offload, it selects a secondary node based on rank:

Selection Logic:

1. All new nodes start at rank 0
2. N_i (high rank) wants to offload to N_k (new node, rank 0)
   → Mutual verification depends on whether rank meets threshold
3. N_i verifies N_k via cloud token system
4. N_k verifies N_i directly via rank from smart contract
5. On success → both ranks updated on blockchain

Phase 3: Token-Based Cloud Verification (PKI)

Used when a fog node does NOT meet the required rank threshold for direct verification.

N_k (unverified node)  →  Request token from Cloud at time t_req
Cloud                  →  Compute token:

$\boxed{token_{req} = [t_{req},\ N_k]\ Pu_{key-cloud}}$

token_req  →  Presented to N_i
N_i        →  Verifies token via cloud (checks authenticity + freshness)
           →  If valid: trust established, offloading proceeds

• Uses Public Key Infrastructure (PKI)
• Token includes timestamp $t_{req}$ → prevents replay attacks (freshness check)
• Cloud acts as trusted third-party verifier for unknown nodes

Full Blockchain F2F Flow (Sequence Summary)

Fog Node N_i (overloaded)
  │ 1. Check own ρ_i > τ_high
  │ 2. Discover neighbors N(i)
  │ 3. Select candidate N_k
  │
  ├── If N_k rank ≥ threshold:
  │       N_k verifies N_i via smart contract rank
  │       N_i verifies N_k via smart contract rank
  │       → Both pass → offload task → update both ranks on blockchain
  │
  └── If N_k rank < threshold:
          N_k requests token from Cloud
          Cloud issues: token = [t_req, N_k] Pu_key-cloud
          N_k presents token to N_i
          N_i verifies token via cloud
          → Verified → offload task → update both ranks on blockchain

📅 Part 16 — Multi-Objective Task Scheduling in Fog

Source: Movahedi et al., J Cloud Comp 10, 53 (2021)

Hierarchical Architecture

IoT Layer:  Sensor/actuator devices (ZigBee, Bluetooth, WiFi, LAN)
    ↓
Fog Layer:  Fog Cluster Managers + Fog Nodes (MAN network, WiFi)
    ↓
Cloud Layer: Cloud Manager + WAN + Compute / Storage / Task Queue

Scheduling Flow (Task Request Handling)

IoT Applications
  → Send task requests to Initial Fog Cluster Manager (FCM)
        ↓
Initial FCM → forwards to Scheduler FCM → tasks enqueued
        ↓
Scheduler FCM:
  1. Get state info from fog/cloud nodes AND IoT devices
  2. Run scheduling algorithm
  3. Offload IoT tasks to selected fog/cloud nodes

Task Execution Flow

Scheduler FCM → Selected Fog/Cloud Node
  1. Offload task
  2. Node fetches data FROM IoT devices
  3. IoT devices send data back
  4. Task executes (may span multiple time slots)
  5. Output result → back to Scheduler FCM → back to IoT

🔒 Part 17 — Security Challenges in Fog Computing

Architecture-Related Challenges

• Trust — hard to establish in distributed, heterogeneous systems
• Authentication — verifying identity across many fog nodes
• Wireless Security — vulnerable last-mile connections
• End-User Privacy — location and behavioral data exposed
• Malicious Attacks — fog nodes exposed at the edge

Technique-Related Challenges

• Model Privacy — ML models at the edge may be extracted
• Volume & Variety — diverse data types complicate security policies
• Flexibility vs. Security — tension between open APIs and strict access control
• Detection Methodology — anomaly detection across distributed nodes is hard
• Cryptography Issues — resource-constrained devices limit crypto options

Security Issues Inherited from Cloud

🎯 Part 18 — F2F vs. F2C Decision Scenarios

🧭 Rule of thumb:

• Real-time response needed → prefer F2F
• Global data or heavy compute → escalate to F2C

🧩 Quick Reference Summary

🧮 Part 19 — Worked Examples ⚠️ Final Exam Practice!

📝 Problem 1: Identify Overloaded / Underloaded Nodes

Given:

Assume: $\tau_{high} = 0.8$, $\tau_{low} = 0.4$

Formula: $\boxed{\rho_i = \frac{L_i}{C_i}}$

Classification:

• $\rho_i > \tau_{high}$ → Overloaded
• $\rho_i < \tau_{low}$ → Underloaded
• $\tau_{low} \leq \rho_i \leq \tau_{high}$ → Normal

Step-by-Step Solution:

$F_1$: $\rho_1 = \frac{72}{80} = 0.90 \quad \Rightarrow \quad 0.90 > 0.8 \quad \Rightarrow \quad \textbf{Overloaded} ✅$

$F_2$: $\rho_2 = \frac{20}{100} = 0.20 \quad \Rightarrow \quad 0.20 < 0.4 \quad \Rightarrow \quad \textbf{Underloaded} ✅$

$F_3$: $\rho_3 = \frac{50}{100} = 0.50 \quad \Rightarrow \quad 0.4 \leq 0.50 \leq 0.8 \quad \Rightarrow \quad \textbf{Normal}$

$F_4$: $\rho_4 = \frac{30}{60} = 0.50 \quad \Rightarrow \quad 0.4 \leq 0.50 \leq 0.8 \quad \Rightarrow \quad \textbf{Normal}$

Summary Table:

$F_1$ needs to offload tasks. $F_2$ is a good candidate to receive them (lowest utilization).

📝 Problem 2: Choose the Best F2F Offload Target

Given: $F_1$ is overloaded. Neighbor set: $\mathcal{N}_1 = {F_2, F_3, F_4}$

Score formula (lower = better): $\boxed{\text{Score}(F_j) = \alpha \cdot \rho_j + \beta \cdot \text{latency}_{1,j}}$

Assume: $\alpha = 1$, $\beta = 0.05$

$\alpha$ weights how much you care about load balancing; $\beta$ weights how much you care about latency. Pick the node with the lowest score.

Step-by-Step Solution:

Score($F_2$): $= 1 \times 0.25 + 0.05 \times 12 = 0.25 + 0.60 = \mathbf{0.85}$

Score($F_3$): $= 1 \times 0.50 + 0.05 \times 5 = 0.50 + 0.25 = \mathbf{0.75}$

Score($F_4$): $= 1 \times 0.35 + 0.05 \times 8 = 0.35 + 0.40 = \mathbf{0.75}$

Summary Table:

Answer: $F_3^* = F_3$ and $F_4$ are tied at 0.75.

Tiebreaker: When scores are equal, prefer the node with lower latency → $F_3$ wins (5 ms vs. 8 ms). Alternatively, if the tiebreaker is lower utilization → $F_4$ wins (0.35 vs. 0.50). Depends on system policy.

$\boxed{F_j^* = F_3 \text{ (lowest latency tiebreaker)}}$

🔑 How to Solve These Problems (General Template)

Problem 1 — Overload/Underload:

1. Compute ρ_i = L_i / C_i for each node
2. Compare against τ_high and τ_low
   - ρ_i > τ_high  → Overloaded
   - ρ_i < τ_low   → Underloaded
   - otherwise     → Normal

Problem 2 — Best F2F Target:

1. Identify overloaded node (from Problem 1)
2. Get its neighbor set N_i (only nodes within latency threshold δ)
3. Filter: only consider underloaded candidates (ρ_j < τ_low) — optional pre-filter
4. Compute Score(F_j) = α·ρ_j + β·latency_{i,j} for each neighbor
5. Select F_j* = argmin Score(F_j)
6. In case of tie → use secondary criterion (lower latency OR lower utilization)
7. Offload: T: F_i → F_j*

⚠️ Final Exam Reminders

1. F2F Offloading Algorithm — be able to write it as a sequence diagram or pseudocode:
   • Load monitoring → Neighbor discovery → Decision rule → Optimal selection → Offload
2. Blockchain-based secure F2F — design the 3-phase algorithm (Registration → Rank-based Selection → Token-based Cloud Verification)
3. Intra-node offloading — within a single fog node that has multiple internal compute units, internal load balancing and scheduling is also required
4. Overload/Underload threshold problem — given $\rho_i$, $\tau_{\text{high}}$, $\tau_{\text{low}}$, determine node status and which neighbor to offload to