2 Edge and Fog Computing

In 60 Seconds

Edge computing processes data within 10 ms at the device, fog computing aggregates regionally within 10-100 ms, and cloud handles global analytics at 100+ ms. Together, this three-tier architecture reduces cloud-bound traffic by 90-99% and enables real-time decisions for autonomous vehicles, industrial safety, and healthcare monitoring. The key design rule: process at the lowest tier that meets your latency requirement.

Key Concepts

Edge Node: Any compute-capable device at the network periphery — from a $2 ESP32 microcontroller to a $500 NVIDIA Jetson — that processes sensor data locally
Fog Node: A more capable intermediate device (industrial gateway, mini server) serving multiple edge devices and providing local storage, analytics, and protocol translation
Compute Continuum: Spectrum from deeply embedded MCUs through edge servers, fog gateways, regional cloudlets, to central cloud — workloads placed based on latency and resource needs
Real-Time Constraint: Requirement that a system respond within a deterministic time bound (e.g., <10ms for brake actuation); only edge processing can satisfy hard real-time constraints
WAN Independence: Ability of edge/fog systems to operate fully during internet outages by maintaining local decision logic and buffering data for eventual sync
Protocol Translation: Edge/fog gateway function converting sensor protocols (Modbus, BACnet, Zigbee) to cloud protocols (MQTT, HTTP/REST) for integration
Containerization at Edge: Running Docker/OCI containers on edge devices (Raspberry Pi, Jetson) to enable portable, reproducible application deployment
Energy-Performance Trade-off: Higher compute performance at edge requires more power; MCUs run at 1-50mW but are limited; edge GPUs run at 5-15W with 100x more throughput

Prerequisites: Cloud Computing | IoT Reference Architectures

This enables: Edge AI/ML | Edge Compute Patterns

2.1 Learning Objectives

By completing this chapter series, you will be able to:

Distinguish edge, fog, and cloud tiers: Compare the roles, latency profiles, and compute capabilities of each processing tier in IoT architectures
Calculate latency and bandwidth trade-offs: Quantify the impact of processing location on response times and data transmission costs using concrete formulas
Design distributed architectures: Apply the decision framework to select appropriate processing tiers for different IoT use cases
Implement three-tier systems: Structure edge, fog, and cloud layers with proper data flow and control patterns
Diagnose common deployment pitfalls: Identify and prescribe corrective actions for typical mistakes in distributed IoT deployments
Demonstrate edge computing concepts: Complete hands-on labs implementing edge filtering, fog aggregation, and hybrid architecture patterns

Minimum Viable Understanding

Before diving into the full chapter series, make sure you grasp these three essentials:

Three processing tiers exist: Edge (on-device, 1-10ms), Fog (local gateway, 10-100ms), and Cloud (remote data center, 100-300ms) – each tier trades latency for computational power
Edge filtering reduces data by 90-99%: A factory with 1,000 sensors generating 100 GB/day can transmit as little as 1 GB/day by performing local aggregation and anomaly detection at the edge, cutting cloud costs from over $100K/month to under $3K/month
The tiers are complementary, not competing: Safety-critical decisions (e.g., emergency stop within 5ms) happen at the edge, coordination across devices happens in the fog, and long-term analytics and ML training happen in the cloud

2.2 Overview

Edge and fog computing extend cloud capabilities to the network edge, enabling real-time processing, bandwidth optimization, and resilient IoT systems. This comprehensive chapter series covers the fundamental concepts, architecture patterns, practical use cases, and hands-on implementation of distributed computing for IoT.

Why Edge and Fog Computing Matters:

Latency: Cloud round-trips take 100-300ms; edge processing achieves 5-15ms
Bandwidth: Edge filtering reduces data transmission by 90-99%
Reliability: Local processing continues during network outages
Privacy: Sensitive data processed locally, never leaves the premises
Cost: Reduces cloud bandwidth and processing costs by orders of magnitude

For Beginners: What is Edge and Fog Computing?

