Chapter 14 - Edge Computing and Fog Computing

Updated 4 Oct 2026

Edge Computing

  • Definition: Processing and computing client data closer to the data source rather than on a centralized server or cloud-based location
  • Brings computing resources, data storage, and enterprise applications closer to where people consume information
  • Has the ability to unleash the full potential of 5G
    • Enables data localization and ultra-low latency
    • Addresses security and privacy concerns
    • Reduces the load on networks
  • When combined with 5G, edge enables: VR/AR, gamification, drone control, connected cars, real-time collaboration

Think of Edge Computing like 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).


5G vs 6G Comparison

Feature5G6G
Peak Data RateUp to 10 GbpsUp to 1 Tbps (100× faster)
Latency~1 ms< 0.1 ms
Frequency BandSub-6 GHz, mmWave (24–100 GHz)Terahertz (THz) (100 GHz – 1 THz)
Spectrum EfficiencyHighUltra-high (AI optimized)
Connection Density~1M devices/km²10M+ devices/km²
ReliabilityUltra-reliable (URLLC)Near-perfect (99.99999%+)

Use Cases

  • 5G: Smart cities, Autonomous vehicles, Remote surgery, Industrial IoT (IIoT), AR/VR
  • 6G: Holographic communication, Tactile Internet (real-time touch feedback), Brain-computer interfaces, Fully immersive Metaverse, Digital twins, Ultra-precision remote control

Edge Computing (Detailed)

  • Deploys compute resources (processing, storage) at or near the data source
    • e.g., smart sensors, gateways, base stations
    • Goal: minimize latency and bandwidth usage
  • Pros:
    • Low latency
    • Bandwidth-efficient
    • Enhances privacy (data stays local)
  • Use Cases:
    • Real-time video analytics in smart surveillance
    • Predictive maintenance in industrial IoT
    • AR/VR applications with low round-trip times
  • Key Difference from Fog: Edge computing occurs directly on the devices where sensors are placed, or on a gateway physically close to sensors
  • Advantages: Optimizes connection, improves response time; security is enhanced with data encryption closer to the core of the network

Edge Computing Architecture (3 Layers)

  1. Device Layer — Sensors & Controllers (data origination)
  2. Edge Layer — Edge Node/Server
    • Data processing & Reduction
    • Data caching & buffering
    • Control response
    • Virtualization
  3. Cloud Layer — Cloud Server
    • Big data processing
    • Data warehousing

มี Edge layer (node) ไว้ลด latency


EDGE vs. Cloud

EdgeCloud
StrengthsLow latency, Reduce backhaul, Data localisationScalability, Mobility, Light Device
TogetherHybrid IT EnvironmentHybrid IT Environment

Mist Computing

  • Definition: Pushes computation to the extreme edge — to the end devices themselves (smart sensors, microcontrollers, embedded systems)
  • Also called "nano-edge" computing
  • Characteristics:
    • Devices perform preprocessing or lightweight analytics
    • Supports actuation and autonomous decision-making without upstream communication
    • Often coupled with battery-powered or constrained devices
  • Pros:
    • Real-time responsiveness
    • No need for constant connectivity
    • Local autonomy (fail-safe operations)
  • Use Cases:
    • Smart thermostats performing temperature regulation
    • Wearables filtering health data before sending summaries
    • Drones performing on-board obstacle detection
  • Relationship with Fog: Complementary — computationally intensive tasks → Fog (gateway); less intensive tasks → Mist (end devices)
  • Hardware: Processing capability comes from microchips or microcontrollers embedded on the device → very limited processing

Mist is like a person making quick decisions on the spot (edge of the edge), while Fog is the supervisor nearby who handles more complex decisions, and Cloud is HQ far away.

It’s resource constrained device, computed on device, limitation on computation power!


Fog Computing

  • Term coined by Cisco in 2014
  • Fog and cloud computing are interconnected
    • In nature: fog is closer to the earth than clouds
    • In tech: fog is closer to end-users, bringing cloud capabilities down to the ground
  • Fog = the layer below the cloud layer, managing connections between cloud and network edge
  • Key Difference vs Cloud:
    • Cloud = centralized system
    • Fog = distributed decentralized infrastructure

Fog is like a network of local warehouses (fog nodes) spread across a city, handling deliveries close to customers, while the central factory (cloud) handles large-scale production and long-term storage.

Characteristics of Fog Computing

  • A paradigm that extends Cloud computing to the edge of the network
  • Low latency & location awareness
  • Sends the right data to the cloud for big data analytics and storage
  • Wide-spread geographical distribution
  • Strong presence of streaming and real-time applications
  • Handles an unprecedented volume, variety, and velocity of data
  • Heterogeneity of connected objects
  • Fog applications communicate directly with mobile devices
  • Predominant role of wireless access

