4  IoT Glossary

Comprehensive Reference of Internet of Things Terminology

Reference usability can be estimated by lookup coverage:

\[ U = \frac{N_{\text{resolved-lookups}}}{N_{\text{total-lookups}}} \]

Worked example: If learners perform 220 glossary lookups and 198 are resolved without leaving the section, usability is \(198/220=90\%\). Improving cross-references and examples should push this ratio higher.

4.1 Learning Objectives

  • Retrieve precise definitions for 100+ essential IoT terms spanning protocols, architecture, networking, security, and hardware
  • Differentiate commonly confused terms (e.g., authentication vs. authorisation, edge vs. fog computing) using the “Common confusions” guidance
  • Trace cross-references to deepen understanding of related concepts across the glossary
In 60 Seconds

This unified glossary provides precise definitions for 100+ IoT terms across protocols, architecture, networking, data management, security, and hardware. Entries are organized alphabetically and cross-referenced across the IoT course to help you trace how terms connect. When you encounter an unfamiliar term in any chapter, look it up here to get the definition, disambiguation from similar terms, and a pointer to the chapter where the concept is covered in depth.

4.2 Key Concepts

  • Term Disambiguation: Clarification of the distinct meaning between commonly confused IoT terms (e.g., edge vs fog, authentication vs authorization, latency vs throughput) provided alongside each definition
  • Cross-Reference: Links within glossary entries to related terms and course chapters where the concept is applied in context, enabling depth-first exploration of related concepts
  • Acronym Expansion: The full form of an abbreviation (e.g., MQTT = Message Queuing Telemetry Transport) provided at the start of each entry to eliminate ambiguity when the same acronym appears in different contexts
  • Technical Definition: A precise, implementation-accurate description of an IoT term suitable for use in engineering documentation and system design decisions
  • Plain Language Explanation: A accessible description of an IoT concept without assuming domain knowledge, supporting learners from diverse backgrounds as per the ‘No One Left Behind’ platform principle
  • Related Terms: A list of concepts that share terminology, implementation details, or conceptual dependencies with the defined term, guiding systematic exploration of related knowledge areas
  • Standards Reference: Where applicable, the IEEE, IETF, or industrial standard document number that formally defines the term, enabling engineers to locate authoritative specifications
  • Example Application: A concrete IoT use case illustrating where and why the defined concept is applied, connecting abstract definitions to practical engineering decisions

4.3 For Beginners: IoT Glossary

A glossary is like a dictionary for technical terms. When you are learning about IoT, you will encounter many unfamiliar words like MQTT, CoAP, or LoRaWAN. Instead of guessing what they mean, you can look them up here to get a clear, simple explanation. Think of this as your reference guide - whenever you see a term you do not understand in other chapters, come back here to find out exactly what it means and why it matters.

MVU: IoT Terminology

Core Concept: IoT vocabulary spans protocols (MQTT, CoAP), architectures (edge, fog, cloud), networking (mesh, star, gateway), and hardware (MCU, GPIO, ADC) - each term has precise meaning that affects design decisions.

Why It Matters: Misunderstanding terminology leads to selecting wrong protocols, misconfiguring systems, and communication breakdowns with vendors and team members.

Key Takeaway: When encountering an unfamiliar term, check both its definition AND the “Common confusions” section to avoid mistakes that propagate through your entire design.

4.4 Introduction

This glossary provides comprehensive definitions for key terms used throughout this IoT textbook. Each entry includes a technical definition, a plain language explanation, common confusions to avoid, and related terms for further exploration.