Imagine you have a smart home with sensors in every room. There are three ways to process this data:

Cloud Computing (traditional): All sensor data travels over the internet to a distant data center, gets processed, and the response comes back. This is like mailing a letter to headquarters and waiting for a reply.
Edge Computing: Each sensor has its own tiny computer that makes instant decisions locally. This is like having a smart assistant in each room who can turn off lights immediately when you leave.
Fog Computing: A local hub (like a smart home controller) collects data from nearby sensors, makes coordinated decisions, and only sends summaries to the cloud. This is like having a building manager who handles routine issues locally but escalates major problems to corporate.

Key insight: Edge and fog computing are not replacements for the cloud - they work together! Simple, time-critical decisions happen locally (edge/fog), while complex analysis and long-term storage happen in the cloud.

Start here: If this is your first time learning about distributed computing, begin with the Introduction chapter which includes more analogies and visual explanations.

Sensor Squad: The Neighborhood Helpers

Sammy the Temperature Sensor was worried. “Every time I measure something in the garden, I have to send a message ALL the way to Cloud City to find out if the plants are too hot. By the time the answer comes back, the flowers are already wilting!”

Lila the Light Sensor agreed. “It takes me forever to get a reply too. I measured that the porch light was still on at noon, but by the time Cloud City told me to turn it off, an hour had passed!”

Max the Motion Detector had an idea. “What if we didn’t send EVERYTHING to Cloud City? What if we had a helper closer to us?”

That’s when Bella the Button introduced them to the Neighborhood Helpers system:

Desk Buddy (Edge): Each sensor gets their own tiny helper sitting right next to them. Sammy’s Desk Buddy checks the temperature every second and turns on the sprinklers instantly if it gets above 35 degrees Celsius. No waiting for Cloud City!
Classroom Teacher (Fog): A smart helper in the garden shed collects information from Sammy, Lila, and Max. The Teacher notices patterns – like “it’s hot AND sunny AND no motion, so the garden needs extra water.” The Teacher handles problems that need teamwork between sensors.
Cloud City Headquarters (Cloud): The big computers far away look at weeks of data and say things like “This summer is hotter than last summer, so change the watering schedule for next month.”

“So the easy stuff stays close, and only the really tricky stuff goes far away?” asked Sammy.

“Exactly!” said Bella. “Your Desk Buddy handles emergencies in milliseconds. The Teacher coordinates the team in seconds. And Cloud City plans for the future using all the data from every garden in the country.”

Try this at home: Think about your school. What decisions does your teacher make right away (edge), what does the principal handle (fog), and what does the school board decide (cloud)?

2.3 Chapter Series

This topic is covered in 11 focused chapters organized into four learning tracks:

Flowchart showing 11 chapters organized into four tracks: Foundations (Introduction, Latency, Bandwidth), Architecture and Design (Decision Framework, Architecture, Advantages/Challenges), Interactive Learning (Simulator), and Applications/Implementation (Use Cases, Pitfalls, Labs). Arrows show recommended progression from foundations through architecture to hands-on practice. — Edge and Fog Computing Chapter Series - Learning Path

2.3.1 Foundations

Introduction - Core concepts, definitions, and business value
- What is edge and fog computing?
- Key terminology and concepts
- Executive summary for business leaders
- Sensor Squad kids section
The Latency Problem - Why milliseconds matter
- Physics of network latency
- Speed of light constraints
- Safety-critical application requirements
- Self-driving car calculations
Bandwidth Optimization - Cost calculations and data reduction
- IoT data volume calculations
- Cloud-only vs edge/fog cost comparison
- ROI analysis for edge infrastructure
- Data gravity principle

2.3.2 Architecture and Design