Fog as a Platform

  • Fog = the distributed, hierarchically organized platform where the Internet meets the physical world at the Machine-to-Machine (M2M) scale
  • Properties:
    • Service Mobility — ability to migrate a running instance from cloud to edge
    • Mixed ownership & operation — single entity or federation of agencies
    • Fog Nodes can be multi-tenant — shared, public or private (like cloud)
    • North/South Flows — between fog and cloud/devices
    • East/West Flows — between fog nodes laterally
    • Highly virtualized environment — secured & isolated tenants, QoS, workload distribution

Taxonomy of Fog Computing

[Image: Taxonomy of Fog Computing tree diagram]

Main branches:

  • Fog Nodes Configuration: Servers, Networking devices, Cloudlets, Base stations, Vehicles
  • Nodal Collaboration: Cluster, P2P, Master-slave
  • Resource/Service Provisioning Metrics: Time (Communication, Computation, Deadline), Data (Flow, Size), Cost (Networking, Deployment, Execution), Context (User, Application), Energy & Carbon footprint
  • Service Level Objectives: Latency Mgmt, Cost Mgmt, Network Mgmt (Congestion, Virtualization, Connectivity), Computation Mgmt (Resource Estimation, Workload Allocation, Coordination), Application Mgmt (Programming Platform, Scaling, Offloading), Data Management, Power Management
  • Applicable Networking System: IoT, Mobile network/RAN, LRPON/PLC, Vehicular Network, CDN
  • Security Concern: Authentication, Encryption, Privacy, DoS Attack

Benefits of Fog Computing

  • Industries using fog: Energy, Manufacturing, Construction, Oil and Gas, Transportation, Finance, Telecommunication, Healthcare, Retail, Smart Cities, Agriculture
  • Fog Benefits:
    • Ultra-low latency
    • Location awareness
    • Efficiency in network load
    • High bandwidth
    • Security
    • Real-time analytics
    • Agility
  • Fog distributes core functions: Computation, Storage, Communication, Control, Decision Making
  • Fog helps devices: Measure, Monitor, Process, Analyze, React

Components of Fog Computing Platform

[Image: Fog Computing Platform architecture diagram]

FC Software Stack (Simplified)

Business Applications
├── Cloud Infrastructure Software (Portals, Services, Resources/tools)
├── Fog Management Software (Life cycle mgmt, Orchestration, APIs/SDKs)
├── Fog Infrastructure Software (Execution env, Operating system, Virtual network functions)
└── Fog Hardware (Networking, Compute, Storage)
         ↕
       Things

Cross-cutting concerns: Policy/Security | Analytics and data models

Technology Components for Scalable Virtualisation

  • Computing — requires selection of hypervisors to virtualise both computing and I/O resources
  • Storage — needs a Virtual File System and a Virtual Block and/or Object Store
  • Networking — needs a Network Virtualisation Infrastructure (e.g., SDN, NFV)
  • Fog leverages policy-based orchestration and provisioning mechanism on top of the resource virtualisation layer
  • Fog architecture should expose APIs for application development and deployment

HW/SW Components

Heterogeneous Physical Resources

  • Fog = heterogeneous infrastructure of FCNs (servers, routers, APs, set-top boxes) + multiple wireless access technologies
  • Needs an abstraction layer on top

Fog Abstraction Layer

  • Hides platform heterogeneity
  • Exposes a uniform and programmable interface for seamless resource M&C
  • Provides generic APIs and virtualisation support
  • Supports multi-tenancy

Fog Service Orchestration Layer

  • Provides dynamic, policy-based life-cycle management of Fog services
  • As distributed as the underlying Fog infrastructure and services

Management of Services — Components

  • A SW agent, Foglet (FSA) — bears the orchestration function and performance requirements
  • A distributed, persistent storage to store policies and resource meta-data (capability, performance, etc.)
  • A scalable messaging bus for service orchestration and resource management
  • A distributed policy engine with a single global view and local enforcement

Foglet Software Agent (FSA)

  • The distributed Fog orchestration framework — implemented by several FSAs, one running on every node
  • Uses abstraction layer APIs to monitor health and state associated with the PHY machine and services deployed on it
  • Performs life-cycle management activities

Distributed Database (DDB)

  • Fast storage and retrieval of data
  • Stores both application data and meta-data to aid in Fog service orchestration

