49  Edge Compute Patterns

49.1 Edge Fundamentals

This section provides a stable anchor for cross-references to edge computing fundamentals across the module.

49.2 Learning Objectives

By the end of this chapter series, you will be able to:

  • Classify IoT Application Types: Distinguish between Massive IoT (scale-focused) and Critical IoT (reliability-focused) patterns
  • Design Edge Architectures: Select appropriate compute placement for latency, bandwidth, and privacy requirements
  • Implement Edge Processing: Apply data filtering, aggregation, and local inference at the edge
  • Optimize Data Flow: Balance processing between edge, fog, and cloud layers for cost and performance
  • Handle Intermittent Connectivity: Design resilient systems that function during network outages
  • Apply Edge ML Patterns: Deploy machine learning models on resource-constrained edge devices

Key Concepts

  • Filter-at-source pattern: Processing raw sensor data on the sensor’s own microcontroller to discard irrelevant readings before they are transmitted, achieving maximum bandwidth reduction at minimum hardware cost.
  • Threshold-at-gateway pattern: Applying event detection rules at a local gateway that receives data from multiple sensors, enabling cross-sensor correlation impossible on individual sensor nodes.
  • Aggregate-at-fog pattern: Computing statistics (mean, variance, histogram) over a time window at a fog node, transmitting compact summaries to the cloud rather than raw readings.
  • Offload-to-cloud pattern: Transmitting all data to the cloud for centralised processing — appropriate only when edge hardware is too constrained, latency requirements are not critical, and bandwidth costs are manageable.
  • Cyber-foraging: Dynamically migrating compute tasks from resource-constrained edge devices to nearby more capable nodes (other gateways, cloudlets) based on current resource availability.
  • Partition point: The boundary in the processing pipeline that divides which computation runs on the edge device versus which runs on a higher-tier node; optimising the partition point is the key architectural decision in edge computing.
In 60 Seconds

Edge compute patterns define where and how data processing occurs along the IoT continuum from sensor to cloud — choosing the right pattern (filter-at-source, threshold-at-gateway, or aggregate-at-fog) determines the latency, bandwidth, and energy characteristics of the entire system. The fundamental principle is to process data as close to the source as feasible given resource constraints.

49.3 Chapter Overview

Edge computing positions processing power close to data sources for immediate response while maintaining cloud connectivity for centralized analytics. This chapter series covers the complete edge computing landscape:

Four-layer edge architecture diagram showing Level 1 Physical Devices at the bottom, Level 2 Connectivity, Level 3 Edge Fog Computing for data element analysis, and Level 4 Data Accumulation and storage at the top, with data flow arrows connecting each layer from edge to cloud
Figure 49.1: The edge architecture positions processing power close to data sources for immediate response while maintaining cloud connectivity for centralized analytics. This tiered approach optimizes for both latency-critical local decisions and bandwidth-efficient global insights.

49.4 Chapter Series

This topic is covered across four focused chapters:

49.4.1 1. IoT Reference Model

Understand the seven-level IoT Reference Model that defines where processing occurs:

  • Levels 1-4 (Operational Technology): Physical devices, connectivity, edge computing, data accumulation
  • Levels 5-7 (Information Technology): Data abstraction, applications, collaboration
  • Level 3 Functions: Evaluation, formatting, distillation, and assessment at the edge

49.4.2 2. Edge Processing Patterns

Master the four primary edge processing patterns:

  • Filter at Edge: Send only threshold-exceeding events (99%+ data reduction)
  • Aggregate at Edge: Compute statistics locally before transmission
  • Infer at Edge: Run ML models locally for anomaly detection
  • Store and Forward: Buffer data during connectivity outages

Includes trade-off analysis for edge ML vs cloud ML, and batch vs streaming processing.

49.4.3 3. Cyber-Foraging and Caching

Explore advanced edge computing concepts:

  • Cyber-Foraging: Opportunistically offload computation to nearby devices
  • What/Where/When Framework: Decision framework for task offloading
  • Virtualization vs Mobile Agents: Compare implementation approaches
  • Edge Caching Strategies: Multi-tier caching hierarchies for optimal latency

49.4.4 4. Practical Guide

Apply edge computing with interactive tools and real-world examples:

  • Latency Calculator: Compare device, edge, and cloud processing locations
  • Worked Examples: Factory monitoring, drone landing, memory optimization
  • Common Pitfalls: Avoid typical edge deployment mistakes
  • Knowledge Checks: Test your understanding with scenario-based questions
Minimum Viable Understanding: Edge vs Cloud Decision

Core Concept: Process data where latency, bandwidth, and reliability requirements are best met - edge for sub-100ms responses, cloud for complex analytics.

Why It Matters: Choosing the wrong processing location leads to either unacceptable latency (cloud for safety systems) or unnecessary hardware costs (edge for batch analytics). A factory safety shutdown requiring 50ms response cannot wait for 300ms cloud round-trip.

Key Takeaway: Start with your latency requirement. If under 100ms is needed, edge processing is mandatory - no amount of cloud optimization can overcome physics (speed of light limits network latency). If latency is flexible (seconds to minutes), leverage cloud for cost-effective ML and storage.

Think of edge computing like a chain of restaurants: local kitchens vs. a central warehouse.

A fast-food chain could prepare all food at one massive central kitchen and ship it everywhere (cloud computing). Or, each restaurant could have its own small kitchen that handles most orders locally (edge computing). The best approach? A mix - local kitchens for speed, central warehouse for bulk supplies.

Two main types of IoT applications:

Type Priority Example Edge Strategy
Massive IoT Scale and cost 10,000 agricultural sensors Send tiny summaries, minimize data
Critical IoT Speed and reliability Factory safety system Process locally, decide instantly