Decision Framework - When to use edge vs fog vs cloud
- Decision tree for architecture selection
- Detailed criteria for each tier
- Cost-benefit analysis framework
- Four architecture patterns
Architecture - Three-tier design and fog node capabilities
- Three-tier architecture (Edge, Fog, Cloud)
- Fog node capabilities
- Data flow and processing pipelines
- GigaSight framework case study
Advantages and Challenges - Benefits and implementation challenges
- Performance, operational, and security advantages
- Resource constraints and management complexity
- Energy-latency trade-offs
- Network topology considerations

2.3.3 Interactive Learning

Interactive Simulator - Hands-on latency visualization tool
- Adjust data size, complexity, distance
- Compare edge, fog, and cloud latency
- Real-world scenario presets
- Bandwidth cost calculator

2.3.4 Applications

Use Cases - Factory, vehicle, and privacy applications
- Smart factory predictive maintenance
- Autonomous vehicle edge computing
- Privacy-preserving architecture
- Agricultural drone worked example

2.3.5 Implementation

Common Pitfalls - Mistakes to avoid
- Retry logic without backoff
- Missing local buffering
- Device management neglect
- Clock synchronization issues
Hands-On Labs - Wokwi ESP32 simulation exercises
- Edge vs cloud latency comparison
- Data aggregation implementation
- Hybrid architecture design
- Challenge exercises

2.4 Quick Reference

Putting Numbers to It

Edge-fog-cloud tiering reduces latency and bandwidth costs. Formula: Response latency $L = L_{process} + L_{network}$ where $L_{network} = 2d/v$ for distance $d$ and signal velocity $v \approx 200,000$ km/s in fiber. Data cost savings $S = D_{raw} \times (1-r) \times p$ where $r$ is fog reduction ratio and $p$ is bandwidth price.

Worked example: Cloud at 1,000 km distance: $L_{network} = 2 \times 1000/200000 = 10$ ms. Total latency (with 50ms processing): 60ms. Factory with 1,000 sensors @ 100 Hz, 50 bytes: $D_{raw} = 432$ GB/day. With 98% fog filtering ($r=0.98$): $S = 432 \times 0.98 \times \$0.09 = \$38.1$/day saved = $\$13,907$/year. Edge latency <5ms enables real-time safety responses; fog reduces costs 98%.

2.4.1 Key Metrics

Tier	Typical Latency	Best For	Bandwidth Impact
Edge	1-10 ms	Safety-critical, real-time control	99%+ reduction (only events)
Fog	10-100 ms	Multi-device coordination, local analytics	90-99% reduction
Cloud	100-300 ms	ML training, global analytics, storage	Full data (if needed)

2.4.2 When to Use Each Tier

Requirement	Recommendation
Latency < 10ms	Edge (mandatory)
Latency < 100ms	Fog (preferred)
Latency > 200ms OK	Cloud (acceptable)
Must work offline	Edge/Fog
Privacy regulations	Edge/Fog
Massive compute needed	Cloud
10,000+ devices	Hierarchical Fog

2.4.3 Three-Tier Architecture Overview

Architecture diagram showing three horizontal tiers. The bottom Edge tier contains sensors and actuators performing real-time control at 1-10ms latency. The middle Fog tier contains local gateways and servers performing coordination and aggregation at 10-100ms latency. The top Cloud tier contains data centers performing analytics, storage, and ML training at 100-300ms latency. Arrows show data flowing upward with increasing reduction at each tier, and commands flowing downward. — Edge-Fog-Cloud Three-Tier Architecture

Data flows upward with progressive reduction at each tier: raw sensor readings at the edge become aggregated summaries at the fog, and only high-value insights reach the cloud. Commands and model updates flow downward from cloud to fog to edge.

2.4.4 Cost Comparison (1,000 sensor factory example)

Architecture	Monthly Cost	Annual Cost
Cloud-only	$106,354	$1,276,248
Edge + Fog	$2,526	$30,312
Savings	98%	$1,245,936/year

2.5 Learning Path

Recommended order for first-time learners:

Start with Introduction for foundational concepts
Understand the physics in The Latency Problem
Learn about costs in Bandwidth Optimization
Use the Decision Framework to choose architectures
Study the Architecture details
Explore the Interactive Simulator
Review Use Cases for practical applications
Complete the Hands-On Labs