Policy-Based Service Orchestration

  • e.g., policy-based service routing — routing an incoming service request to the appropriate service instance
  • Examples of policies: thresholds, QoS requirements, config policies, power management, security, isolation, privacy
  • The policy manager = central element
  • Business policies are pushed to a distributed policy database

Message BUS

  • Messaging infrastructure that allows different systems to communicate through a shared set of interfaces

Pushing Intelligence Up Toward The Cloud

Cloud ChallengesHow Fog Can Help
Critical Latency Req.Fewer Network hops
Data Rich MobilityData locality & Local Caches
Geographic DiversityIntelligence localized as appropriate
Network Bandwidth limit.Local processing / less core Net. Load
Reliability/RobustnessFast Failover; local resp. in Emergency
Analytics ChallengesAnalytics & Storage at the Right Tier
User Data/Geo. PrivacyFog can Aggregate User Data

Pushing Intelligence Downward to the Endpoints

Intelligent Endpoint ChallengesHow Fog Can Help
Physical Constraints (Energy/Power, Space, Environment)Fog nodes can access more energy; Fog Nodes can be physically larger; Better cooling systems
Functional Constraints (Processor throughput, Storage, Reliability, Modularity)Terabytes > PB storage cap.; Fog capabilities can be more redundant; Modules can be added as needed
Security ConstraintsFog has better physical/network security

IoT with Fog Computing

Architecture (bottom to top):

  1. Device → Local data collection
  2. FOG (IOx) → Local data analysis and filtering
  3. Data Center/Cloud → Non-real-time data action, storage

What You Can Do:

  • Analyze and act on data right at the network edge
  • Use bandwidth and storage capacity more efficiently — sending only relevant information to the cloud
  • Connect any protocol or device through an open platform

Data Flow: Today vs Tomorrow

  • Today: Large data volume flows from edge to core (data refining at each tier)
  • Tomorrow: Analytics algorithms become slimmer as we move to edge

Fog Data Services

  • Coordinates the movement of data from Fog to Cloud
  • Fog Nodes receive: Large Volume of Data, Wide Variety of Things, High Velocity of Data Generation
  • Fog Data Services apply: Rules, Patterns, Actions
    • Data Reduction
    • Control Response
    • Data Virtualization/Standardization
  • Sends up to Cloud: Virtualized Data, Historic/Predictive Analysis, Machine Learning
  • Cloud sends back: Rule and Pattern Updates

Computing Paradigms Comparison

[Image: Comparison of infrastructure of fog computing and related computing paradigms from the networking perspective]

Paradigms shown: Mobile Computing, Mist Computing, Mobile Cloud Computing, Mobile Edge Computing (Cloudlet), Fog Computing, Cloud Computing, Mobile ad hoc Cloud Computing


Comparative Summary: Mist vs Edge vs Fog

FeatureMist ComputingEdge ComputingFog Computing
LocationOn the IoT deviceNear the device (e.g., AP)Intermediate (gateway/server)
LatencyLowest (µs–ms)Low (ms)Moderate (ms–s)
ResourcesVery limitedModerateHigh
ConnectivityIntermittentLocalizedAggregated/distributed
Ideal forAutonomy, fail-safe opsLocal processingContextual orchestration

Offloading: F2F and F2C

Criteria ในการจะ offload ก็คือ load ไง ถ้า 80% ก็ส่งไปให้อีกอันทำงานแทน
ออก #FinalExam เรื่องนี้!!!!!!!

F2F (Fog-to-Fog) and F2C (Fog-to-Cloud) Offloading

  • End-users upload task to primary fog node (ith fog node)
  • If overloaded → offload to:
    • F2F: assistive jth fog node via wired link
    • F2C: the Cloud via wireless link

Fog2Fog Load Sharing

Fog Nodes: F=F1,F2,…,FnF = {F_1, F_2, \ldots, F_n} — collection of all fog nodes in the system

Node Parameters:

  • LiL_i → Current load of node FiF_i
  • CiC_i → Capacity of node FiF_i

Utilization:
ρi=LiCi\boxed{\rho_i = \frac{L_i}{C_i}}

Load Status:

  • Overloaded: ρi>τhigh\rho_i > \tau_{\text{high}}
  • Underloaded: ρi<τlow\rho_i < \tau_{\text{low}}

Think of ρi\rho_i like CPU usage percentage — if it goes above a high threshold, the node is "overloaded" and needs to delegate tasks to a less busy neighbor.

Load Sharing Mechanism (4 Steps)

Step 1: Load Monitoring

  • Each fog node periodically computes: ρi=LiCi\rho_i = \frac{L_i}{C_i}
  • Enables real-time system awareness