Key question this chapter answers: “Where should I process my IoT data - at the sensor, at a local gateway, or in the cloud?”

Edge Computing is like having a smart helper right next to you instead of calling someone far away!

Imagine you’re playing a game and need to make a quick decision. Would you rather: - A) Ask your friend sitting next to you (super fast!) - B) Call someone in another country and wait for them to answer (slow!)

Edge computing is like having that helpful friend nearby. Instead of sending all the information far away to the cloud (like calling another country), we process it right where the action is happening!

One day, Sammy the Sensor was monitoring the oven temperature at Max the Microcontroller’s Pizza Palace. The oven got too hot! But thanks to edge computing, Max could make a smart decision right there - without waiting for the faraway cloud. In just 50 milliseconds, the oven started cooling down. The pizza was saved!

Key Takeaway

The four primary edge processing patterns – Filter, Aggregate, Infer, and Store-Forward – cover most edge processing needs. Select patterns based on data type and criticality: Filter for threshold-based alerts, Aggregate for trend analysis, Infer for local ML decisions, and Store-Forward for intermittent connectivity resilience.

Scenario: 1,000 temperature sensors, 1 sample/minute, 20 bytes per reading. Only transmit when >2 deg C change from last reading. Normal per-reading variation follows N(0, 0.5^2).

Quick Calculation (using statistical model below):

  • Without filtering: 1,000 sensors x 1,440 min/day = 1,440,000 readings/day = 28.8 MB/day
  • With 2 deg C threshold (4 sigma): P(|delta T| > 2) = 0.00006, yielding ~86 transmissions/day = 1.72 KB/day
  • Reduction: ~16,700x (99.994% data reduction)

Filter-at-Edge Pattern: Quantifying the Trade-off Between Threshold and Bandwidth

The filter-at-edge pattern transmits only “interesting” events. Setting the threshold involves balancing bandwidth savings vs missed events:

Scenario: 1,000 temperature sensors, 1 sample/minute, transmit only when change >2 deg C from last reading

Statistical Model for temperature variation: \[ \Delta T \sim \mathcal{N}(0, 0.5^2) \quad \text{(normal variation is ±0.5°C per reading)} \]

Probability of exceeding threshold: \[ P(|\Delta T| > 2°C) = 2 \times P(Z > \frac{2 - 0}{0.5}) = 2 \times P(Z > 4) \approx 0.00006 \] \[ \text{Transmission Rate} = 1,000 \text{ sensors} \times 1,440 \text{ readings/day} \times 0.00006 = 86 \text{ transmissions/day} \]

Bandwidth Calculation: \[ \text{Without Filter} = 1,000 \times 1,440 \times 20 \text{ bytes} = 28.8 \text{ MB/day} \] \[ \text{With Filter} = 86 \times 20 \text{ bytes} = 1.72 \text{ KB/day} \] \[ \text{Reduction} = \frac{28.8 \text{ MB}}{1.72 \text{ KB}} = 16,744\times \quad \text{(99.994% savings)} \]

Threshold Sensitivity (if we lower to 1 deg C): \[ P(|\Delta T| > 1°C) = 2 \times P(Z > 2) \approx 0.046 \] \[ \text{Transmissions} = 1,440,000 \times 0.046 = 66,240 \text{ readings/day} \] \[ \text{Reduction} = \frac{1,440,000}{66,240} = 22\times \quad \text{(still 95.4% savings)} \]

The sweet spot is setting thresholds at 3-4 standard deviations of normal variation: high enough to filter noise, low enough to catch real events.

Explore how filter threshold, sensor count, and reading size affect data reduction. The statistical model assumes per-reading temperature changes follow a normal distribution N(0, sigma^2).

Pattern Use When Data Reduction Edge CPU Example
Filter Threshold-based alerts 90-99% Very Low Temperature >30°C → alert
Aggregate Trend analysis 100-1000x Low Hourly min/max/avg
Infer Local ML decisions Variable High Anomaly detection
Store-Forward Intermittent connectivity N/A Low Remote sensors, buffer for sync
Common Mistake: Edge ML Model Staleness

The Mistake: Deploying ML models to edge without update mechanism, causing accuracy degradation as environmental conditions change.

The Fix: Implement model versioning and OTA updates. Monitor edge model accuracy via cloud telemetry. Retrain cloud models weekly, push updates to edge monthly. Maintain model registry with version tracking.

49.5 Prerequisites

Before diving into this chapter series, you should be familiar with:

49.6 Knowledge Check

49.7 Concept Relationships

Edge compute patterns determine where processing occurs based on latency, bandwidth, and reliability requirements:

Core Framework (This chapter):

  • Four primary patterns: Filter (99% reduction), Aggregate (100-1000x), Infer (local ML), Store-Forward (resilience)
  • Decision criterion: Start with latency requirement – sub-100ms mandates edge, flexible latency enables cloud

Architectural Context:

Practical Application:

Data Acquisition Context:

Data Quality Integration:

Key Insight: Edge vs cloud is not a binary choice – it’s a continuum. Massive IoT (scale-focused, delay-tolerant) uses Aggregate + Store-Forward patterns. Critical IoT (reliability-focused, sub-100ms latency) uses Filter + Infer patterns. Most deployments use multiple patterns simultaneously based on data type and criticality.

49.8 What’s Next

Next Topic Description
IoT Reference Model Seven-level architecture defining where processing occurs
Edge Processing Patterns Detailed Filter, Aggregate, Infer, Store-Forward implementation
Cyber-Foraging and Caching Opportunistic compute offloading to nearby devices
Edge Patterns Practical Guide Interactive tools, worked examples, and common pitfalls
Data in the Cloud Levels 5-7 of the IoT Reference Model
ML Edge Deployment Deploying ML models on resource-constrained devices