For experienced practitioners:

Jump directly to Decision Framework for architecture guidance
Review Common Pitfalls to avoid mistakes
Use the Interactive Simulator for scenario analysis

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

2.6 Knowledge Check

Test your understanding of edge and fog computing concepts:

Quick Assessment

Question 1: A manufacturing robot needs to stop within 5ms when it detects a human nearby. Which processing tier should handle this safety function?

Cloud computing (centralized processing)
Fog computing (local gateway)
Edge computing (on-device)
Any tier works equally well

Answer

c) Edge computing (on-device) - Safety-critical applications requiring sub-10ms response times must use edge computing. Cloud round-trips (100-300ms) and even fog processing (10-100ms) are too slow for human safety applications where every millisecond counts.

Question 2: A smart city deploys 10,000 traffic cameras generating 1TB of video data per day. What is the PRIMARY benefit of using fog computing instead of sending all data to the cloud?

Better video quality
Reduced bandwidth costs (90-99% data reduction)
Faster camera frame rates
More storage capacity

Answer

b) Reduced bandwidth costs (90-99% data reduction) - Fog nodes can perform local video analytics, extracting only relevant events (vehicle counts, incidents) and discarding raw video. This reduces data transmission from 1TB/day to potentially 10-100GB/day, dramatically cutting bandwidth costs.

Question 3: During a network outage, which architecture ensures a factory can continue operating?

Cloud-only architecture
Edge/Fog architecture with local buffering
Either architecture works the same
Network outages don’t affect IoT systems

Answer

b) Edge/Fog architecture with local buffering - Edge and fog computing provide operational resilience. Local processing continues during network outages, with fog nodes buffering data until connectivity is restored. Cloud-only architectures fail completely when the network is unavailable.

Common Pitfalls

Pitfall 1: Treating edge/fog as a cloud replacement. Edge and fog computing supplement the cloud – they do not replace it. Tasks like ML model training, global analytics across thousands of sites, and long-term archival storage still require cloud infrastructure. A common mistake is over-investing in edge hardware to avoid cloud costs entirely, only to discover that edge devices lack the compute power for complex analytics.

Pitfall 2: Ignoring clock synchronization across tiers. When data is processed at different tiers with different clocks, event ordering becomes unreliable. A fog node might log an alarm at 10:03:01 while the edge sensor recorded it at 10:03:04 due to clock drift. Without NTP or PTP synchronization, debugging distributed systems becomes nearly impossible. Always implement clock sync before deploying multi-tier architectures.

Pitfall 3: No local buffering for network outages. If your fog node has no local storage and the cloud connection drops, data is permanently lost. A factory that generates 10 GB/day of sensor data needs at least 30 GB of local buffer (3 days) to survive a typical WAN outage. Design for the worst-case disconnection period, not the average.

Pitfall 4: Retry storms overwhelming the network. When connectivity is restored after an outage, all edge devices simultaneously retrying creates a traffic spike that can crash the fog gateway or saturate the uplink. Use exponential backoff with jitter (random delay) so devices reconnect gradually. See the Common Pitfalls chapter for implementation patterns.

Pitfall 5: Deploying without remote update capability. Edge devices deployed in the field without over-the-air (OTA) update mechanisms become permanently stuck on their initial firmware. When a security vulnerability is discovered, you cannot patch devices that lack OTA support. Budget for device management infrastructure from day one.

Worked Example: Smart Building Energy Optimization

Scenario: 50-floor office building with 2,000 HVAC zones, 5,000 occupancy sensors, and 1,000 smart lights. Goal: Minimize energy costs while maintaining comfort.

Architecture Design:

Edge Layer (Per-Zone Controller - ESP32): - Inputs: Temperature sensor (10s intervals), occupancy PIR sensor (real-time), light sensor (10s) - Local processing: PID control for HVAC setpoint, occupancy-based lighting (on/off within 500ms) - Decision latency: <1s for comfort adjustments - Bandwidth: Sends zone status every 5 minutes = 2,000 zones × 50 bytes × 12/hour = 1.2 MB/hour

