%% fig-alt: "Side-by-side comparison of protocol stacks for Wi-Fi IoT, Zigbee, and LoRaWAN showing how each technology implements different protocols at each layer: Wi-Fi uses standard TCP/IP with MQTT/CoAP, Zigbee uses IEEE 802.15.4 with its own network layer, and LoRaWAN uses LoRa physical layer with its own MAC"
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#E67E22', 'primaryTextColor': '#fff', 'primaryBorderColor': '#2C3E50', 'lineColor': '#16A085', 'secondaryColor': '#16A085', 'tertiaryColor': '#2C3E50', 'fontSize': '12px'}}}%%
graph TB
subgraph Wi-Fi["Wi-Fi IoT Stack"]
direction TB
W_App["Application<br/>MQTT / CoAP / HTTP"]
W_Trans["Transport<br/>TCP / UDP"]
W_Net["Network<br/>IPv4 / IPv6"]
W_Link["Data Link<br/>802.11 MAC"]
W_Phy["Physical<br/>2.4/5 GHz Radio"]
W_App --> W_Trans --> W_Net --> W_Link --> W_Phy
end
subgraph Zigbee["Zigbee Stack"]
direction TB
Z_App["Application<br/>Zigbee Cluster Library"]
Z_Net["Network<br/>Zigbee NWK Layer"]
Z_Link["Data Link<br/>802.15.4 MAC"]
Z_Phy["Physical<br/>2.4 GHz 802.15.4"]
Z_App --> Z_Net --> Z_Link --> Z_Phy
end
subgraph LoRaWAN["LoRaWAN Stack"]
direction TB
L_App["Application<br/>Cayenne LPP / Custom"]
L_Mac["MAC Layer<br/>LoRaWAN Class A/B/C"]
L_Phy["Physical<br/>LoRa CSS Modulation"]
L_App --> L_Mac --> L_Phy
end
subgraph Legend["Key Characteristics"]
W_Note["Wi-Fi: High bandwidth<br/>Power hungry<br/>Standard IP stack"]
Z_Note["Zigbee: Mesh network<br/>Low power<br/>Non-IP native"]
L_Note["LoRaWAN: Long range<br/>Very low power<br/>Star topology"]
end
style W_App fill:#E67E22,stroke:#2C3E50,color:#fff
style W_Trans fill:#16A085,stroke:#2C3E50,color:#fff
style W_Net fill:#16A085,stroke:#2C3E50,color:#fff
style W_Link fill:#2C3E50,stroke:#2C3E50,color:#fff
style W_Phy fill:#2C3E50,stroke:#2C3E50,color:#fff
style Z_App fill:#E67E22,stroke:#2C3E50,color:#fff
style Z_Net fill:#16A085,stroke:#2C3E50,color:#fff
style Z_Link fill:#2C3E50,stroke:#2C3E50,color:#fff
style Z_Phy fill:#2C3E50,stroke:#2C3E50,color:#fff
style L_App fill:#E67E22,stroke:#2C3E50,color:#fff
style L_Mac fill:#16A085,stroke:#2C3E50,color:#fff
style L_Phy fill:#2C3E50,stroke:#2C3E50,color:#fff
style W_Note fill:#7F8C8D,stroke:#2C3E50,color:#fff
style Z_Note fill:#7F8C8D,stroke:#2C3E50,color:#fff
style L_Note fill:#7F8C8D,stroke:#2C3E50,color:#fff
651 IoT Reference Models
651.1 Learning Objectives
By the end of this chapter, you will be able to:
- Explain why IoT needs specialized reference models: Understand the unique requirements beyond traditional networking
- Describe the ITU IoT Reference Model: Identify the four layers and cross-cutting concerns
- Apply the Cisco 7-Level IoT Model: Map IoT system components to appropriate levels
- Compare IoT protocol stacks: Analyze how Wi-Fi, Zigbee, and LoRaWAN implement layered models differently
- Design edge computing strategies: Determine where data processing should occur in an IoT architecture
TipMVU: Minimum Viable Understanding
Core concept: IoT extends traditional networking models with additional layers for edge computing, data accumulation, and business processes - recognizing that IoT systems do much more than just move data.
Why it matters: Understanding where to process data (device, edge, or cloud) affects latency, bandwidth costs, privacy, and system reliability. The wrong architecture choice can make your IoT project fail.
Key takeaway: The Cisco 7-Level model is practical for IoT design - it shows that 80% of data should be processed at the edge (Level 3) before reaching the cloud (Levels 4-7).
651.2 Prerequisites
- OSI and TCP/IP Models: Understanding of traditional layered networking models
- Encapsulation and PDUs: How data moves through protocol layers
651.3 Why IoT-Specific Reference Models?
While OSI and TCP/IP models apply to IoT, IoT has unique requirements that traditional networking models don’t address:
- Resource-constrained devices (limited CPU, memory, power)
- Massive scale (billions of devices)
- Edge computing needs (process before sending)
- Data processing pipelines (filter, aggregate, analyze)
- Application-specific services (analytics, ML, business rules)
- Cross-layer security (device to cloud)
651.3.1 IoT Protocol Stack Comparison
Different IoT technologies implement the layered model differently. This comparison shows how common IoT protocols map to the TCP/IP layers:
Key Observations: - Wi-Fi IoT: Uses standard TCP/IP stack - easy integration but power-hungry - Zigbee: Custom network layer optimized for mesh - requires gateway for IP connectivity - LoRaWAN: Minimal stack for long-range, low-power - extremely simple but limited bandwidth
WarningTradeoff: Native IP Stack vs Proprietary Protocol Stack
Option A: Use native IP stack (Wi-Fi, Thread, Cellular) - direct internet connectivity, standard tools and libraries, no translation needed at gateway Option B: Use proprietary/optimized stack (Zigbee, LoRaWAN, Z-Wave) - lower power consumption, optimized for constrained devices, requires protocol translation at gateway Decision Factors: Choose native IP when devices need direct cloud connectivity, when using standard HTTP/REST APIs, or when development speed is critical. Choose proprietary stacks when battery life is paramount (years vs months), when devices are severely constrained (<64KB RAM), or when mesh networking is required. Hybrid approaches are common: proprietary stack on edge devices, IP translation at gateway. Consider total cost including gateway complexity and cloud integration effort.
651.4 ITU IoT Reference Model
The International Telecommunication Union (ITU) developed a general four-layer model for IoT:
651.4.1 ITU Model Layers
| Layer | Name | Function |
|---|---|---|
| 4 | Application | Smart home, healthcare, industrial applications |
| 3 | Service Support | Data processing, storage, middleware |
| 2 | Network | Connectivity (Wi-Fi, cellular, LoRa) |
| 1 | Device | Physical devices, sensors, actuators, gateways |
651.4.2 Cross-Cutting Capabilities
The ITU model emphasizes Management and Security that span all layers:
- Management: Device provisioning, firmware updates, monitoring
- Security: Authentication, encryption, access control at every level
651.5 Cisco 7-Level IoT Reference Model
A more applied approach showing functionality and challenges at each level:
651.5.1 Level 1: Physical Devices and Controllers
Purpose: Endpoint devices that generate and receive data
Components: - Sensors (temperature, humidity, motion, pressure) - Actuators (motors, valves, relays) - Controllers (microcontrollers, PLCs)
Functions: - Analog-to-digital conversion - Data generation - Remote query/control capability
IoT Examples: - ESP32 temperature sensor - Smart light bulbs - Industrial pump controllers - Security cameras
651.5.2 Level 2: Connectivity
Purpose: Reliable, timely information transmission
Functions: - Communication between devices and network - Reliable delivery across networks - Protocol implementation and translation - Switching and routing - Network-level security
IoT Protocols: - Wi-Fi, Bluetooth, Zigbee, LoRaWAN - Ethernet, cellular (4G/5G) - Gateway translation (non-IP to IP)
Key point: IoT uses existing networks, doesn’t require separate infrastructure
651.5.3 Level 3: Edge (Fog) Computing
Purpose: Convert network data flows into information suitable for storage and processing
Functions: - Data filtering, cleanup, aggregation - Packet content inspection - Thresholding and event generation - Combination of network and data analytics
Processing Examples: - Evaluation: Should this data go to cloud? - Formatting: Standardize data structure - Expanding: Add context (sensor location, timestamp) - Reduction: Summarize to reduce network load - Assessment: Does this trigger an alert?
Why at the edge? Process data as close to source as possible to: - Reduce network bandwidth - Enable real-time decisions - Decrease cloud costs - Improve privacy (data stays local)
ImportantThe 80/20 Rule of Edge Computing
A well-designed IoT system processes 80% of data at the edge and sends only 20% to the cloud. Raw sensor data rarely needs to leave the local network - summaries, alerts, and exceptions are what matter.
Example: A factory with 500 vibration sensors at 1 kHz = 500 MB/s raw data. After edge processing: ~1 MB/hour of alerts and hourly summaries.
651.5.4 Level 4: Data Accumulation
Purpose: Make network data usable by applications
Key Transition: - Data-in-motion to Data-at-rest - Network packets to Database tables - Event-based to Query-based
Functions: - Persist data to storage (file system, database, big data system) - Filter and selectively store - Recombine with historical data - Bridge real-time and non-real-time worlds
Storage Types: - Time-series databases (InfluxDB, TimescaleDB) - NoSQL databases (MongoDB, Cassandra) - Big data systems (Hadoop, Spark)
651.5.5 Level 5: Data Abstraction
Purpose: Reconcile multiple data sources and formats for applications
Challenges: - Data spread across multiple locations - Different formats and schemas - Geographically distributed processing - Mix of IoT and non-IoT data
Functions: - Reconcile multiple data formats - Ensure consistent semantics - Confirm data completeness - Data virtualization (access without moving) - Authentication and authorization - Indexing for fast access
Example: Smart retail chain - Local store: real-time inventory - Regional: aggregated sales trends - Corporate: enterprise analytics
All must be accessible through unified interface!
651.5.6 Level 6: Application
Purpose: Information interpretation, reporting, and control
Software at this level: - Interacts with Level 5 (data at rest) - Does NOT operate at network speed - Varies by vertical market and business needs
Application Types: - Monitoring: Dashboard showing device status - Control: Adjusting actuators remotely - Analytics: Business intelligence reports - Management: System configuration
IoT Examples: - Smart home automation dashboard - Industrial SCADA system - Fleet management platform - Healthcare patient monitoring
651.5.7 Level 7: Collaboration and Processes
Purpose: Connect applications to people and business processes
Beyond Technology: - People using applications - Multi-step business workflows - Cross-application collaboration - Decision-making and actions
Key Insight: IoT systems are only valuable when they yield action!
Example Workflow: 1. Alert: Temperature sensor detects overheating 2. Notification: Maintenance manager receives alert 3. Collaboration: Manager consults with engineer 4. Decision: Schedule emergency maintenance 5. Action: Technician dispatched to repair 6. Documentation: Work order closed, data logged
This transcends multiple applications and requires human collaboration.
651.6 Practical Application: Where to Process?
Use the Cisco 7-Level model to decide where data processing should occur:
| Processing Need | Best Level | Rationale |
|---|---|---|
| Sensor calibration | Level 1 (Device) | Requires hardware knowledge |
| Data filtering | Level 3 (Edge) | Reduce bandwidth early |
| Real-time alerts | Level 3 (Edge) | Low latency required |
| Historical trends | Level 4 (Accumulation) | Needs stored data |
| Cross-site analytics | Level 5 (Abstraction) | Multiple data sources |
| Dashboards | Level 6 (Application) | User-facing |
| Workflow automation | Level 7 (Collaboration) | Human-in-the-loop |
651.7 Original Source Figures (Alternative Views)
NoteOSI 7-Layer Reference Model (Original Source Figure)
Source: CP IoT System Design Guide, Chapter 4 - Networking Fundamentals
NoteNetworking Model Overview (Original Source Figure)
Source: CP IoT System Design Guide, Chapter 4 - Networking Fundamentals
651.8 Summary
This chapter covered IoT-specific reference models that extend traditional networking:
- IoT requires specialized models beyond OSI/TCP-IP because of unique requirements: constrained devices, massive scale, edge processing needs, and business process integration
- Different IoT technologies implement layers differently: Wi-Fi uses standard TCP/IP, Zigbee has custom network layers, LoRaWAN has minimal protocol overhead
- The ITU IoT Reference Model provides four layers (Device, Network, Service Support, Application) with cross-cutting Management and Security capabilities
- The Cisco 7-Level IoT Model is practical for system design, covering Physical Devices, Connectivity, Edge Computing, Data Accumulation, Data Abstraction, Application, and Collaboration
- Edge computing (Level 3) is critical - process 80% of data locally to reduce bandwidth, enable real-time decisions, decrease costs, and improve privacy
- IoT systems are only valuable when they yield action - Level 7 (Collaboration) connects technology to people and business processes
651.9 What’s Next
Apply your understanding of layered models with hands-on implementation:
- Layered Models: Labs and Implementation: Deep dive into MAC addresses, IPv4/IPv6 addressing, subnet masks, ARP protocol, and Python implementations
- Layered Models: Review: Test your understanding with comprehensive knowledge checks
- IoT Reference Models (Architecture Deep Dive): Multi-layer IoT system architectures in detail
651.10 Knowledge Check
NoteRelated Chapters
Deep Dives: - Layered Models Labs and Implementation - Hands-on MAC/IP addressing, ARP, Python implementations - Layered Models Review - Comprehensive knowledge checks covering all layering concepts
IoT Reference Architectures: - IoT Reference Models - Multi-layer IoT system architectures - Architectural Enablers - Technologies enabling IoT at each layer
Protocol Stack Components: - IoT Protocols Fundamentals - How IoT protocols fit into layered models - Networking Fundamentals - Core networking principles across layers - Application Protocols - Application layer protocols (MQTT, CoAP, HTTP) - Transport Fundamentals - TCP and UDP at transport layer - Network Access Physical - Physical and data link layers
Addressing: - Networking Addressing and Subnetting - IP addressing, subnet masks, CIDR
Learning: - Videos Hub - Layered model video tutorials - Quizzes Hub - Test your OSI/TCP-IP knowledge