27 Quick Reference: Key Concepts

27.1 Learning Objectives

After completing this chapter, you will be able to:

Apply protocol selection heuristics to choose between MQTT, CoAP, and HTTP based on power, latency, and communication pattern constraints
Use practical rules for IoT data management including UTC timestamps, payload encoding, and edge aggregation
Implement reliability patterns (exponential backoff, idempotency, store-and-forward) for resilient IoT systems
Make informed architecture decisions about edge vs fog vs cloud processing based on latency and privacy requirements

In 60 Seconds

A scannable quick-reference for core IoT concepts: protocol selection (MQTT vs CoAP vs HTTP), data management (time series, payload design, aggregation), reliability patterns (retry, idempotency, store-and-forward), security essentials (TLS, authentication, zero trust), architecture decisions (edge vs fog vs cloud), networking, sensing, energy management, and design. Each entry provides a one-sentence summary, practical rule, and link to the full chapter.

Chapter Scope (Avoiding Duplicate Hubs)

This chapter focuses on fast recall of core concepts and decision heuristics.

Use Quick Reference Cards for printable protocol tables and parameter sheets.
Use Code Snippet Library when you need runnable implementation patterns.
Use this chapter when you need concise conceptual guidance before deciding or building.

For Beginners: Quick Reference

This page collects the most important takeaway from every major IoT topic into one place. Each entry gives you a one-sentence summary, a practical rule of thumb, and a link to the full chapter if you want to learn more. It is designed for quick review - like flashcards for IoT - perfect for checking your understanding before a project, exam, or job interview.

Use this for:

Quick review before projects or exams
Study reference during lab work
Decision support when designing IoT systems
Refresher on concepts from earlier chapters

Match IoT Design Rules to Their Rationale

Order: Applying Quick Reference Concepts to Design

Place these design decision steps in the correct order.

Key Takeaway

In one sentence: IoT system design is about trade-offs - there is no single best protocol, architecture, or approach; the right choice depends on your specific constraints.

Remember this rule: Match your design decisions to your constraints: power budget determines protocol choice, latency requirements determine processing location, and reliability needs determine QoS level.

27.2 How to Use This Page

Each concept includes:

Element

One-sentence summary

The core insight in minimal words so you can recognize the concept quickly.

Element

Remember this rule

A practical heuristic you can apply immediately during design or troubleshooting.

Element

When to use

Context for when the concept matters most in real IoT decisions.

Navigation Tips

Use Ctrl+F (Cmd+F on Mac) to search for specific terms
Each section links to the full chapter for deeper learning
Print this page for offline reference during lab sessions

No-One-Left-Behind Recall Loop

Read one concept summary and one rule of thumb.
Apply it immediately to one scenario question.
Validate with one quiz or simulation touchpoint.
Reinforce with one short challenge in the games hub.

27.3 Protocols

MVU: Protocol Selection Criteria

Core Concept: Protocol choice is determined by three primary constraints - power budget (battery vs. mains), latency requirements (real-time vs. tolerant), and communication pattern (request-response vs. publish-subscribe). Why It Matters: Choosing the wrong protocol early in design forces expensive rewrites later; a battery-powered sensor using HTTP instead of CoAP may drain in weeks instead of years. Key Takeaway: For battery devices sending periodic data to multiple consumers, use MQTT with QoS 0-1; for request-response on constrained devices, use CoAP; reserve HTTP for gateways and cloud integration only.

27.3.1 MQTT (Message Queue Telemetry Transport)

In one sentence: MQTT is a lightweight publish/subscribe messaging protocol designed for unreliable networks and constrained devices.

Remember this rule: Use QoS 0 for frequent telemetry (temperature every second), QoS 1 for commands (turn on light), QoS 2 only when exactly-once matters (payment transactions).

When to use: Event-driven systems where devices need to broadcast data to multiple subscribers without knowing who is listening.

Full chapter: MQTT Fundamentals

27.3.2 CoAP (Constrained Application Protocol)

In one sentence: CoAP is a RESTful protocol over UDP designed for constrained devices that need request/response patterns with minimal overhead.