Fog Layer (Floor Gateway - Raspberry Pi 4 per floor): - Aggregates 40 zones per floor - Local analytics: Predict occupancy patterns (ML model), optimize floor-wide HVAC (coordinate zones to reduce peaks), detect anomalies (stuck dampers, failed sensors) - Inter-floor coordination: Balance cooling loads across floors - Bandwidth to cloud: Hourly summaries + anomalies = 50 floors × 1 KB/hour = 50 KB/hour (96% reduction from edge)

Cloud Layer (Azure IoT Hub + Stream Analytics): - Receives 50 KB/hour × 24 = 1.2 MB/day (vs. 28.8 MB/day raw) - Historical analytics: Building-wide energy trends, utility cost optimization, predict maintenance needs - Model training: Update occupancy prediction models monthly, push to fog gateways

Energy Savings Calculation:

Baseline (no optimization): $180,000/year HVAC + $85,000/year lighting = $265,000
Edge optimization (occupancy-based): 15% savings = $39,750/year
Fog optimization (floor-wide coordination): Additional 8% = $21,200/year
Cloud optimization (predictive scheduling): Additional 5% = $13,250/year
Total savings: 28% = $74,200/year

System Costs:

Edge: 2,000 controllers × $25 = $50,000
Fog: 50 gateways × $120 = $6,000
Cloud: $500/month × 12 = $6,000/year
Payback period: 10 months

Result: 28% energy reduction, <1s comfort response, 96% bandwidth savings, ROI in under 1 year.

Decision Framework: When Edge/Fog Outperforms Cloud-Only

Use this decision matrix to determine if edge/fog computing is justified for your application:

Evaluation Criteria	Cloud-Only	Edge/Fog Required	Score Weight
Latency requirement <50ms?	No (100-500ms typical)	Yes (1-10ms edge)	Critical (5×)
Bandwidth cost >$1K/month?	Acceptable if needed	Fog reduces 90-99%	High (3×)
Must operate offline?	No (requires connectivity)	Yes (local autonomy)	Critical (5×)
Privacy regulations apply?	Data leaves premises	Data stays local	High (3×)
Energy constrained devices?	Constant transmission	Local processing saves battery	Medium (2×)
Real-time decisions required?	Batch acceptable	Immediate response	High (3×)

Scoring: Multiply each “Edge/Fog Required” benefit by its weight. Total >10 = Edge/Fog recommended, >15 = Edge/Fog mandatory.

Example 1 - Fitness Tracker: Latency (0), Bandwidth ($5/month = 0), Offline (0), Privacy (0), Energy (2), Real-time (0) = 4 → Cloud-only acceptable

Example 2 - Industrial Safety: Latency (5), Bandwidth ($12K/month = 3), Offline (5), Privacy (0), Energy (0), Real-time (3) = 56 → Edge/Fog mandatory

Example 3 - Smart Agriculture: Latency (0), Bandwidth ($800/month = 3), Offline (5), Privacy (0), Energy (2), Real-time (0) = 18 → Edge/Fog strongly recommended

Common Mistake: Retrofitting Edge Intelligence After Cloud-Only Deployment

The Mistake: Building a cloud-centric IoT system, then discovering unacceptable latency/bandwidth/cost, and attempting to add edge processing as an afterthought.

Real Example - Retail Analytics:

Original design: 500 retail stores, 10 cameras per store, streaming 720p video to cloud for people counting
Bandwidth reality: 10 cameras × 2 Mbps × 500 stores = 10 Gbps total = $45,000/month
Attempted fix: Retrofit edge processing to detect people locally, send counts only

Retrofit Challenges:

Camera hardware: Existing IP cameras lack compute for ML inference (need to replace all 5,000 cameras = $500K)
Network architecture: Cloud-centric design assumed high bandwidth, no local storage at edge (need to add edge gateways = $120K)
Software rewrite: Cloud pipeline tightly coupled to raw video (6 months engineering to decouple)
Data migration: 18 months of video in cloud ($2.1M stored) must be reprocessed (7 months batch job)
Dual deployment: Must run cloud and edge simultaneously during transition (2× operational costs for 9 months)

Total retrofit cost: $500K hardware + $120K gateways + $900K engineering + $600K dual operations = $2.1M

Correct Approach (Design for Edge from Day 1): - Specify cameras with onboard ML inference ($100 vs. $95 for dumb cameras = $5K premium) - Design edge gateway architecture upfront (included in initial budget) - Build data pipeline to accept counts or video (flexible from start) - Initial cost: $5K camera premium + $120K gateways = $125K vs. $2.1M retrofit = 94% savings

Lesson: Architectural patterns (edge vs. cloud) must be decided during requirements phase, not during operations. Retrofitting distributed intelligence costs 10-20× more than designing it upfront.

Decision checkpoint: Before any IoT project, ask: “Could this require edge processing in production?” If yes, design the edge capability from day 1, even if MVP uses cloud-only for speed.

🏷️ Label the Diagram

💻 Code Challenge

2.7 Summary

Key Takeaways:

Edge computing processes data at the device level (1-10ms latency), ideal for safety-critical and real-time applications
Fog computing provides intermediate processing at local gateways (10-100ms latency), enabling multi-device coordination and 90-99% data reduction
Cloud computing handles complex analytics and long-term storage (100-300ms latency), providing unlimited compute resources
The three tiers work together in a hierarchical architecture, not as replacements for each other
Cost savings can reach 98% by processing data locally instead of transmitting everything to the cloud
Offline operation and privacy compliance are key benefits of edge/fog architectures

2.8 Knowledge Check

Quiz: Edge and Fog Computing

2.9 Concept Relationships

Concept	Relates To	Relationship Type	Why It Matters
Three-Tier Architecture	IoT Reference Models	Architectural implementation	Edge-fog-cloud realizes the hierarchical processing layers described in abstract IoT reference architectures
Edge Processing (1-10ms)	Real-Time Systems	Latency constraint	Safety-critical applications like collision avoidance require guaranteed sub-10ms response impossible with network round-trips
Fog Aggregation (10-100ms)	Bandwidth Optimization	Economic enabler	90-99% data reduction at fog layer transforms economically unviable deployments into sustainable ones
Data Gravity Principle	Cloud Migration Strategy	Cost-benefit driver	Moving compute to data (fog) is cheaper than moving data to compute (cloud) when datasets exceed terabytes
Offline Operation	System Resilience	Availability requirement	Edge/fog autonomy ensures critical functions continue during network outages common in industrial and remote environments
Privacy Preservation	GDPR/HIPAA Compliance	Regulatory driver	Local fog processing of PII satisfies data minimization requirements that cloud-only architectures violate

2.10 See Also

Deepen your understanding of edge and fog computing through these related chapters:

Edge-Fog Architecture - Detailed three-tier architecture patterns and fog node capabilities
Edge-Fog Latency Problem - Physics of network latency and why milliseconds matter for IoT
Edge-Fog Bandwidth Optimization - Quantified cost analysis and data reduction strategies
IoT Reference Architectures - Foundational architectural frameworks for distributed IoT systems
WSN Fundamentals - Wireless sensor networks with similar edge processing patterns

2.11 How It Works: Edge-Fog-Cloud in a Smart Building

Let’s trace how a single temperature reading flows through all three tiers in a real smart building deployment.

The Setup:

50-floor building with 2,000 temperature sensors (40 per floor)
Each sensor samples every 10 seconds
Goal: Optimize HVAC while reducing cloud costs

Step 1: Edge Tier (Temperature Sensor with ESP32)