Step 2: Neighbor Discovery

  • Define neighbor set:
    Ni=Fj∣latency(i,j)<δ\mathcal{N}_i = {F_j \mid \text{latency}(i,j) < \delta}
  • Only low-latency neighbors are considered

Step 3: Decision Rule

  • If node FiF_i is overloaded, find:
    ∃Fj∈Ni such that ρj<τlow\exists F_j \in \mathcal{N}_i \text{ such that } \rho_j < \tau_{\text{low}}
  • Select candidate nodes with low utilization and acceptable latency

Step 4: Optimal Target Selection
Fj∗=arg⁡min⁡Fj∈Ni(α⋅ρj+β⋅latencyi,j)\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
  • β\beta → weight for latency minimization

Task Offloading:
T:Fi→Fj∗\boxed{\mathcal{T}: F_i \rightarrow F_j^*}

Load Sharing Strategies

Load is not sent to the cloud first — it is redistributed intelligently within the fog layer

  • Threshold-based — trigger offloading when utilization exceeds a threshold
  • Queue-based — based on queue length at each node
  • Prediction-based — proactively offload before overload occurs
  • Load-aware — continuously monitor and redistribute
  • Priority-aware — high-priority tasks get preferential routing

Secure Task-Offloading Framework for Cooperative Fog (Blockchain-based)

Source: R. Roshan et al., GLOBECOM 2020

ออก #FinalExam ให้ ออกแบบ (design) algorithm เขียนเป็นแบบ sequence diagram F2F
เขียนเป็น Pseudocode ไรงี้

Phase 1: Joining and Registration on the Blockchain

  • A node joining the fog network joins the blockchain
  • Registered using unique credentials
  • A registered fog node has its identity and registration timestamp as a transaction on the blockchain
  • Uses Smart Contracts (programmable object/policy) in BC to:
    • Authenticate fog nodes
    • Handle communication between fog nodes

Phase 2: Secure Fog Node Selection

  • Offloading decision is made when a fog-node lacks enough resources
  • Choice of secondary fog node is based on rank of each fog node
    • Rank = number of unique successful peer relations a fog node has established
    • Rank increments whenever a fog-node successfully authenticates itself to a peer and a transaction is carried out

Rank Calculation:

  1. All new nodes begin with rank 0
  2. NkN_k joining the network has rank 0 — no authenticated peer-relations yet
  3. If NiN_i (rank > threshold) needs to offload to NkN_k → mutual verification depends on the threshold
  4. NiN_i verifies NkN_k through the cloud token system; NkN_k verifies NiN_i directly via rank from smart contract → on success, both ranks are updated
  5. Rank value of a fog node is stored on the blockchain as a transaction

Phase 3: Token-Based Cloud Verification

  • Used when a fog-node does not meet the required threshold for direct verification
  • Uses Public Key Infrastructure (PKI)
  • A fog-node verifies and validates the identity of a peer fog-node through the cloud, using a token

Verification Procedure:

  1. Every fog node obtains a pair of keys (public/private) through the PKI
  2. Let NkN_k be the peer fog-node that must authenticate itself to NiN_i via cloud
  3. NkN_k requests a token from cloud at time treqt_{req}
  4. Token computed by the cloud:

tokenreq=[treq,Nk]Pukey−cloud\boxed{token_{req} = [t_{req}, N_k] Pu_{key-cloud}}

  1. tokenreqtoken_{req} is presented to NiN_i and verified via the cloud for authenticity and freshness

Multi-Objective Task Scheduling in Fog (Movahedi et al., 2021)

Source: J Cloud Comp 10, 53 (2021)

Hierarchical Fog-Based Architecture

[Image: Hierarchical fog-based architecture model — IoT layer → Fog layer → Cloud layer]

Layers:

  • IoT Layer: Sensor/actuator devices (ZigBee, Bluetooth, WiFi, LAN)
  • Fog Layer: Fog cluster managers with fog nodes (MAN network, WiFi)
  • Cloud Layer: Cloud manager + WAN network + compute/storage/task queue

Process of Handling IoT Task Requests (Scheduling)

[Image: Sequence diagram — IoT applications → initial fog cluster manager → scheduler fog cluster manager → fog/cloud nodes → IoT devices]

Flow:

  1. IoT applications send requests for IoT tasks execution to initial fog cluster manager
  2. Initial FCM forwards requests to scheduler FCM → tasks enqueued
  3. Scheduler FCM gets state info from fog/cloud nodes and IoT devices
  4. Scheduling process runs
  5. IoT tasks offloaded to selected fog/cloud nodes

Process of Task Execution

[Image: Sequence diagram — scheduler fog cluster manager → selected fog/cloud node → IoT devices]

