49  Edge in the IoT Reference Model

analytics-ml
edge
patterns
iot

49.1 Start With the Story

Picture an IoT team using the ideas in Edge in the IoT Reference Model during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

In 60 Seconds

The seven-level IoT Reference Model defines where data processing occurs in IoT systems. Levels 1-3 handle operational technology (data in motion): physical devices, connectivity, and edge computing. Level 4 converts data in motion to data at rest. Levels 5-7 handle information technology: data abstraction, applications, and business collaboration. Level 3 (edge computing) is the critical transformation layer where raw data is evaluated, formatted, distilled, and assessed before storage.

Chapter Roadmap

This chapter follows data as it climbs the reference model:

  1. First separate the device, connectivity, edge-computing, and storage responsibilities.
  2. Then recompute the Level 3 bandwidth bill for vibration data.
  3. Next test the same functions against cold-chain monitoring and processing-location choices.
  4. Finally connect the model to application requirements, quizzes, and the placement-contract chapter.

Checkpoints recap the placement decisions. Calculation panels and practice exercises can be collapsed on a first read.

49.2 Learning Objectives

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

  • Explain the Seven-Level IoT Reference Model: Describe how data flows from physical devices through edge processing to cloud analytics
  • Distinguish OT vs IT Layers: Classify which levels handle operational technology (data in motion) versus information technology (data at rest)
  • Apply Level 3 Processing Functions: Implement evaluation, formatting, decoding, distillation, and assessment at the edge
  • Design for Data Accumulation: Determine appropriate storage strategies at Level 4 based on data characteristics
IoT Edge Reference Check

Key Concepts

  • IoT reference model: A standardised multi-tier architecture model (physical → network → middleware → application → business) that provides a common vocabulary and design framework for IoT system architects.
  • Device tier: The lowest layer of the IoT reference model containing physical sensors, actuators, and embedded processing — the tier where edge patterns are most directly applied.
  • Connectivity tier: The network layer responsible for transporting sensor data from devices to higher processing tiers, using protocols suited to the device’s power, range, and bandwidth constraints.
  • Edge analytics tier: An intermediate processing layer (typically gateways or fog nodes) that applies data reduction, event detection, and protocol translation before forwarding to cloud.
  • Cross-tier optimisation: Designing computation placement, data formats, and communication frequencies across multiple tiers simultaneously rather than optimising each tier in isolation.

This chapter shows where edge data processing fits in the larger IoT architecture. Think of understanding where the kitchen sits in a restaurant floor plan – knowing the overall layout helps you design each part to work well with the others. The IoT reference model maps out how data flows from sensors through edge devices to the cloud.

49.3 Prerequisites

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

Use those prerequisites as orientation: this chapter names the reference-model levels first, then asks which evidence each layer should produce.

49.4 IoT Reference Model Overview

The IoT Reference Model provides a structured framework for understanding where data processing occurs in IoT systems. It spans seven levels, from physical devices at the bottom to business collaboration at the top.

Seven-layer IoT Reference Model diagram showing Level 1 Physical Devices at bottom through Level 7 Business Collaboration at top, with Level 3 Edge Computing highlighted as the transformation layer performing evaluation, formatting, distillation, and assessment
Figure 49.1: IoT Reference Model Seven Layers with Edge Computing Functions
Latency timeline comparing edge processing path at Level 3 adding 10ms for 20-60ms total local response versus cloud path through Levels 5-7 taking seconds to minutes for deep analytics
Figure 49.2: Sequence timeline showing latency at each IoT Reference Model level

IoT Reference Model Levels 1-7: Seven-layer architecture showing transition from Operational Technology (data in motion, Levels 1-3) to Information Technology (data at rest, Levels 5-7). Level 3 edge computing performs critical functions: evaluation, formatting, reduction, and assessment before data accumulation at Level 4.

Comparison diagram showing cloud-centric architecture where all IoT devices connect to centralized cloud versus edge-centric architecture with local processing nodes reducing cloud dependency and latency
Figure 49.3: Cloud-centric vs edge-centric IoT architecture
Layered architecture diagram showing IoT devices at bottom, edge processing layer in middle performing filtering and aggregation, and cloud services at top for analytics and storage
Figure 49.4: Data at the edge architecture overview

49.5 Level 1 Devices and Controllers

The IoT Reference Model starts with Level 1: Physical devices and controllers that might control multiple devices. These are the ‘Things’ in the IoT, and they include a wide range of endpoint devices that send and receive information. Today, the list of devices is already extensive and it will become almost unlimited as more equipment is added to the IoT over time.

Device Categories at Level 1:

Category Examples Data Generated
Sensors Temperature, humidity, pressure, motion Continuous measurements
Actuators Motors, valves, switches, displays State changes, commands
Controllers PLCs, MCUs, embedded systems Processed signals, control loops
Gateways Protocol converters, edge boxes Aggregated device data

49.6 Level 2 Connectivity

Level 2 contains communications and connectivity – providing reliable, timely information transmission. This includes transmissions from devices (Level 1) to the network, across the network, and into the edge computing layer (Level 3).

Network topology diagram illustrating various IoT connectivity options including Wi-Fi, cellular, LoRaWAN, and wired connections linking devices through gateways to backend systems
Figure 49.5: Networking and connectivity in IoT systems

Connectivity Considerations:

  • Protocol selection: Match protocol to bandwidth, range, and power requirements
  • Network topology: Star, mesh, or hybrid depending on reliability needs
  • Reliability mechanisms: Acknowledgments, retransmission, error correction
  • Security: Encryption, authentication at the transport layer

49.7 Level 3 Edge Computing

Level 3 focuses on high-volume data analysis and transformation. It converts network data flows from Level 2 into information suitable for storage and higher-level processing at Level 4 (data accumulation). Level 3 processing can include:

  • Evaluation: Applying criteria to determine if data should be processed at a higher level
  • Formatting: Reformatting data to improve consistency
  • Expanding/decoding: Decrypting data and translating device-specific code
  • Distillation/reduction: Distilling data to reduce the amount of network traffic
  • Assessment: Determining whether data should trigger a response

49.8 Putting Numbers to It

Consider a fleet of 100 vibration sensors sampling at 10 kHz (10,000 samples/sec):

Without Level 3 processing (raw transmission to cloud): \[\text{Per sensor} = 10{,}000\text{ samples/s} \times 2\text{ bytes} = 20{,}000\text{ bytes/s} = 19.5\text{ KB/s}\] \[\text{Fleet total} = 19.5\text{ KB/s} \times 100 = 1{,}950\text{ KB/s} \approx 1.9\text{ MB/s}\] \[\text{Monthly bandwidth} = 1.9\text{ MB/s} \times 2{,}592{,}000\text{ s} \approx 4{,}925\text{ GB}\] \[\text{Cloud ingestion cost} = 4{,}925\text{ GB} \times \text{\$0.15/GB} \approx \text{\$739/month}\]

With Level 3 edge processing (512-point FFT every 51.2 ms):

  • Transmit only top 20 frequency components (40 bytes) at ~19.5 Hz \[\text{Per sensor} = 40\text{ bytes} \times 19.5\text{ Hz} = 780\text{ bytes/s}\] \[\text{Fleet total} = 780\text{ bytes/s} \times 100 = 78{,}000\text{ bytes/s} \approx 76\text{ KB/s}\] \[\text{Monthly bandwidth} = 76\text{ KB/s} \times 2{,}592{,}000\text{ s} \approx 197\text{ GB}\] \[\text{Cloud ingestion cost} = 197\text{ GB} \times \text{\$0.15/GB} \approx \text{\$30/month}\]

Result: Level 3 achieves 96% cost reduction ($739 to $30/month) while preserving spectral anomaly detection. This is the power of distillation at the edge.

49.8.1 Edge Bandwidth Savings Calculator

Use this interactive calculator to explore how edge processing reduces bandwidth and cost for vibration monitoring fleets.

Detailed edge IoT system architecture showing data flow from sensors through edge gateways performing real-time processing, filtering, and aggregation before selective transmission to cloud
Figure 49.6: Edge IoT architecture and processing overview

49.8.2 Level 3 Processing Functions in Detail

Evaluation determines whether data warrants further processing:

Raw reading: temperature = 23.4 C
Evaluation criteria: Alert if > 30 C or < 10 C
Result: Within normal range -> do not escalate

Formatting standardizes data from heterogeneous sources:

Device A reports: {"temp": 23.4, "unit": "C"}
Device B reports: {"temperature_f": 74.12}
Formatted output: {"temperature_celsius": 23.4, "timestamp": "2026-01-19T10:30:00Z"}

Distillation reduces data volume while preserving key information:

Input: 1000 temperature readings over 1 minute
Distillation: min=22.1, max=24.8, avg=23.4, stddev=0.5
Output: 4 values instead of 1000 (99.6% reduction)

Assessment triggers immediate local responses:

Vibration reading: 8.5 g-force (threshold: 5.0)
Assessment: CRITICAL - exceeds safe operating limit
Action: Trigger immediate machine shutdown (local actuator)

Data DoraCheckpoint: Level 3 Transformation

You now know:

  • Levels 1-2 collect and move operational data before edge processing changes it.
  • Level 3 evaluates, formats, decodes, distills, and assesses data before storage.
  • The vibration example drops monthly transfer from about 4,925 GB and $739 to about 197 GB and $30.

49.9 Cold Chain Edge Processing

With the Level 3 functions named, test whether they still hold up when the network is mobile and compliance-sensitive.

Scenario: A pharmaceutical distributor monitors 50 refrigerated trucks, each carrying 20 temperature sensors that sample at 1 Hz (once per second). The system must detect temperature excursions above 8 degrees Celsius within 30 seconds for regulatory compliance.

Without Edge Processing (Cloud-Only Architecture):

Metric Calculation Value
Raw data rate per truck 20 sensors x 1 sample/sec x 16 bytes 320 bytes/sec
Fleet data rate 50 trucks x 320 bytes/sec 16,000 bytes/sec (16 KB/s)
Daily data volume 16 KB/s x 86,400 sec 1.38 GB/day
Monthly cellular data cost 1.38 GB/day x 30 days x $0.10/MB $4,140/month
Cloud ingestion cost 41.4 GB/month x $0.25/GB (AWS IoT Core) $10.35/month
Excursion detection latency Cellular RTT (200ms) + cloud processing (500ms) 700 ms

With Level 3 Edge Processing:

Each truck runs an edge gateway (Raspberry Pi or similar) that performs:

  • Evaluation: Discard readings within 2-8 degrees Celsius (normal range). Only escalate outliers.
  • Formatting: Convert raw ADC values to Celsius, attach truck ID and GPS coordinates.
  • Distillation: Compute 1-minute averages, min/max. Replace 1,200 raw readings with 4 summary values per sensor per minute.
  • Assessment: If any sensor exceeds 8 degrees Celsius for 3 consecutive readings (3 seconds), trigger immediate alert to dispatch.
Metric Calculation Value
Distilled data rate per truck 20 sensors x 4 values/min x 8 bytes / 60 sec 10.7 bytes/sec
Fleet data rate 50 trucks x 10.7 bytes/sec 535 bytes/sec
Daily data volume 535 bytes/sec x 86,400 sec 46.2 MB/day
Monthly cellular data cost 46.2 MB/day x 30 days x $0.10/MB $139/month
Excursion detection latency Local processing on gateway 3 seconds (3 readings)

Savings Summary:

Category Cloud-Only Edge Processing Savings
Cellular data cost $4,140/month $139/month 97% reduction
Data volume 1.38 GB/day 46.2 MB/day 30x reduction
Detection latency 700 ms (but requires constant connectivity) 3 seconds (works offline) Operates during cellular dead zones
Gateway hardware cost $0 50 x $35 = $1,750 (one-time) Pays for itself in 13 days

The edge gateway investment of $1,750 saves $4,001 per month in cellular costs. More critically, the edge architecture detects temperature excursions even when trucks pass through tunnels or rural areas without cellular coverage – a compliance requirement that cloud-only architectures cannot guarantee.

Data DoraCheckpoint: Cold-Chain Edge Case

You now know:

  • The cloud-only fleet sends 16 KB/s, or 1.38 GB/day, before any filtering.
  • Level 3 summaries reduce the flow to 535 bytes/sec and 46.2 MB/day.
  • Gateway spending is justified when local alerts still work during cellular dead zones.

49.9.1 Cold Chain Cost Calculator

Adjust the parameters below to explore how edge processing affects your cold chain monitoring costs.

49.9.2 Choose the Processing Level

Not all data needs to travel to the cloud. The following decision table helps determine where to process each data stream:

Decision Factor Process at Level 3 (Edge) Process at Level 5-7 (Cloud)
Latency requirement Sub-second response needed (safety shutdowns, real-time control) Minutes to hours acceptable (trend analysis, reporting)
Data volume High-frequency raw data (>1 reading/sec per sensor) Pre-aggregated summaries (hourly/daily)
Connectivity Intermittent or expensive (cellular, satellite) Reliable broadband available
Privacy Sensitive data that should not leave premises (medical, industrial IP) Non-sensitive operational metrics
Compute complexity Simple rules, thresholds, averaging ML model training, cross-site correlation

Real-world example – vibration monitoring on rail networks: Deutsche Bahn deploys vibration sensors on approximately 5,400 ICE train wheelsets. Each sensor generates about 50 KB/second at 20 kHz sampling. Uploading everything would require approximately 23 TB/day in cellular bandwidth. Instead, edge gateways on each train run FFT (Fast Fourier Transform) locally, extract the dominant frequency peaks (~200 bytes), and upload only the spectral summary every 10 minutes. Cloud analytics then correlates these summaries across the fleet to predict bearing failures weeks before they occur. The edge processing reduces data volume by over 99.99% while preserving the diagnostic information needed for predictive maintenance.

Data DoraCheckpoint: Placement Choice

You now know:

  • Edge placement is strongest for sub-second response, high-frequency data, intermittent links, privacy, and simple local rules.
  • Cloud placement fits minutes-to-hours analysis, stored summaries, broadband links, non-sensitive metrics, and cross-site training.
  • The rail example keeps diagnostic features while avoiding roughly 23 TB/day of raw cellular upload.

49.10 Level 4: Data Accumulation (Storage)

After deciding what Level 3 should distill, decide what Level 4 must remember.

Levels 1-3 have data in motion and are event-driven. At Level 4, the data in motion is converted to data at rest. Decisions at Level 4 include:

  • Is the data of interest to higher levels?
  • Does the data need to be saved or accumulated in memory for short-term use?
  • Does persistency require a file system, big data system, or relational database?
  • What data transformations are needed for the required storage system?
  • Does the data need to be recombined or recomputed?

Storage Decision Matrix:

Data Characteristic Storage Type Example
Short-term, high-frequency In-memory buffer Last 100 sensor readings
Time-series, queryable Time-series DB (InfluxDB, TimescaleDB) Historical sensor data
Relational, structured SQL database Device configuration, metadata
Unstructured, large Object storage (S3, blob) Images, video clips
Real-time streaming Message queue (Kafka, MQTT) Event streams for processing

49.11 Application Requirements Summary

Understanding the IoT Reference Model helps match application requirements to appropriate processing levels:

Comparison diagram showing Massive IoT applications prioritizing scale and cost with batch processing versus Critical IoT applications requiring ultra-low latency real-time edge processing for safety-critical systems
Figure 49.7: Massive IoT versus Critical IoT Processing Strategies

49.12 Latency vs Bandwidth Matrix

This view shows how edge processing decisions balance latency and bandwidth requirements:

Matrix diagram showing four quadrants of IoT processing: high-latency low-bandwidth handled by cloud batch, high-latency high-bandwidth requiring edge reduction, low-latency low-bandwidth suited for direct cloud streaming, and low-latency high-bandwidth demanding full edge processing

Latency vs bandwidth trade-off matrix for IoT processing decisions

The optimal processing location depends on both latency sensitivity and data volume. Edge processing is essential when either latency is critical or bandwidth is limited.

Massive IoT vs Critical IoT Requirements: Two distinct IoT application categories – Massive IoT prioritizes scale and cost efficiency with delay tolerance (smart metering, agriculture), while Critical IoT demands ultra-low latency and high reliability for safety-critical applications (autonomous vehicles, industrial control). Edge processing strategies differ accordingly.

49.13 Interactive Quiz: Match Concepts

49.14 Interactive Quiz: Sequence the Steps

Common Pitfalls

Edge patterns like ‘filter-at-source’ and ‘aggregate-at-fog’ must be mapped to specific reference model tiers (device tier vs connectivity tier) before implementation decisions about hardware, protocol, and power can be made.

Optimising the device tier for low power and the cloud tier for analytical throughput without considering the connectivity tier in between often produces an architecture where the network is the bottleneck. Design all tiers together.

The data flow (sensor → cloud) is visible and well-designed in most architectures, but the control flow (cloud → device configuration, firmware updates) is often an afterthought. Both flows must be explicit in the reference model mapping.

The reference model for a smart building differs from one for industrial automation or connected health. Apply the reference model as a starting template and adapt tier responsibilities and protocols to the specific domain requirements.

Data DoraCheckpoint: Model Review

You now know:

  • Level 4 is the boundary where event-driven streams become retained records.
  • Massive IoT emphasizes scale and cost efficiency, while Critical IoT emphasizes real-time edge response.
  • The quizzes that follow check whether you can match, sequence, label, and code the same reference-model flow.

49.15 Label the Diagram

49.16 Code Challenge

49.17 Edge Placement Contracts

The reference-model mapping above still needs a concrete placement and evidence contract for the computation continuum. Continue to Edge Reference Model Placement Contracts for latency, bandwidth, privacy, tier-boundary, data-reduction, and accountability checks across device, edge, fog, storage, cloud, and application layers.

49.18 Summary

  • The seven-level IoT Reference Model separates operational technology (Levels 1-3, data in motion) from information technology (Levels 5-7, data at rest), with Level 4 as the transition from streaming to stored data
  • Level 1 (Physical Devices) includes all sensors, actuators, and controllers that generate or receive data
  • Level 2 (Connectivity) provides reliable, timely transmission through appropriate protocols and network topologies
  • Level 3 (Edge Computing) transforms raw data through evaluation, formatting, distillation, and assessment before storage
  • Level 4 (Data Accumulation) converts data in motion to data at rest, selecting appropriate storage types based on data characteristics
  • Massive IoT applications prioritize scale and cost at Levels 1-4 with batch processing
  • Critical IoT applications demand real-time processing at Level 3 with cloud for monitoring only
Key Takeaway

The IoT Reference Model separates edge processing (Levels 1-3, data in motion) from cloud analytics (Levels 5-7, data at rest), with Level 4 as the critical transition point. Level 3 is the edge computing layer that filters, formats, and reduces data before storage. Massive IoT applications prioritize scale and cost efficiency with batch processing, while Critical IoT demands real-time edge processing for safety and reliability.

49.19 Concept Check

Quick Knowledge Check

Q: What is the key difference between data in motion (Levels 1-3) and data at rest (Level 4+)?

Data in motion is event-driven, streaming data that flows from sensors through edge processing. Data at rest is stored in databases for batch analytics and historical queries. Level 4 is the critical transition point where real-time streams become persistent storage.

Q: Why is Level 3 edge computing called the “transformation layer”?

Level 3 performs five critical functions: evaluation (check data quality), formatting (standardize schemas), expanding (decode proprietary protocols), distillation (reduce data volume through aggregation), and assessment (trigger local responses). It transforms raw device data into cloud-ready information.

49.20 Concept Relationships

How This Concept Connects

Builds on:

Enables:

Related Concepts:

  • Massive IoT vs Critical IoT - Different processing requirements at each level
  • Gateway Architecture - Level 3 gateways handle protocol translation for non-IP devices
  • Tiered Storage - Level 4 retention policies (hot/warm/cold tiers)

49.21 See Also

Related Resources

Core Edge Computing:

Architecture Context:

Real-World Applications:

49.22 Try It Yourself

Scenario: A pharmaceutical cold chain monitoring system tracks 50 refrigerated trucks, each with 20 temperature sensors sampling at 1 Hz.

Your Task: Design the architecture for Levels 1-4:

  1. Level 1 (Devices): What sensors are needed? What’s the data format?
  2. Level 2 (Connectivity): Which protocol (Bluetooth, LoRaWAN, cellular)? Why?
  3. Level 3 (Edge Gateway): Apply the five functions:
    • Evaluation: What threshold values trigger alerts?
    • Formatting: Design the standardized data schema
    • Distillation: Calculate data reduction ratio (1 Hz raw to what summary?)
    • Assessment: What local actions (alarms, door locks)?
  4. Level 4 (Storage): What retention policy (hot/warm/cold tiers)?

What to Observe:

  • Compare bandwidth costs: raw 1 Hz data vs edge-processed summaries
  • Calculate alert latency: edge detection vs cloud detection
  • Consider offline operation: what happens during cellular dead zones?

Starter Code (Python simulation):

import time
import statistics

class ColdChainEdgeGateway:
    def __init__(self, truck_id, num_sensors=20):
        self.truck_id = truck_id
        self.buffer = []
        self.alert_threshold_max = 8.0  # degrees C

    def evaluate(self, reading):
        """Level 3: Evaluation - check data quality"""
        return 2.0 <= reading <= 10.0  # Valid range

    def format(self, sensor_id, temp_c):
        """Level 3: Formatting - standardize schema"""
        return {
            "truck_id": self.truck_id,
            "sensor_id": sensor_id,
            "temp_celsius": round(temp_c, 1),
            "timestamp_utc": time.time()
        }

    def distill(self, readings_1min):
        """Level 3: Distillation - 60 readings to 4 summary values"""
        return {
            "min": min(readings_1min),
            "max": max(readings_1min),
            "avg": statistics.mean(readings_1min),
            "stddev": statistics.stdev(readings_1min)
        }

    def assess(self, temp_c):
        """Level 3: Assessment - trigger local alarm"""
        if temp_c > self.alert_threshold_max:
            print(f"ALERT: Truck {self.truck_id} temp {temp_c} C exceeds 8 C")
            return True
        return False

# Test the gateway
gateway = ColdChainEdgeGateway("TRUCK-042")
readings = [5.2, 5.3, 5.1, 8.5, 8.9, 9.2]  # Temperature excursion!

for i, temp in enumerate(readings):
    if gateway.evaluate(temp):
        formatted = gateway.format(sensor_id=1, temp_c=temp)
        gateway.assess(temp)
        gateway.buffer.append(temp)

summary = gateway.distill(gateway.buffer)
print(f"1-minute summary: {summary}")
print(f"Data reduction: {len(gateway.buffer)} readings to 4 values")

Extension Challenge: Add Level 4 storage with tiered retention (last hour = raw data, last week = hourly summaries, beyond = daily aggregates).

49.23 Knowledge Check

Quiz: IoT Reference Model

49.24 What’s Next

Next Topic Description
Edge Reference Model Placement Contracts Tier placement evidence, data-reduction, and accountability contracts for Level 3 edge decisions
Edge Processing Patterns Four primary patterns: Filter, Aggregate, Infer, Store-Forward
Cyber-Foraging and Caching Opportunistic compute offloading and caching strategies
Edge Patterns Practical Guide Interactive tools and worked examples for architecture decisions