Remember this rule: Use CoAP when you need REST semantics (GET/PUT/POST/DELETE) on constrained devices; use MQTT for event-driven messaging where multiple consumers need the same data.

When to use: Direct device control, reading sensor values on demand, environments where UDP works well (local networks, not behind NAT).

Full chapter: CoAP Fundamentals

27.3.3 HTTP/HTTPS

In one sentence: HTTP provides universal compatibility but with significant overhead; reserve it for gateways and cloud integration, not edge devices.

Remember this rule: If your device has Wi-Fi and reliable power, HTTP is fine; if battery-powered or on LPWAN, use CoAP or MQTT instead.

When to use: Gateway-to-cloud communication, integration with existing web APIs, devices with ample power and bandwidth.

Full chapter: IoT Protocols Overview

27.3.4 6LoWPAN

In one sentence: 6LoWPAN compresses IPv6 headers from 40 bytes to as few as 6 bytes, enabling IP networking on constrained wireless networks like IEEE 802.15.4.

Remember this rule: Use 6LoWPAN when you need end-to-end IP connectivity on low-power mesh networks; it bridges your sensors to the internet without gateways doing protocol translation.

When to use: Sensor meshes that need native IPv6 addressing, Thread/Zigbee networks, applications requiring IP end-to-end.

Full chapter: IoT Protocols Fundamentals

27.4 Data Management

27.4.1 Time Series Data

In one sentence: Time series data requires special handling for timestamps, ordering, retention policies, and efficient aggregation over time windows.

Remember this rule: Always use UTC for storage; convert to local time only for display. Include timezone info when displaying to users.

When to use: Any sensor data collected over time - temperature logs, energy meters, machine health monitoring.

Full chapter: Data Storage and Databases

27.4.2 Payload Design

In one sentence: Payload size directly impacts battery life, bandwidth costs, and transmission success rate on constrained networks.

Remember this rule: For LPWAN (LoRaWAN, NB-IoT), use binary encoding or CBOR. For general IoT with more bandwidth, CBOR beats JSON by 30-50%. Only use JSON when human readability matters more than efficiency.

When to use: Every message design decision - smaller payloads mean longer battery life and lower data costs.

Full chapter: Edge Compute Patterns

27.4.3 Data Aggregation

In one sentence: Aggregate data at the edge to reduce bandwidth, costs, and cloud storage while preserving the insights needed for decision-making.

Remember this rule: Send aggregates (min, max, avg, count) instead of raw values when detailed history is not needed. A 1-minute summary of 60 readings uses 50x less bandwidth.

When to use: High-frequency sensors, bandwidth-constrained networks, cost-sensitive deployments.

Full chapter: Edge Compute Patterns

27.5 Reliability & Resilient Systems

27.5.1 Retry Strategies

In one sentence: Exponential backoff with jitter prevents thundering herd problems during network recovery and reduces server overload.

Remember this rule: backoff = min(base * 2^attempt + random_jitter, max_backoff). Start with 1-second base, cap at 30-60 seconds.

When to use: Any network operation that may fail - API calls, MQTT connections, firmware updates.

Full chapter: Transport Protocols

27.5.2 Idempotency

In one sentence: Idempotent operations can be safely retried without causing duplicate effects - essential for reliability over unreliable networks.

Remember this rule: Always include unique message IDs and track processed IDs for deduplication. Use PUT (idempotent) over POST (not idempotent) when possible.

When to use: Command messages, state updates, any operation where duplicates would cause problems (billing, actuator commands).

Full chapter: Transport Optimizations

27.5.3 Store-and-Forward

In one sentence: Buffer data locally during connectivity outages and transmit when connection is restored, ensuring no data loss.

Remember this rule: Size your local storage for worst-case outage duration. For a sensor sending 100 bytes every minute, a 24-hour buffer needs only 144 KB.

When to use: Remote deployments, mobile assets, any scenario where connectivity is intermittent.

Full chapter: Edge Compute Patterns

27.6 Security

27.6.1 Transport Security

In one sentence: All IoT communication should use TLS (TCP) or DTLS (UDP) to prevent eavesdropping, tampering, and man-in-the-middle attacks.

Remember this rule: Never send credentials over unencrypted connections. Use TLS 1.3 where supported; avoid TLS 1.0/1.1 entirely.

When to use: Every network connection - even on “private” networks. Encryption is cheap; breaches are expensive.

Full chapter: DTLS and Security

27.6.2 Device Authentication

In one sentence: Every device must prove its identity before accessing resources; passwords alone are insufficient for IoT scale.

Remember this rule: Use X.509 certificates or pre-shared keys provisioned during manufacturing. Never use default credentials in production.

When to use: Device provisioning, cloud connectivity, API access, firmware updates.

Full chapter: Security and Privacy Overview

27.6.3 Zero-Trust Principles

In one sentence: Never trust, always verify - treat every request as potentially malicious regardless of network location.

Remember this rule: Authenticate every request, authorize every action, encrypt every transmission, log everything for audit.

When to use: Any production deployment - especially mixed environments with devices from different vendors or ages.

Full chapter: Threat Modelling and Mitigation

27.7 Architecture

27.7.1 Edge vs Cloud Processing

In one sentence: Process at the edge when latency, bandwidth, or privacy requires it; use cloud for aggregation, ML training, and long-term storage.

Remember this rule: Filter and aggregate at the edge; store and analyze in the cloud. Ask: “What happens if cloud is unreachable for 1 hour?”

When to use: Every architecture decision - the right split depends on latency requirements, bandwidth costs, and privacy constraints.

Full chapter: Edge, Fog, and Cloud Overview

27.7.2 Three-Tier Architecture (Edge-Fog-Cloud)

In one sentence: Edge devices sense and actuate, fog nodes provide local intelligence and aggregation, cloud provides global analytics and storage.

Remember this rule: Edge for milliseconds latency, Fog for seconds latency, Cloud for minutes-to-hours analysis. Match processing tier to latency requirement.

When to use: Complex deployments with mixed latency requirements - factories, smart buildings, smart cities.

Full chapter: Edge, Fog, and Cloud Overview

27.7.3 Gateway Architecture

In one sentence: Gateways bridge constrained device networks to IP networks, handling protocol translation, security termination, and local processing.

Remember this rule: Gateways should be stateless when possible - if a gateway fails, devices should reconnect to another without data loss.

When to use: Connecting Zigbee/BLE/LoRa devices to cloud platforms, aggregating data from multiple sensors, providing local compute.

Full chapter: Mobile Phones as a Gateway

27.8 Networking

27.8.1 Network Topology Selection

In one sentence: Star topology is simple but has single point of failure; mesh provides resilience but adds complexity and latency.

Remember this rule: Use star for simple deployments with reliable power. Use mesh for large areas, obstacle-rich environments, or when redundancy matters.

When to use: Network design phase - topology choice affects range, reliability, battery life, and complexity.

Full chapter: Topologies Fundamentals

27.8.2 Wireless Range Estimation

In one sentence: Real-world range is typically 50-70% of datasheet specifications due to obstacles, interference, and antenna orientation.

Remember this rule: For planning, assume half the datasheet range. Test in the actual deployment environment before finalizing design.

When to use: Site surveys, deployment planning, selecting wireless technology (Wi-Fi vs BLE vs LoRa vs cellular).

Full chapter: Design Implications

27.8.3 Protocol Stack for Constrained Devices

In one sentence: Constrained devices use UDP/CoAP instead of TCP/HTTP to minimize overhead, handshakes, and power consumption.

Remember this rule: TCP overhead is acceptable for powered devices. For battery-powered sensors, UDP-based protocols (CoAP, DTLS) extend battery life by 3-10x.

When to use: Selecting application and transport protocols for battery-powered devices.

Full chapter: IoT Protocols Overview

27.9 Sensing & Actuation

27.9.1 Sensor Selection

In one sentence: Match sensor accuracy, resolution, and response time to your application needs - over-specifying wastes money and power.

Remember this rule: Resolution is not accuracy. A sensor with 0.01 degree resolution may only be accurate to ±2 degrees. Always check both specifications. Response time matters for control loops - a 1-second response sensor cannot support 10 Hz control.

When to use: Component selection, system design, choosing between low-cost and precision sensors.

Full chapter: Sensor Fundamentals and Types

27.9.2 Sensor Calibration

In one sentence: Sensors drift over time and vary between units; calibration ensures measurements are accurate and comparable across your fleet.

Remember this rule: Calibrate at installation and periodically thereafter. Store calibration coefficients in non-volatile memory.

When to use: Any precision application, before deployment, after sensor replacement.

Full chapter: Sensor Interfacing and Processing

27.9.3 Actuator Safety

In one sentence: Actuators move things in the physical world - failures can cause damage, injury, or death. Design for safe failure modes.

Remember this rule: Define the safe state and ensure the system returns to it on power loss, software crash, or communication failure. Fail-safe, not fail-dangerous.

When to use: Any system with motors, valves, heaters, or other physical actuators.

Full chapter: Actuators

27.10 Energy & Power

27.10.1 Battery Life Estimation

In one sentence: Battery life depends on average current draw, which is dominated by transmit time for most IoT devices.

Remember this rule: Battery Life (hours) = Capacity (mAh) / Average Current (mA). A CR2032 (220mAh) at 10uA average lasts 2.5 years.

When to use: Every battery-powered design - calculate expected life before prototyping.

Full chapter: Energy Aware Considerations

Putting Numbers to It

A LoRaWAN sensor transmits 12 bytes every 10 minutes using SF7 at 14 dBm. What battery life can we expect with a CR2032 (220 mAh)?

Calculate airtime: At SF7 on 125 kHz bandwidth, 12-byte payload takes ~40 ms.

Current consumption breakdown: \[ \begin{align} \text{Deep sleep: } & 1\,\mu\text{A} \times 600\,\text{s} = 600\,\mu\text{As} = 0.167\,\mu\text{Ah}\\ \text{TX @ 14 dBm: } & 30\,\text{mA} \times 0.04\,\text{s} = 1,200\,\mu\text{As} = 0.333\,\mu\text{Ah}\\ \text{Sensor read: } & 5\,\text{mA} \times 0.1\,\text{s} = 500\,\mu\text{As} = 0.139\,\mu\text{Ah}\\ \hline \text{Per cycle (10 min): } & 0.639\,\mu\text{Ah} \end{align} \]

Daily consumption: \(0.639\,\mu\text{Ah/cycle} \times 144\,\text{cycles/day} = 92.0\,\mu\text{Ah/day} = 0.092\,\text{mAh/day}\)

Expected battery life: \(220\,\text{mAh} \div 0.092\,\text{mAh/day} = 2,391\,\text{days} \approx 6.5\,\text{years}\)

Note: Sleep current dominates (26%), followed by TX (52%)! Optimizing sleep from 1 µA to 0.5 µA extends life by 18%, while reducing TX power from 14 dBm to 10 dBm (20 mA) extends life by 38%.

Interactive Battery Life Calculator

Adjust the parameters below to see how they affect battery life:

Show code

viewof battery_capacity = Inputs.range([50, 3000], {value: 220, step: 10, label: "Battery capacity (mAh)"})
viewof sleep_current = Inputs.range([0.5, 50], {value: 1, step: 0.5, label: "Sleep current (µA)"})
viewof tx_current = Inputs.range([10, 150], {value: 30, step: 5, label: "TX current (mA)"})
viewof tx_time = Inputs.range([10, 500], {value: 40, step: 10, label: "TX time (ms)"})
viewof sensor_current = Inputs.range([1, 20], {value: 5, step: 1, label: "Sensor read current (mA)"})
viewof sensor_time = Inputs.range([10, 500], {value: 100, step: 10, label: "Sensor read time (ms)"})
viewof cycle_minutes = Inputs.range([1, 60], {value: 10, step: 1, label: "Cycle interval (minutes)"})

Show code

battery_calc = {
  const cycle_seconds = cycle_minutes * 60;
  const tx_seconds = tx_time / 1000;
  const sensor_seconds = sensor_time / 1000;

  // Convert to µAh per cycle
  const sleep_uah = sleep_current * cycle_seconds / 3600;
  const tx_uah = tx_current * 1000 * tx_seconds / 3600;
  const sensor_uah = sensor_current * 1000 * sensor_seconds / 3600;
  const total_uah = sleep_uah + tx_uah + sensor_uah;

  // Daily and lifetime
  const cycles_per_day = 1440 / cycle_minutes;
  const daily_uah = total_uah * cycles_per_day;
  const daily_mah = daily_uah / 1000;
  const lifetime_days = battery_capacity / daily_mah;
  const lifetime_years = lifetime_days / 365;

  // Percentages
  const sleep_pct = (sleep_uah / total_uah) * 100;
  const tx_pct = (tx_uah / total_uah) * 100;
  const sensor_pct = (sensor_uah / total_uah) * 100;

  return {
    sleep_uah, tx_uah, sensor_uah, total_uah,
    cycles_per_day, daily_mah, lifetime_days, lifetime_years,
    sleep_pct, tx_pct, sensor_pct
  };
}

Show code

html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
<h4 style="margin-top: 0; color: #2C3E50;">Results</h4>
<div class="mvu-battery-grid">
  <div class="mvu-battery-card">
    <h4>Per-cycle consumption</h4>
    <strong>${battery_calc.total_uah.toFixed(3)} µAh</strong>
  </div>
  <div class="mvu-battery-card">
    <h4>Daily consumption</h4>
    <strong>${battery_calc.daily_mah.toFixed(3)} mAh</strong>
    <p>${battery_calc.cycles_per_day.toFixed(0)} cycles per day</p>
  </div>
  <div class="mvu-battery-card">
    <h4>Expected battery life</h4>
    <strong style="color: #16A085;">${battery_calc.lifetime_days.toFixed(0)} days</strong>
    <p>${battery_calc.lifetime_years.toFixed(1)} years</p>
  </div>
  <div class="mvu-battery-card">
    <h4>Energy breakdown</h4>
    <strong>Sleep ${battery_calc.sleep_pct.toFixed(0)}%</strong>
    <p>TX ${battery_calc.tx_pct.toFixed(0)}% | Sensor ${battery_calc.sensor_pct.toFixed(0)}%</p>
  </div>
</div>
<p style="margin-bottom: 0; margin-top: 0.75rem; font-size: 0.9rem; color: #7F8C8D;">
<strong>Tip:</strong> ${battery_calc.tx_pct > battery_calc.sleep_pct
  ? "TX dominates power consumption. Consider reducing TX power or increasing interval."
  : "Sleep current dominates. Use the lowest-power sleep mode available."}
</p>
</div>`

27.10.2 Duty Cycling

In one sentence: Keep devices asleep 99%+ of the time, waking only to sense, process, and transmit - this extends battery life by 10-100x.

Remember this rule: 1% duty cycle = 100x battery life improvement. A device awake 1 second per minute (1.67% duty) uses 60x less energy than always-on.

When to use: All battery-powered devices. Even powered devices benefit from duty cycling to reduce heat and wear.

Full chapter: Energy Aware Considerations

27.10.3 Energy Harvesting

In one sentence: Solar, thermal, and vibration energy can power IoT devices indefinitely, but only if average consumption is extremely low (microwatts).

Remember this rule: Indoor solar provides 10-100 uW/cm2. Size your solar cell for your average power budget plus 2-3x margin for cloudy days.

When to use: Remote deployments where battery replacement is impractical, perpetual monitoring applications.

Full chapter: Context-Aware Energy Management

27.11 Design & Prototyping

27.11.1 Rapid Prototyping

In one sentence: Validate your concept quickly with off-the-shelf hardware before investing in custom design.

Remember this rule: Use Arduino/ESP32 for proof-of-concept, then move to custom PCB only when requirements are proven. 80% of prototypes never need custom hardware.

When to use: Every new project. Prove the concept works before optimizing.

Full chapter: Prototyping Hardware

27.11.2 Reading Datasheets

In one sentence: Datasheets contain critical specifications that determine whether a component works for your application - learn to read them quickly.

Remember this rule: Check these first: supply voltage range, current consumption (active/sleep), operating temperature, interface type (I2C/SPI/UART), and accuracy specifications.

When to use: Component selection, design verification, troubleshooting.

Full chapter: Reading a Spec Sheet

27.11.3 Testing and Validation

In one sentence: Test in conditions that match or exceed production environments - lab conditions rarely reflect real-world challenges.

Remember this rule: Test at temperature extremes, with interference, with weak signals, after weeks of operation. If it works in the lab but not in the field, you did not test enough.

When to use: Before any production deployment, during certification, after design changes.

Full chapter: Testing and Validation

Decision Framework: Protocol Selection by Use Case

Use this shortlist to eliminate poor fits quickly, then prototype the simplest viable candidate.

Publish / subscribe

MQTT

Strong when multiple consumers need the same data stream and cloud or broker connectivity is available.

Multiple subscribers QoS delivery Heavy for tiny batteries

Good fit for event-driven telemetry and command channels.
Weak fit when you need years of battery life without reliable IP backhaul.

Constrained REST

CoAP

Best when devices need REST semantics with low overhead and low-latency local communication.

Battery friendly Low latency Observe is limited pub/sub

Strong for direct device control, local reads, and constrained UDP environments.
Weak fit when kilometer-range networking or large ecosystem tooling matters more.

Universal web compatibility

HTTP / HTTPS

Use when compatibility with browsers, gateways, and existing web APIs outweighs overhead.

Web API ecosystem Reliable TCP delivery Poor for constrained nodes

Strong for gateway-to-cloud integration and powered devices on Wi-Fi or Ethernet.
Avoid for coin-cell sensors or ultra-low-bandwidth links.

Long range low power

LoRaWAN

Strong when you need kilometers of range and multi-year battery life from sparse uplink traffic.

Long range Battery optimized Needs gateway bridge

Best for remote sensing and sparse telemetry where seconds of delay are acceptable.
Weak fit for real-time control or direct multi-subscriber application logic.

Ultra-low-power local links

BLE

Use when devices operate nearby and power is extremely limited.

Low power Fast local interaction Short range only

Strong for wearables, peripherals, commissioning, and room-scale sensing.
Not suitable for kilometer coverage or large pub/sub distribution.

How to Use This Table:

List your 3 most critical requirements (e.g., battery-powered + long-range + multiple subscribers)
Eliminate protocols with ❌ for any critical requirement
For remaining protocols with ✅, compare secondary factors (cost, complexity, ecosystem)
If multiple protocols remain viable, prototype with the simplest option first

Example Decision: Smart agriculture with soil sensors 5km from gateway, battery-powered (5-year life), sending data every hour to multiple consumers (farmer app, analytics system, irrigation controller).

❌ Eliminate HTTP (high overhead, battery drain)
❌ Eliminate BLE (range too short)
❌ Eliminate MQTT (battery life inadequate for 5 years)
✅ LoRaWAN (long-range, ultra-low power) BUT needs gateway to bridge to MQTT for multiple subscribers
⚠️ CoAP (low power) BUT range requires IP network infrastructure

Result: LoRaWAN sensors → LoRaWAN gateway → MQTT broker → multiple subscribers. LoRaWAN for sensors (battery life), MQTT for cloud distribution (multiple consumers).

27.12 Quick Decision Guide

Need real-time updates to multiple subscribers

Use MQTT with QoS 1.

Constrained device with REST semantics

Use CoAP over UDP.

Large payloads and reliable delivery

Use HTTP/HTTPS.

Low-power, long-range connectivity

Use LoRaWAN or NB-IoT with binary encoding.

Need exactly-once delivery

Use MQTT QoS 2 or application-level idempotency.

Intermittent connectivity expected

Implement store-and-forward with a local buffer.

Latency-critical decisions under 100 ms

Process at the edge, not in the cloud.

Battery life is the primary constraint

Maximize sleep time and minimize transmissions.

Privacy-sensitive data

Process locally and send only aggregates.

Simple deployment with reliable power

Use star topology with Wi-Fi.

Large area with obstacles and limited power

Use mesh topology with LoRa or Zigbee.

27.13 Protocol Selection Flowchart

Protocol Selection Flowchart

Start by choosing the constraint you cannot compromise.

↓

Long range + battery

LoRaWAN or NB-IoT

Choose these when kilometer-scale coverage and sparse sensor uplinks matter most.

Add a gateway or cloud bridge if multiple subscribers need the data.

Multiple subscribers

MQTT

Use when the same event stream must fan out to dashboards, alerts, and automation.

Prefer QoS 0 for frequent telemetry and QoS 1 for important commands.

Constrained REST APIs

CoAP

Pick this when devices need GET/PUT/POST semantics without full HTTP overhead.

Good for direct device control and local request/response workflows.

Web compatibility

HTTP / HTTPS

Use when compatibility with gateways, browsers, and existing APIs is the priority.

Best suited to powered devices or gateway-to-cloud links.

27.14 Processing Location Decision

Processing Location Decision

Route logic to the tier that matches your latency, privacy, and coordination needs.

↓

Sub-100 ms or safety critical

Edge

Keep sensing, control loops, and immediate fail-safe behavior on the device.

Best for local actuation, filtering, and operating through outages.

Local coordination across devices

Fog / Gateway

Use an on-site node when several devices need shared context or local orchestration.

Good for buffering, aggregation, and site-level dashboards.

Fleetwide analytics and history

Cloud

Move storage, reporting, and ML training to the cloud when seconds-to-minutes latency is acceptable.

Send aggregates or filtered events if bandwidth or privacy is constrained.

27.15 Key Numbers to Remember

CR2032 battery capacity

220 mAh

Common coin cell for IoT sensors.

Wi-Fi transmission current

100-300 mA

High power, short duration bursts.

LoRa transmission current

20-40 mA

Lower power, longer duration.

BLE advertisement current

5-15 mA

Very short bursts for local discovery.

Deep sleep current

1-10 uA

Target range for battery-powered devices.

Indoor Wi-Fi range

30-50 m

Walls and interference reduce this quickly.

LoRa urban range

2-5 km

Line of sight can extend it much further.

BLE range

10-30 m

Depends strongly on power level and environment.

MQTT QoS 0 overhead

Minimal

Fire-and-forget delivery.

MQTT QoS 2 overhead

4 packets

Exactly-once guarantee costs more exchanges.

CoAP header size

4 bytes

Much smaller than typical HTTP headers.

6LoWPAN compressed header

6 bytes

Versus 40 bytes for full IPv6.

27.17 See Also

Code Snippet Library — Ready-to-use implementations of quick reference concepts
Discussion Prompts Hub — Debate trade-offs mentioned in quick reference
Hands-On Labs Hub — Practice quick reference concepts with guided labs
Learning Recommendations — Get personalized next steps based on quick reference topics
Concept Navigator — Explore connections between quick reference concepts
IoT Games Hub — Reinforce quick recall under time pressure

Common Pitfalls

1. Treating MVU Summaries as Complete Understanding

The Minimum Viable Understanding cards condense complex topics into 3-5 key points. While sufficient for recognizing concepts in context, they are not sufficient for designing, implementing, or troubleshooting systems. Use MVU cards to verify baseline familiarity, then study the full chapters for topics you need to apply.

2. Using Quick Reference in Place of Hands-On Practice

Reference cards support recall but do not build application skill. A card summarizing MQTT QoS levels cannot substitute for implementing MQTT message delivery in a lab. Pair quick reference review with hands-on lab exercises to build the procedural memory that complements conceptual understanding.

3. Reviewing All Cards Instead of Targeting Weak Areas

Reviewing 286 MVU cards in sequence is inefficient. Use quiz results and self-assessment to identify which concepts need review, then target those specific cards. Focused review of 10 weak concepts is more valuable than general review of 100 concepts you already know.

🧠 Knowledge Check

27.18 What’s Next

If you want to…	Read this
Go deeper on any MVU concept	Interactive Concept Navigator
Test your MVU knowledge formally	Quiz Navigator
Find full chapters for specific topics	Knowledge Map
Access code examples for quick reference	IoT Code Snippet Library

27.19 Related Hubs

Simulation Playground: Hands-on practice with protocols and architectures
Quiz Navigator: Test your understanding with self-assessment quizzes
Knowledge Gaps Tracker: Identify and address weak areas
Video Library: Visual explanations of key concepts
Knowledge Map: See how all concepts connect

Previous	Current	Next
Quick Reference Cards	MVU Quick Reference	Discussion Prompts

Label the Diagram

Code Challenge