Steps:

  1. IoT task offloading (scheduler → selected fog/cloud node)
  2. Get data (selected node → IoT devices)
  3. IoT devices send data back
  4. Task execution (may take more than one slot time)
  5. Output result of task execution → back to scheduler

Security Challenges in Fog Computing

[Image: Security challenges tree diagram]

  • Trust
  • Authentication
  • Wireless Security
  • End User's Privacy
  • Malicious Attacks
  • Models Privacy
  • Volume and Variety
  • Flexible
  • Detection Methodology
  • Cryptography Issue

Security Issues Inherited from Cloud

Potential security issues fog inherits:

  • Data threats: Data Breaches, Data Loss
  • Fog/Cloud layer threats: Advanced Persistent Threats, Access control issues, Account Hijacking, Denial of Service
  • Platform threats: Insecure APIs, System and Application Vulnerabilities, Malicious Insiders, Insufficient Due Diligence, Abuse and Nefarious Use, Shared Technology Issues

Cloud vs. Fog — Comparison Tables

Data State Definitions

  • Data at rest — stored in db/file
  • Data in transit/motion/flight — data being transferred in the network

Table 1: Performance & Security

RequirementsCloud ComputingFog Computing
LatencyHighLow
Delay JitterHighVery low
Location of ServersWithin InternetAt the edge close to Nodes
Distance (client & server)Multiple hopsOne hop
SecurityVaries amongst providersCan be more defined and customized
Attack on Data-in-FlightHigh probabilityLimited with less probability
Location awarenessNoYes

Table 2: Architecture & Connectivity

RequirementsCloud ComputingFog Computing
Geo. DistributionCentralizedDistributed
No. of Server NodesFewVery large
Support for MobilityLimitedSupported
Real Time InteractionsSupported but may be difficult & CostlySupported
Type of last mile connectivityLeased lineWireless

Relationship: Fog Computing, Cloudlet, and MEC

Fog ComputingMECCloudlet
Operation modeConnected to cloudStandaloneStandalone or connected to cloud
Main driver—Industry consortiumResearch and Development
VirtualizationSupportedVM or any other appropriate technologyVM
Target applicationsMobile offloading, better at edge, spanning cloud and edgeMobile offloading, better at edgeMobile offloading

Common features of all three: Computing at the edge, Virtualization supported

Intranode ก็เป็นไปได้นะ สำหรับ Offloading, ก็แปลว่าใน node ก็จะมี computing node หลายตัวนั่นแหละ ข้างในก็จำเป็นต้องมี load balance, scheduling อีก (depend on nature of task) #FinalExam


Fog Milestone: OpenFog Consortium

  • Founded by: ARM, Cisco, Dell, Intel, Microsoft, Princeton University
  • Mission: Drive industry and academic leadership in fog computing architecture, testbed development, and a variety of interoperability and composability deliverables that seamlessly leverage cloud and edge architectures to enable end-to-end IoT scenarios

Pros and Cons

Cloud Computing — Pros for IoT

  • Improved performance — faster communication between IoT sensors and data processing
  • Storage capacities — highly scalable and unlimited storage; integrate, aggregate and share enormous data
  • Processing capabilities — remote data centers provide unlimited virtual processing on-demand
  • Reduced costs — license fees lower than on-premise equipment and maintenance

Fog Computing — Pros

  • Low latency — geographically closer to users → instant responses
  • No bandwidth problems — information aggregated at different points instead of one channel
  • Loss of connection impossible — due to multiple interconnected channels
  • High security — data processed by a huge number of nodes in a complex distributed system
  • Improved user experience — instant responses and no downtimes
  • Power-efficiency — edge nodes run power-efficient protocols (Bluetooth, Zigbee, Z-Wave)

Fog Computing — Cons

  • More complicated system — fog is an additional layer in the data processing and storage system
  • Additional expenses — companies must buy edge devices (routers, hubs, gateways)
  • Limited scalability — not as scalable as cloud

F2F vs F2C — Decision Scenarios

  1. → F2C (Fog-to-Cloud): An application requires aggregating data from multiple cities worldwide and generating global insights → requires cloud-scale resources
  2. → F2F (Fog-to-Fog): Multiple fog nodes are processing real-time CCTV streams; one node is overloaded, nearby fog nodes have spare capacity → real-time object detection needs low latency, use F2F
  3. → F2C (Fog-to-Cloud): A manufacturing system needs to train a deep learning model using massive sensor data collected over weeks → requires massive cloud compute

Rule of thumb: If it needs real-time response → prefer F2F; if it needs global data or heavy compute → escalate to F2C.

Problem 1: Overload or Underloead