%% fig-alt: "Decision flowchart for IoT protocol selection. Starting with 'Does device have reliable power?', if No leads to 'Use CoAP/UDP or MQTT with QoS 0-1'. If Yes, asks 'Need request-response semantics?', if Yes leads to 'Use CoAP or HTTP'. If No, asks 'Multiple subscribers for same data?', if Yes leads to 'Use MQTT pub/sub', if No leads to 'Use CoAP or direct API calls'."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
A[Device has reliable power?] -->|No| B[Use CoAP/UDP<br/>or MQTT QoS 0-1]
A -->|Yes| C[Need request-response?]
C -->|Yes| D[Use CoAP or HTTP]
C -->|No| E[Multiple subscribers?]
E -->|Yes| F[Use MQTT pub/sub]
E -->|No| G[Use CoAP or REST API]
31 Quick Reference: Key Concepts
31.1 Overview
This page aggregates the essential βminimum viable understandingβ for core IoT concepts into a scannable quick-reference format. 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
NoteKey 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.
31.2 How to Use This Page
Each concept includes:
| Element | Purpose |
|---|---|
| One-sentence summary | The core insight in minimal words |
| Remember this rule | Practical heuristic you can apply immediately |
| When to use | Context for when this concept matters most |
TipNavigation 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
31.3 Protocols
TipMVU: 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.
31.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
31.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
31.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
31.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
31.4 Data Management
31.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
31.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
31.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
31.5 Reliability & Resilient Systems
31.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
31.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
31.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
31.6 Security
31.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
31.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
31.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
31.7 Architecture
31.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
31.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
31.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
31.8 Networking
31.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
31.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
31.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
31.9 Sensing & Actuation
31.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.
Remember this rule: Response time matters for control loops. A 1-second response sensor cannot support 10 Hz control.
Full chapter: Sensor Fundamentals and Types
31.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
31.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
31.10 Energy & Power
31.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
31.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
31.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
31.11 Design & Prototyping
31.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
31.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
31.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
31.12 Quick Decision Guide
| Situation | Recommendation |
|---|---|
| Need real-time updates to multiple subscribers | Use MQTT with QoS 1 |
| Constrained device, REST semantics needed | Use CoAP over UDP |
| Large payloads, reliable delivery required | 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 implement application-level idempotency |
| Intermittent connectivity expected | Implement store-and-forward with local buffer |
| Latency-critical decisions (<100ms) | Process at the edge, not cloud |
| Battery life is primary constraint | Maximize sleep time, minimize transmissions |
| Privacy-sensitive data | Process locally, send only aggregates |
| Simple deployment, reliable power | Star topology with Wi-Fi |
| Large area, obstacles, no power | Mesh topology with LoRa or Zigbee |
31.13 Protocol Selection Flowchart
31.14 Processing Location Decision
%% fig-alt: "Decision flowchart for determining where to process IoT data. Starting with 'Latency requirement less than 100ms?', if Yes leads to 'Process at Edge'. If No, asks 'Bandwidth cost is significant concern?', if Yes leads to 'Aggregate at Edge, analyze at Cloud'. If No, asks 'Privacy-sensitive data?', if Yes leads to 'Process at Edge/Fog', if No leads to 'Process in Cloud for scale'."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
A[Latency < 100ms required?] -->|Yes| B[Process at Edge]
A -->|No| C[Bandwidth cost concern?]
C -->|Yes| D[Aggregate at Edge<br/>Analyze in Cloud]
C -->|No| E[Privacy-sensitive data?]
E -->|Yes| F[Process at Edge/Fog]
E -->|No| G[Process in Cloud]
31.15 Key Numbers to Remember
| Metric | Typical Value | Notes |
|---|---|---|
| CR2032 battery capacity | 220 mAh | Common coin cell for IoT sensors |
| Wi-Fi transmission current | 100-300 mA | High power, short duration |
| LoRa transmission current | 20-40 mA | Lower power, longer duration |
| BLE advertisement current | 5-15 mA | Very short bursts |
| Deep sleep current | 1-10 uA | Target for battery devices |
| Indoor Wi-Fi range | 30-50m | Walls reduce significantly |
| LoRa urban range | 2-5 km | Line of sight much further |
| BLE range | 10-30m | Depends on power level |
| MQTT QoS 0 overhead | Minimal | Fire and forget |
| MQTT QoS 2 overhead | 4 packets | Exactly-once guarantee |
| CoAP header size | 4 bytes | Vs HTTP hundreds of bytes |
| 6LoWPAN compressed header | 6 bytes | Vs IPv6 40 bytes |
31.16 Study Checklist
Use this checklist to verify your understanding before exams or projects: