Architecture selection is driven by constraints: safety-critical systems (<50ms latency) need edge processing, while tolerant systems (minutes-hours) can use cloud-only. LoRaWAN saves $40,000+ over 3 years vs. NB-IoT ($3-5/device/month) for 400+ sensor deployments in one area. Hybrid architectures are the norm in production β real systems combine industrial (ISA-95) and consumer (Matter/Thread) architectures with a secure integration layer.
The Sensor Squad was hired for four very different missions, and each one needed a different plan!
Mission 1 β The Factory: Sammy the Sensor was placed on a giant machine. βIf I detect something dangerous, Max the Microcontroller needs to stop the machine in 50 milliseconds β that is faster than a blink! We canβt wait for a message to travel to the cloud and back.β
Mission 2 β The Farm: Bella the Battery powered sensors spread across hundreds of acres. βI need to last 3 years out here! We chose LoRaWAN because it is free to use after buying one gateway, instead of paying $3 per sensor per month for cellular.β
Mission 3 β The Smart Home: Lila the LED was part of a cozy home setup. βWe use Matter/Thread protocol so all the smart devices β lights, locks, thermostat β work together, no matter who made them!β
Mission 4 β The Smart City: All four squad members worked together across 50,000 sensors. βThe traffic cameras need fast AI at the edge, the air quality sensors can report slowly to the cloud, and the parking meters need real-time updates. We needed a multi-tier architecture because no single approach fits everything!β
The lesson: There is no one-size-fits-all IoT architecture. Always let your specific requirements (speed, cost, battery life, scale) guide your architecture choice!
By the end of this chapter, you will be able to:
Before diving into this chapter, you should be familiar with:
Think of it like choosing transportation for different trips:
| Trip | Best Transport | Why | IoT Equivalent |
|---|---|---|---|
| Walk to next room | Walk | Short, fast, free | Edge processing (local, instant) |
| Commute to work | Bus/train | Regular, shared route | Fog computing (regional, shared) |
| International travel | Airplane | Long distance, scheduled | Cloud computing (global, batched) |
You would not take an airplane to walk to the next room. Similarly, you would not send factory safety data to the cloud when it needs a 50ms response β process it locally at the edge instead!
Each IoT project has different βtripsβ for its data, so it needs a different combination of edge, fog, and cloud processing.
This chapter applies the architecture selection framework to real-world scenarios across multiple industries. Each example demonstrates how scale, latency, connectivity, and data volume requirements drive specific architecture decisions.
Decision Path: Medium Scale β Reliable connectivity β Industrial domain
Recommended Architecture: Industrial IoT Reference Architecture (ISA-95)
Decision Path: Medium Scale β Intermittent connectivity β Agriculture domain
Recommended Architecture: WSN-based with Fog Computing
Option A (LoRaWAN): Unlicensed spectrum (868/915 MHz), free to operate after gateway investment. Range: 2-15km rural, 1-5km urban. Data rate: 0.3-50 kbps. Power: 10-year battery life possible. Latency: seconds to minutes (class A devices).
Option B (NB-IoT): Licensed cellular spectrum, requires carrier subscription ($1-5/device/month). Range: same as cellular coverage. Data rate: 20-250 kbps. Power: 10-year battery life. Latency: 1-10 seconds with better reliability.
Decision Factors:
Choose LoRaWAN when: You control the deployment area and can install gateways, device count exceeds 1,000 where per-device cellular fees become prohibitive ($12,000-60,000/year), data rates under 50 kbps are sufficient, or you need to operate in areas without cellular coverage.
Choose NB-IoT when: Devices are geographically dispersed (no gateway coverage), existing cellular infrastructure provides adequate coverage, you need carrier-grade reliability (99.9% SLA), higher data rates (100+ kbps) are required, or total device count is under 500 where carrier fees are acceptable.
Hybrid approach: Deploy LoRaWAN for dense clusters (farms, campuses) and NB-IoT for isolated remote sites. Gateway cost: $500-2,000 covers 100-1,000 LoRaWAN devices. NB-IoT makes sense for <50 devices in an area or when cellular already exists.
Adjust the inputs to compare 3-year total cost of ownership between connectivity options.
viewof sensorCount = Inputs.range([10, 5000], {value: 400, step: 10, label: "Number of sensors"})
viewof nbiotCostMonth = Inputs.range([1, 10], {value: 3, step: 0.5, label: "NB-IoT cost ($/device/month)"})
viewof gatewayCount = Inputs.range([1, 10], {value: 1, step: 1, label: "LoRaWAN gateways needed"})
viewof yearsDeployment = Inputs.range([1, 10], {value: 3, step: 1, label: "Deployment years"})costCalc = {
const months = yearsDeployment * 12;
const nbiotTotal = sensorCount * nbiotCostMonth * months;
const lorawanGateway = gatewayCount * 800; // $800 per gateway avg
const lorawanBackhaul = gatewayCount * 50 * months; // $50/month per gateway backhaul
const lorawanServer = 200 * yearsDeployment; // $200/year network server
const lorawanTotal = lorawanGateway + lorawanBackhaul + lorawanServer;
const savings = nbiotTotal - lorawanTotal;
const breakEvenSensors = Math.ceil(lorawanTotal / (nbiotCostMonth * months));
const winner = lorawanTotal < nbiotTotal ? "LoRaWAN" : "NB-IoT";
return { nbiotTotal, lorawanTotal, savings, breakEvenSensors, winner };
}
html`<div style="background: var(--bs-light, #f8f9fa); padding: 1.25rem; border-radius: 8px; border-left: 4px solid #16A085; margin-top: 0.5rem; font-family: system-ui;">
<h4 style="margin-top:0; color: #2C3E50;">${yearsDeployment}-Year Total Cost Comparison</h4>
<div style="display: grid; grid-template-columns: 1fr 1fr; gap: 0.75rem; margin-bottom: 0.75rem;">
<div style="background: ${costCalc.winner === 'NB-IoT' ? '#f0faf7' : '#fdf2f2'}; padding: 0.75rem; border-radius: 6px; text-align: center; border-top: 3px solid #E74C3C;">
<div style="font-weight: 700; color: #E74C3C; font-size: 0.85rem; margin-bottom: 0.25rem;">NB-IoT (Cellular)</div>
<div style="font-size: 1.5rem; font-weight: 700; color: #2C3E50;">$${costCalc.nbiotTotal.toLocaleString()}</div>
<div style="font-size: 0.75rem; color: #7F8C8D;">${sensorCount} Γ $${nbiotCostMonth}/mo Γ ${yearsDeployment * 12} months</div>
</div>
<div style="background: ${costCalc.winner === 'LoRaWAN' ? '#f0faf7' : '#fdf2f2'}; padding: 0.75rem; border-radius: 6px; text-align: center; border-top: 3px solid #16A085;">
<div style="font-weight: 700; color: #16A085; font-size: 0.85rem; margin-bottom: 0.25rem;">LoRaWAN (Self-managed)</div>
<div style="font-size: 1.5rem; font-weight: 700; color: #2C3E50;">$${costCalc.lorawanTotal.toLocaleString()}</div>
<div style="font-size: 0.75rem; color: #7F8C8D;">${gatewayCount} gateway(s) + backhaul + server</div>
</div>
</div>
<div style="background: white; padding: 0.75rem; border-radius: 6px; text-align: center; margin-bottom: 0.75rem;">
<strong style="color: ${costCalc.savings > 0 ? '#16A085' : '#E74C3C'};">${costCalc.winner} saves $${Math.abs(costCalc.savings).toLocaleString()} over ${yearsDeployment} years</strong>
<div style="font-size: 0.85rem; color: #7F8C8D; margin-top: 0.25rem;">LoRaWAN break-even: ${costCalc.breakEvenSensors} sensors β below this NB-IoT is cheaper</div>
</div>
<p style="margin: 0; font-size: 0.85rem; color: #2C3E50;"><strong>Rule of thumb:</strong> With ${sensorCount} sensors over ${yearsDeployment} years, <strong>${costCalc.winner}</strong> is the more cost-effective choice. The break-even is ${costCalc.breakEvenSensors} sensors β for fewer sensors in a dispersed area, NB-IoT's zero-infrastructure cost wins.</p>
</div>`Option A (Star Topology): All sensors connect directly to a central gateway. Simpler architecture, predictable latency (single hop: 5-50ms), easier troubleshooting. Gateway is single point of failure. Range limited to gateway coverage (50-200m indoor, 1-10km outdoor depending on technology).
Option B (Mesh Topology): Sensors relay messages through each other to reach gateway. Extended range (multi-hop extends coverage), self-healing (routes around failed nodes), better coverage in complex environments. Higher complexity, variable latency (50-500ms for multi-hop), increased power consumption for relay nodes.
Decision Factors:
Choose Star when: Deployment area fits within single gateway range, latency must be predictable and low (<100ms), all sensors are battery-powered (no relay burden), network topology is stable, or simplicity is valued over coverage flexibility.
Choose Mesh when: Coverage area exceeds single gateway range, physical obstacles block direct communication (warehouses, forests), network must self-heal from node failures, some nodes can be mains-powered to serve as reliable relays, or deployment area may expand unpredictably.
Power impact: Star topology sensors with 1 message/hour achieve 5-10 year battery life. Mesh relay nodes forwarding 50 messages/hour reduce to 6-18 month battery life. Use mains power or solar for mesh relay nodes, battery for leaf nodes only.
Letβs do a detailed 5-year total cost of ownership (TCO) analysis for LoRaWAN vs NB-IoT across different farm sizes.
Scenario: Soil moisture sensors transmitting 2Γ daily, 3-year battery life target.
\[\text{NB-IoT Monthly Cost} = N_{\text{sensors}} \times \$3/\text{month}\]
\[\text{NB-IoT 5-year TCO} = N_{\text{sensors}} \times \$3 \times 60\text{ months} = N_{\text{sensors}} \times \$180\]
\[\text{LoRaWAN Infrastructure} = N_{\text{gateways}} \times \$800 + \$200\text{ network server}\]
Gateway coverage: Each gateway covers ΟrΒ² = Ο(5km)Β² β 78.5 kmΒ² β 19,400 acres.
For 400 sensors on 200 acres (< 1 kmΒ²):
\[\text{Break-even point} = \frac{\$1,000}{\$3/\text{month}} = 333\text{ sensor-months} = 28\text{ sensors for 1 year}\]
For any deployment with > 28 sensors lasting > 1 year, LoRaWAN is cheaper. With 400 sensors, LoRaWAN pays for itself in just 0.83 months!
Battery life bonus: LoRaWAN Class A transmission uses ~50 mAh/year, while NB-IoT uses ~80 mAh/year (60% more). With a 2,000 mAh battery: LoRaWAN = 40 years, NB-IoT = 25 years (both exceed 3-year replacement target).
Decision Path: Small Scale β Low latency β Smart Home domain
Recommended Architecture: Hybrid Edge-Cloud (Matter/Thread)
Decision Path: Large Scale β High data volume β Smart City domain
Recommended Architecture: Distributed Multi-Tier
Some systems have conflicting requirements that necessitate combining architectures:
When architecting an IoT system, one of the most critical decisions is where to process data. This framework guides you through the decision systematically.
Step 1: Map Your Requirements
Create a requirements matrix for your system:
| Requirement | Measurement | Threshold | Decision Weight |
|---|---|---|---|
| Latency | Time from sensor β action | < 100ms = edge required; 100ms-2s = fog optional; > 2s = cloud acceptable | Critical (40%) |
| Data Volume | Daily data generated | < 1 GB/day = cloud direct; 1-100 GB = fog filter; > 100 GB = edge mandatory | High (25%) |
| Connectivity | Network reliability | Always-on = cloud OK; intermittent = fog buffer; offline periods = edge autonomous | High (20%) |
| Device Count | Total endpoints | < 100 = cloud direct; 100-10K = fog aggregate; > 10K = edge hierarchical | Medium (10%) |
| Data Privacy | Regulatory constraints | Public data = cloud OK; PII = fog process locally; HIPAA/regulated = edge only | Critical (5%) |
Step 2: Calculate Architecture Score
For Farm Environmental Monitoring (200 soil sensors):
Weighted Score:
Verdict: Cloud-centric with LoRaWAN gateway acting as simple relay (not fog compute). The intermittent connectivity slightly favors fog but does not justify the added complexity for tolerant-latency applications.
Step 3: Cost-Benefit Analysis
| Architecture | Infrastructure Cost | Monthly Opex | Development Complexity | Maintenance Burden |
|---|---|---|---|---|
| Cloud-Centric | $500 (LoRaWAN gateway) | $50 (cloud hosting for 200 devices) | Low (standard REST APIs) | Low (single update target) |
| Fog Computing | $2,000 (edge server + redundancy) | $80 (cloud + fog power/cooling) | Medium (fog orchestration, sync) | Medium (2-tier updates) |
| Edge Processing | $8,000 (edge nodes per zone) | $120 (edge + cloud tiers) | High (distributed logic) | High (update 20+ edge nodes) |
3-year TCO:
For tolerant-latency applications, fog costs 2.1Γ and edge costs 5.4Γ more than cloud-centric with minimal functional benefit.
Step 4: Decision Tree
START: What is your latency requirement?
β
ββ < 100ms (safety-critical)
β ββ EDGE mandatory (local PLC, no cloud dependency)
β
ββ 100ms - 2s (responsive but not critical)
β ββ Data volume?
β ββ > 100 GB/day β FOG (filter at gateway)
β ββ < 100 GB/day β Is connectivity reliable?
β ββ Yes β CLOUD (simplest)
β ββ No β FOG (buffer during outages)
β
ββ > 2s (tolerant)
ββ Connectivity?
ββ Offline periods > 1 hour β FOG (autonomous operation)
ββ Intermittent OK β CLOUD (with device buffering)Common Pitfalls:
Edge for the sake of edge: βWe want to be cutting-edgeβ is not a valid architectural driver. Edge adds 3-5Γ cost and 2-3Γ complexity. Only use when latency, bandwidth, or privacy requirements mandate it.
Ignoring network costs: Cloud-centric with cellular backhaul for 1,000 devices at 1 GB/device/month = $3,000-5,000/month (NB-IoT data plans). Fog filtering to 10 MB/device saves $2,500/month, paying for fog infrastructure in 9 months.
Premature optimization: Start cloud-centric for MVP (fastest time-to-market). Measure actual latency, bandwidth, and cost in production. Migrate to fog/edge only when metrics prove the need.
Real-world validation: A smart building pilot started with cloud-centric HVAC control (2-minute latency acceptable). At 5,000-device scale, network costs hit $800/month. They added fog gateways for local aggregation, reducing bandwidth 90% and cloud costs to $120/month. The $4,000 fog infrastructure paid for itself in 6 months. Key insight: let actual data (not assumptions) drive the cloudβfogβedge migration decision.
Understanding why LoRaWAN becomes cost-effective at 400+ sensors in a concentrated area.
LoRaWAN Architecture:
Cost Breakdown (400 sensors, 3 years):
| Cost Component | LoRaWAN | NB-IoT Cellular |
|---|---|---|
| Gateway hardware | $2,000 (one-time, covers 400 sensors) | $0 (uses carrier network) |
| Gateway backhaul | $50/month Γ 36 months = $1,800 | N/A |
| Per-sensor connectivity | $0 (unlicensed spectrum) | 400 Γ $3/month Γ 36 = $43,200 |
| Network server | $200/year Γ 3 = $600 (self-hosted LoRa Server) | Included in carrier fee |
| Total 3-year TCO | $4,400 | $43,200 |
| Cost per sensor | $11 over 3 years | $108 over 3 years |
Break-Even Analysis:
Key Insight: LoRaWAN is cheaper when you have 41+ sensors within one gatewayβs coverage area. Below 41 sensors, NB-IoTβs zero upfront cost is more economical. For 1,000 sensors, LoRaWAN saves $103,600 over 3 years!
Trade-off: LoRaWAN requires self-managing the gateway (firmware updates, monitoring), while NB-IoT delegates infrastructure to the carrier. Choose LoRaWAN when cost savings justify operational overhead.
Objective: Apply the architecture selection framework to a real-world scenario.
Scenario: Youβre deploying parking sensors across a 10-block downtown area. Requirements:
Step 1: Map Requirements
| Requirement | Measurement | Architecture Implication |
|---|---|---|
| Scale | 500 sensors | Medium scale β edge aggregation beneficial |
| Latency | 5 seconds | Tolerant β cloud processing acceptable |
| Connectivity | Wi-Fi (50%), LTE (95%) | Mixed β need fallback strategy |
| Battery Life | 5 years | Low-power protocol essential |
| Data Volume | 500 Γ 10 messages/day = 5,000 msg/day | Low bandwidth β any protocol works |
Step 2: Connectivity Decision
Evaluate three options:
Step 3: Calculate Your Decision
What to Observe: At 500 sensors, LoRaWANβs upfront investment pays for itself in 6 months ($14,200 / ($90,000/60 months)). The break-even point for LoRaWAN vs NB-IoT is ~80 sensors in this scenario.
Your Task: Modify the scenario for 50 sensors (one parking garage). Recalculate β youβll find NB-IoT becomes cheaper ($9,000 vs $6,200 for minimal LoRaWAN setup). This demonstrates how scale drives connectivity decisions.
A smart factory and a wildlife monitoring system have fundamentally different requirements: the factory needs sub-second latency and deterministic messaging; the wildlife tracker needs multi-year battery life and sparse connectivity. Using the same 3-layer architecture for both will over-engineer one and under-serve the other. Always map requirements to architecture.
Healthcare IoT requires HIPAA compliance and fail-safe redundancy. Agriculture IoT must handle intermittent connectivity in rural areas. Industrial IoT requires compliance with IEC 62443 security standards. Ignoring domain constraints during architecture selection leads to expensive redesigns after deployment.
Real-world IoT deployments encounter failed sensors, network partitions, power outages, and device tampering. An architecture that performs perfectly under normal conditions but lacks graceful degradation will fail in production. Build fault tolerance and offline operation into the architecture from the beginning.
A successful 50-sensor pilot in controlled conditions does not validate an architecture for 50,000 sensors in diverse environments. Pilots rarely expose protocol scalability limits, security vulnerabilities under adversarial conditions, or maintenance burden over years. Plan architecture validation at 10x the pilot scale before committing to full deployment.
Real-world IoT deployments demonstrate that architecture selection must be driven by specific requirements:
| Scenario | Key Constraints | Architecture Choice |
|---|---|---|
| Smart Factory | Safety (<50ms), reliability | ISA-95 with edge PLCs |
| Wildlife Monitoring | Power, intermittent connectivity | WSN + fog computing |
| Smart Home | User experience, interoperability | Matter/Thread hybrid |
| Smart City | Scale, multi-domain, open APIs | Multi-tier with IoT-A |
Key insights:
| Concept | Relationship | Connected Concept |
|---|---|---|
| LoRaWAN | Becomes cost-effective at | 400+ sensors in one area (break-even vs NB-IoT cellular subscriptions) |
| Star Topology | Requires | Single-hop coverage within gateway range (50-200m indoor, 1-10km outdoor) |
| Mesh Topology | Enables | Extended range via multi-hop but shortens battery life 50-80% for relay nodes |
| Edge Processing | Mandatory when | Data volume >100 GB/day OR latency requirement <100 ms |
| Fog Computing | Provides | Regional aggregation for 100-10K device clusters before cloud transmission |
| Multi-Architecture Systems | Common in | Mixed domains (industrial + consumer) requiring different safety/UX standards |
| NB-IoT | Preferred for | Sparse deployments (<100 sensors) or wide geographic dispersion without gateway coverage |
Architecture Fundamentals:
Connectivity Technologies:
System Design:
| If you want to⦠| Read this |
|---|---|
| Study common architectural mistakes | Common Pitfalls and Best Practices |
| Select the right architecture for your use case | Architecture Selection Framework |
| Learn about edge-fog computing architectures | Edge and Fog Computing |
| Explore WSN architecture patterns | Wireless Sensor Networks |
| Study QoS for production IoT | QoS and Service Management |