How to use this glossary:

  • Terms are organized alphabetically across three focused chapters
  • Each term has a unique anchor ID for cross-referencing (e.g., #term-mqtt)
  • Related terms link to other glossary entries across chapters
  • “In simple terms” sections provide accessible explanations

4.5 Glossary Sections

Navigate to the section containing your term of interest:

4.5.1 A-F: ACL to Frame

32 terms covering security fundamentals, data formats, architecture patterns, and reliability concepts.

Key terms include:

  • Security: ACL, Authentication, Authorization, Certificate, Encryption, Firewall
  • Protocols: AMQP, BLE, CoAP, DDS, DTLS
  • Architecture: Broker, Cloud, Edge Computing, Fog Computing, Digital Twin
  • Data: Aggregation, CBOR, Compression, Data Lake, ETL
  • Reliability: ACK, At-least-once, At-most-once, Exactly-once, Backoff, Circuit Breaker

4.5.2 G-P: Gateway to Publisher

30 terms covering network infrastructure, hardware interfaces, protocols, and messaging patterns.

Key terms include:

  • Protocols: HTTP, HTTPS, LoRa, LoRaWAN, MQTT, Modbus, OPC-UA
  • Networking: Gateway, Latency, LPWAN, LTE-M, Mesh, NB-IoT
  • Hardware: GPIO, I2C, Microcontroller, MTU, Packet
  • Data: InfluxDB, JSON, Metadata, Payload, Protobuf
  • Architecture: Matter, Microservices, Middleware, Platform

4.5.3 Q-Z: QoS to 6LoWPAN

35 terms covering quality of service, databases, wireless protocols, and reference concepts.

Key terms include:

  • Wireless: Sigfox, Thread, Wi-Fi, Zigbee, Z-Wave, 6LoWPAN
  • Messaging: QoS, Subscriber, Subscription, Topic, Wildcard
  • Databases: Time Series, TimescaleDB, TSDB, Sampling, Schema
  • Security: TLS, Token
  • Hardware: SoC, SPI, UART

4.6 Category Summary

This glossary covers 100+ essential IoT terms across key categories:

Category Count Examples
Protocols 20+ MQTT, CoAP, HTTP, BLE, LoRaWAN, Zigbee
Architecture 15+ Gateway, Edge, Fog, Cloud, Broker, Digital Twin
Networking 15+ Topic, Channel, Mesh, QoS, Latency, Routing
Data 15+ Payload, JSON, CBOR, Schema, Telemetry
Reliability 10+ QoS, ACK, Retry, Backoff, Idempotency
Security 10+ TLS, Authentication, OAuth, Encryption
Hardware 10+ Sensor, Actuator, MCU, GPIO, ADC
Data Management 5+ TSDB, InfluxDB, ETL, Data Lake

Use the cross-references within each section to explore related concepts and build a comprehensive understanding of IoT terminology.

4.7 Quick Reference by Topic

Looking for protocol comparisons? Start with MQTT and CoAP.

Understanding wireless options? Compare BLE, Zigbee, Thread, and LoRaWAN.

Learning about architecture? See Edge Computing, Fog Computing, and Cloud.

Exploring data management? Check Time Series, TSDB, and Aggregation.

Security fundamentals? Review TLS, Authentication, and OAuth.

You’re designing a smart agriculture monitoring system. Here’s how to use this glossary to create a professional design specification:

Step 1: Protocol Selection

  • Requirement: Battery-operated sensors in a 2-hectare field
  • Glossary research: Compare LoRaWAN vs Wi-Fi vs Zigbee
  • Decision: LoRaWAN for LPWAN coverage (10+ km), 10-year battery life
  • Documentation: “We selected LoRaWAN (glossary: long-range low-power WAN) for its 15 km range and ability to operate on 2×AA batteries for 5+ years”

Step 2: QoS Configuration

  • Requirement: Soil moisture data every 30 minutes, occasional pump control commands
  • Glossary research: Review QoS levels and At-least-once delivery
  • Telemetry design: MQTT QoS 0 for sensor data (acceptable loss, 1,440 readings/day)
  • Command design: MQTT QoS 2 (Exactly-once) for pump control (prevent duplicate activations)
  • Power impact calculation: QoS 2 uses 3× transmissions (PUBLISH, PUBREC, PUBREL), increasing energy by 5% compared to QoS 0

Step 3: Data Schema Design

  • Glossary research: Compare JSON (human-readable) vs CBOR (compact binary)
  • Telemetry payload: 145 bytes JSON → 68 bytes CBOR (53% reduction)
  • Transmission time: At LoRa SF7/125kHz → JSON: 412 ms, CBOR: 193 ms
  • Energy savings: 219 ms × 50 mA = 3.04 mAh/day saved (10% battery life extension)
  • Decision: Use CBOR for sensors, JSON for cloud API (see Serialization)

Step 4: Edge vs Cloud Processing

  • Glossary research: Edge Computing vs Cloud vs Fog Computing
  • Analysis: Field gateway has ESP32 (240 MHz, 520 KB RAM)
  • Decision matrix:
    • Local averaging: Edge (reduce 1,440 readings → 48 hourly averages, 97% bandwidth reduction)
    • Anomaly detection: Edge (detect sensor failures locally, prevent false alarms)
    • ML predictions: Cloud (RandomForest model requires 128 MB RAM, 45× gateway capacity)
    • Historical analytics: Cloud (5-year dataset = 2.1 GB)

Resulting Design Document

Agriculture Monitoring Architecture
====================================

Data Collection Layer
- Protocol: LoRaWAN Class A (glossary: lorawan)
- Devices: 24× soil moisture sensors (LoRa nodes)
- Sampling: 30-minute intervals
- Payload: CBOR (68 bytes vs 145 bytes JSON, 53% reduction)
- Battery life: 5.2 years (2×AA lithium, calculated via glossary formulas)

Gateway Layer (Fog Computing)
- Device: ESP32-based LoRaWAN gateway
- Edge processing: Local data aggregation (1,440→48 values/day)
- Anomaly detection: Sensor health monitoring (local alerts)
- Uplink: LTE-M cellular (monthly 2.4 GB → 82 MB after edge processing)

Cloud Layer
- Protocol: HTTPS REST API (glossary: rest)
- Security: TLS 1.3 + JWT tokens (glossary: tls, token)
- Storage: Time-series database (glossary: tsdb) - InfluxDB
- Analytics: ML crop health prediction models
- Retention: 90-day hot storage, 5-year cold archive

QoS Configuration
- Sensor telemetry: MQTT QoS 0 (glossary: qos, at-most-once)
  Rationale: 48 redundant readings/day, single loss acceptable
- Pump commands: MQTT QoS 2 (glossary: exactly-once)
  Rationale: Prevent duplicate irrigation (water waste)
- Gateway health: MQTT QoS 1 (glossary: at-least-once)
  Rationale: Ensure monitoring team receives alerts

Key Lesson: The glossary enabled precise terminology, quantitative comparisons, and professional justifications for every design decision.

Use this framework to navigate the 100+ term glossary efficiently based on your project phase and decision type.

Project Phase Key Decisions Start With These Terms Cross-Check Against
Requirements Communication range, power budget, data volume LPWAN, Latency, Bandwidth Battery, Duty Cycle
Protocol Selection Transport layer, application protocol MQTT, CoAP, HTTP QoS, Payload size
Wireless Technology Physical layer, frequency bands BLE, LoRaWAN, Zigbee, Wi-Fi Mesh, Star Topology
Data Architecture Payload format, encoding JSON, CBOR, Protobuf Compression, Schema
Reliability Design Delivery guarantees, error handling QoS, At-least-once, Idempotency Retry, Backoff, Circuit Breaker
Security Design Encryption, authentication TLS, Authentication, Certificate OAuth, Token, ACL
Processing Location Edge vs cloud, resource allocation Edge Computing, Fog Computing, Cloud Gateway, Microservices
Data Storage Database type, retention policy TSDB, InfluxDB, TimescaleDB Time Series, Aggregation

4.7.1 Confusion Resolution Guide

When terms seem interchangeable, check “Common confusions” sections:

Confusing Pair Where to Look Key Distinction
QoS vs Bandwidth QoS, Bandwidth QoS = delivery guarantee, Bandwidth = data rate capacity
Edge vs Fog Edge Computing, Fog Computing Edge = on-device, Fog = local-network nodes
Authentication vs Authorization Authentication, Authorization AuthN = verify identity, AuthZ = check permissions
MQTT vs CoAP MQTT, CoAP MQTT = TCP pub/sub, CoAP = UDP request/response

4.7.2 Example Usage Workflow

  1. Start: “I need low-power communication for a 500-meter outdoor deployment”
  2. Protocol section: Compare LPWAN options → LoRaWAN (10 km range) vs NB-IoT (operator coverage)
  3. Cross-check: Review Latency (LoRa: 1-3s, NB-IoT: 1.6-10s), Packet size limits (LoRa: 242 bytes, NB-IoT: 1,600 bytes)
  4. Decision: LoRaWAN selected for 500m range + 10-year battery life requirement
  5. Document: Use glossary anchor links in design doc: “Selected LoRaWAN for LPWAN connectivity”
Common Mistake: Using Terminology Incorrectly in Design Documents

The Problem: Students often use technical terms imprecisely, leading to miscommunication with vendors, teammates, or evaluators.

Real Example from Student Projects:

A team wrote in their proposal: “We will use high QoS to ensure our system has good bandwidth for video streaming from security cameras.”

What’s wrong?

  1. QoS ≠ Bandwidth: QoS means message delivery guarantees (at-most-once, at-least-once, exactly-once), NOT data rate capacity. They meant Bandwidth (data rate).
  2. “High QoS”: MQTT QoS 2 (exactly-once) provides highest delivery guarantee but uses 3× messages compared to QoS 0, REDUCING effective bandwidth by 67% for the same physical connection.
  3. Protocol mismatch: Video streaming uses HTTP/RTSP, not MQTT, so “MQTT QoS” is irrelevant to the camera data flow.

How to avoid this:

  1. Look up EVERY technical term you use in your design document in this glossary
  2. Read “Common confusions” sections - these highlight exactly the mistakes students make
  3. Use glossary anchor links in your documentation to prove you understand the term precisely

Correct version with glossary references:

“Our security cameras require 2 Mbps bandwidth (data rate capacity) per stream. We will use HTTP over TLS for video transport (standard for IP cameras). For camera status telemetry (online/offline, disk space), we will use MQTT with QoS 1 (at-least-once delivery) to ensure we receive alerts even if the network is unreliable.”

Other common terminology errors to check:

Incorrect Usage What They Meant Glossary Terms to Review
“We need faster latency” Lower latency (delay) Latency
“The gateway will do fog computing” Edge computing (local processing) Edge, Fog
“MQTT will authenticate our devices” TLS/OAuth authenticate, MQTT transports messages MQTT, Authentication, TLS
“We store data in a JSON database” JSON is a format, not a database type JSON, TSDB, InfluxDB

Pro tip: Before your capstone presentation, have a teammate quiz you by pointing to any technical term in your slides and asking “Define this precisely using the glossary.” If you can’t explain the difference between similar terms (QoS vs bandwidth, edge vs fog, authentication vs authorization), you need more glossary review.

4.8 Concept Relationships

How This Glossary Connects to Other Concepts

Builds Upon:

  • Basic networking terminology (IP, TCP/UDP) from networking fundamentals
  • Programming concepts (variables, functions, APIs) from software development
  • Electronics basics (voltage, current, resistance) from hardware fundamentals

Enables:

  • Reading technical datasheets and protocol specifications
  • Understanding research papers and industry documentation
  • Communicating precisely with engineering teams and vendors
  • Debugging IoT systems by identifying component interactions

Related Frameworks:

  • OSI networking model (glossary terms map to specific layers)
  • IoT reference architectures (terms organized by system layer)
  • Protocol stacks (terms show how protocols build on each other)

4.9 See Also

Related Resources

Within This Module:

  • Mathematical Foundations - Formulas and equations referenced in technical definitions (dB, Shannon capacity, Kalman filters)
  • Visual Style Guide - IEEE color palette and diagram conventions used throughout glossary figures

Cross-Module References:

Interactive Learning:

Common Pitfalls

A glossary entry is a summary, not a complete explanation. Definitions that seem clear in isolation often hide important nuances covered in the full chapter. For example, the glossary defines ‘QoS’ in two sentences, but the MQTT chapter explains the protocol-level handshake differences between QoS 0, 1, and 2 that actually affect your firmware. Always follow cross-references for terms you will use in design decisions.

IoT shares terminology with other domains where words mean different things. ‘QoS’ means MQTT delivery guarantee levels in IoT but network traffic prioritization in networking. ‘Gateway’ means protocol bridge in IoT but default router in networking. Always verify which context applies. Each glossary entry notes where the IoT usage differs from general networking or computing usage.

Terminology precision matters in IoT engineering – miscommunication between hardware engineers, firmware developers, and cloud architects about what ‘topic’ means (MQTT topic? Database topic?) causes specification bugs. Keep the glossary bookmarked and reference it when writing architecture documents or technical specifications to ensure consistent terminology usage across your team.

4.11 What’s Next

If you want to… Read this
Look up IoT terms alphabetically from A through F Glossary A-F
Look up IoT terms alphabetically from G through P Glossary G-P
Look up IoT terms alphabetically from Q through Z Glossary Q-Z
Apply learned terminology in capstone project work Capstone Projects
Review mathematical notation used throughout the course Mathematical Foundations