// Edge device code running on ESP32
void loop() {
    float temp = dht.readTemperature();  // Read DHT22 sensor

    // Local threshold check (sub-10ms response)
    if (temp > 28.0) {  // Danger: Too hot!
        digitalWrite(ALARM_PIN, HIGH);  // Trigger local alarm immediately
        sendUrgentAlert(temp);  // Send to fog with "URGENT" flag
    }

    // Normal operation: Send to fog only if changed significantly
    if (abs(temp - lastSentTemp) > 0.5 || minutesSinceLastSend > 5) {
        sendToFog(temp);
        lastSentTemp = temp;
        minutesSinceLastSend = 0;
    }

    delay(10000);  // Wait 10 seconds
}

What happens: Edge device reads temperature locally, triggers immediate alarm if dangerous (no network latency), and filters out 95% of “normal” readings before sending to fog.

Step 2: Fog Tier (Floor Gateway - Raspberry Pi)

The fog gateway receives data from 40 sensors on one floor:

# Fog gateway code (Python on Raspberry Pi)
def process_sensor_data(sensor_id, temp):
    # Store in local time-series database
    influxdb.write(sensor_id, temp, timestamp=now())

    # Update floor aggregation
    floor_stats = calculate_floor_average()  # Average of all 40 sensors

    # Only send to cloud if floor average changed by >1°C
    if abs(floor_stats['avg'] - last_sent_avg) > 1.0:
        send_to_cloud({
            'floor': 23,
            'avg_temp': floor_stats['avg'],
            'min_temp': floor_stats['min'],
            'max_temp': floor_stats['max'],
            'sensor_count': 40
        })
        last_sent_avg = floor_stats['avg']

# Hourly summary task
@schedule.every(1).hour
def send_hourly_summary():
    summary = {
        'floor': 23,
        'hour_avg': calculate_hour_average(),
        'anomaly_count': count_threshold_violations(),
        'energy_used_kwh': read_energy_meter()
    }
    send_to_cloud(summary)

What happens: Fog gateway aggregates 40 sensors into floor-level statistics, applies second-level filtering (only send if floor average changed >1°C), and sends hourly summaries. Result: 96% further reduction from edge data.

Step 3: Cloud Tier (Azure IoT Hub + Analytics)

# Cloud analytics pipeline
def process_building_data(floor_data):
    # Receive aggregated data from 50 floors
    building_avg = calculate_building_average(all_floors)

    # Historical trend analysis
    if building_avg > historical_avg + 2:
        alert_facility_manager(
            "Building temperature trending 2°C above normal. Check HVAC system."
        )

    # Machine learning: Predict tomorrow's energy usage
    prediction = ml_model.predict(
        outdoor_forecast, day_of_week, floor_data
    )

    # Update fog gateways with new HVAC schedules
    for floor in floors:
        updated_schedule = optimize_schedule(prediction, floor)
        push_to_fog_gateway(floor, updated_schedule)

# Weekly model retraining
@schedule.every().sunday.at("02:00")
def retrain_models():
    # Use 3 months of historical data to improve prediction models
    training_data = query_warehouse(months=3)
    new_model = train_energy_prediction_model(training_data)
    deploy_to_all_fog_gateways(new_model)

What happens: Cloud receives only hourly summaries from 50 floors (not raw 2,000 sensor readings), performs building-wide analytics, trains ML models on historical data, and pushes updated schedules/models back to fog gateways.

Data Reduction Summary:

Tier	Data Volume	Processing	Reduction
Edge	2,000 sensors × 6 readings/min × 50 bytes	Threshold filtering, local alarms	95% (send only changes)
Fog	50 floors × 12 messages/hour × 200 bytes	Aggregation, local analytics	96% further (hourly summaries)
Cloud	50 messages/hour × 200 bytes	Historical analytics, ML training	Receives 0.04% of edge data

Result: ~25.9 GB/month raw edge data reduced to ~7.2 MB/month cloud data (99.97% reduction), cutting cloud bandwidth and storage costs by over 99% compared to a cloud-only architecture.

Knowledge Check: Three-Tier Data Flow

2.12 Try It Yourself

Exercise 1: Calculate Tier Placement for Your Application

Use the 50-500-5000 Rule to determine where processing should happen:

Your application: ___________________________

Answer these questions:

Latency requirement: What’s the maximum acceptable delay for a response?
- < 50ms → Edge processing mandatory
- 50-500ms → Fog processing recommended
- 5000ms → Cloud processing viable
Bandwidth volume: How much data does each device generate per day?
- 1 GB/day/device → Edge filtering mandatory
- 100 MB - 1 GB/day/device → Fog aggregation recommended
- < 100 MB/day/device → Cloud-only may work
Connectivity requirement: Must the system work during internet outages?
- Yes, safety-critical → Edge/Fog with local autonomy
- Partial degradation acceptable → Fog with buffering
- No, always connected → Cloud-only possible
Privacy sensitivity: Does the data include PII, health data, or regulated information?
- Yes, GDPR/HIPAA applies → Fog anonymization mandatory
- No, public data → Cloud-only acceptable

Decision matrix: If ANY factor indicates “mandatory” for edge/fog, cloud-only is insufficient.

Exercise 2: Implement a Simple Edge Filter

Write code for an ESP32 that sends temperature data to the cloud only when it changes significantly:

// Your task: Complete this edge filtering logic
float lastSentTemp = 0;
unsigned long lastSentTime = 0;
const float TEMP_THRESHOLD = 0.5;  // Degrees Celsius
const unsigned long HEARTBEAT_INTERVAL = 300000;  // 5 minutes in ms

void setup() {
    Serial.begin(115200);
    dht.begin();
}

void loop() {
    float currentTemp = dht.readTemperature();
    unsigned long currentTime = millis();

    // YOUR CODE HERE:
    // Send to cloud if either:
    // 1. Temperature changed by more than TEMP_THRESHOLD since last sent
    // 2. HEARTBEAT_INTERVAL elapsed since last sent (even if temp unchanged)

    // If you decide to send:
    // - Call sendToCloud(currentTemp)
    // - Update lastSentTemp and lastSentTime

    delay(10000);  // Read sensor every 10 seconds
}

Test scenario: Room temperature stable at 22°C for 1 hour. How many times should your code send data? - Answer: 12 times (heartbeat every 5 minutes, 60min / 5min = 12)

Exercise 3: Design a Fog Aggregation Strategy

Scenario: Factory floor with 100 vibration sensors sampling at 1 kHz (1,000 readings/second).

Raw data rate: 100 sensors × 1,000 Hz × 4 bytes = 400 KB/s = 34.5 GB/day

Your fog gateway has: - 4 GB RAM - 500 GB SSD - 10 Mbps uplink to cloud

Your tasks:

Design filtering: What processing happens at the fog tier to reduce 34.5 GB/day to something cloud can handle?
Calculate storage: If the fog gateway stores 24 hours of local data before overwriting, how much disk space is needed?
Determine alerts: What threshold conditions should trigger immediate cloud alerts (bypassing normal aggregation)?

Hints:

Apply FFT to detect frequency anomalies (bearings wear = specific frequency changes)
Store raw data locally for 24h forensic analysis after anomalies
Send only anomaly events + hourly statistical summaries to cloud
Target: <100 MB/day to cloud (99.7% reduction)

2.13 What’s Next?

Start your journey through edge and fog computing with the Introduction chapter.

Topic	Chapter	Description
Introduction	Edge-Fog Introduction	Core concepts, definitions, and business value of edge and fog computing
Edge AI/ML	Edge AI/ML	Machine learning inference and training at the edge
Edge Compute Patterns	Edge Compute Patterns	Data processing and computation distribution patterns
Cloud Computing Fundamentals	Cloud Computing Fundamentals	Cloud architecture basics and service models
IoT Reference Architectures	IoT Reference Architectures	Foundational architectural patterns for IoT systems