6  IoT Glossary: G-P

Essential IoT Terms from Gateway to Publisher

capstone
glossary
g
p

6.1 In 60 Seconds

This glossary section covers IoT terminology from G through P, with emphasis on gateway architecture, web and messaging protocols, wireless network choices, hardware interfaces, payload formats, and platform design. The most frequently reused terms in this range include Gateway, MQTT, LPWAN, I2C, OAuth, Platform, Payload, and Publisher.

6.2 Start With The Handoff

Most G-P terms describe a handoff. GPIO and I2C hand a physical signal to firmware. A payload hands program state to a network message. MQTT hands device evidence to subscribers through a broker. OAuth hands a limited permission to an API. A platform hands a prototype to the people who operate, support, and improve it after the demo.

When a term marks a handoff, the useful question is “what could be lost or misunderstood here?” Units can disappear from a payload. A gateway can translate a field incorrectly. A topic can route to the wrong subscriber. A platform can show a polished dashboard while hiding stale data. The term is only trustworthy when the report shows the trace across that handoff.

Read this section with that trace in mind. For each term, look for the artifact on the sending side, the rule at the boundary, and the evidence on the receiving side.

6.3 Learning Objectives

After reviewing this section, you should be able to:

  1. Define key IoT terms from G to P with technical precision.
  2. Differentiate commonly confused concepts such as gateway vs. router, LoRa vs. LoRaWAN, MQTT broker vs. MQTT client, and I2C vs. SPI.
  3. Explain messaging patterns including publishers, subscribers, brokers, topics, and payloads.
  4. Select appropriate protocols, interfaces, and platform patterns for different IoT scenarios.

6.4 G-P Terms Name Handoffs

The G-P range sits in the middle of most IoT designs. Gateway, GPIO, HTTP, I2C, JSON, LoRaWAN, LPWAN, MQTT, OAuth, OPC UA, packet, payload, platform, Protobuf, and publisher are not isolated definitions. They name handoffs between hardware, local networks, application protocols, identity systems, schema owners, cloud services, and people who operate the system after the demo.

Read each term by asking which handoff it describes. GPIO and I2C describe the handoff from a sensor circuit into firmware. Packet, MTU, payload, JSON, and Protobuf describe the handoff from local program state into bytes that can cross a link. Gateway, middleware, microservices, platform, MQTT, HTTP, OPC UA, and OAuth describe the handoff from device or gateway evidence into services with routing, authorization, storage, dashboards, or support ownership.

The main beginner mistake is treating the term as a product label instead of a contract. LoRa is a radio modulation, while LoRaWAN adds join behavior, MAC-layer rules, regional parameters, network-server routing, device classes, and security. MQTT defines publish-subscribe message routing through a broker, but it does not define database retention, dashboard freshness, authorization scope, or command safety. OAuth defines delegated authorization, but it does not replace device identity, certificate handling, or topic ACLs.

Handoff Terms To Watch Evidence To Inspect Failure If Misnamed
Sensor to firmware GPIO, I2C, microcontroller, packet Pin mode, pull-up value, bus scan, sample timestamp A wiring or bus problem is blamed on the cloud path
Firmware to network Payload, JSON, Protobuf, MTU, latency, jitter Payload sample, schema version, packet size, retry trace Units, metadata, or oversized fields disappear in transit
Gateway to service Gateway, MQTT, HTTP, OAuth, middleware, OPC UA Topic, endpoint, scope, translation rule, buffer policy Routing, identity, and offline ownership become unclear
Service to operation Platform, publisher, subscriber, metadata, microservices Device registry, subscriber filter, database row, dashboard age A polished view hides stale state or missing ownership
Treat each G-P term as a handoff contract: name the boundary, the artifact, and the failure mode before using it in a design claim.

6.5 Prove The Handoff With Traces

In a project review, do not write “the gateway sends data to the platform” without evidence. Split that sentence into inspected artifacts. On the device side, show the sensor value, unit, timestamp, local address, firmware version, and interface evidence. For I2C, that may include the device address, bus speed, pull-up arrangement, and an error or clock-stretching observation. For GPIO, it may include pin mode, voltage level, debounce choice, and board-specific boot pin constraints.

On the message side, show the exact payload and the envelope around it. A payload sample should name fields, units, null behavior, schema version, and what metadata is outside the payload. JSON is readable and easy to debug, but it does not enforce a schema by itself. Protobuf is compact and strongly described by a .proto contract, but it requires schema version discipline and tooling. MTU, packet, latency, and jitter claims should point to a capture, log, or timing sample rather than a single average number.

On the gateway or service side, show routing and identity. For MQTT, record broker address, client id, topic, QoS, retained flag, session behavior, Last Will and Testament if used, subscriber filter, and ACL. For HTTP or HTTPS, record method, path, status code, authentication requirement, retry rule, and error payload. For OAuth, record scopes, token lifetime, refresh flow, and which API enforces the token. For OPC UA or Modbus integration, record the address/register/node mapping and the translation rule that preserves meaning.

On the platform side, name the owner. AWS IoT Core, Azure IoT Hub, ThingsBoard, Eclipse Ditto, InfluxDB, TimescaleDB, Grafana, Node-RED, and custom microservices can all appear in IoT designs, but each owns different states. A platform claim should say whether the service owns device registry, command queue, digital twin or shadow state, storage retention, alert routing, dashboard rendering, analytics jobs, OTA update state, audit logging, or support workflows. If ownership is not named, the glossary term is too broad to support a capstone claim.

A practical review format is four lines: term, handoff, evidence, and consequence. “MQTT” becomes “publisher firmware sends JSON payload to topic site/boiler/temperature with QoS 1; broker log and subscriber insert show duplicate-safe storage; consequence is that subscriber writes must be idempotent.” That sentence is longer than a definition, but it is reviewable.

6.6 Similar Words Carry Different Guarantees

Under the hood, several G-P terms sound interchangeable because they all move data. A packet is a network-layer or link-layer unit with headers and size limits. A payload is the application data carried inside an envelope. Metadata describes context around the payload, such as timestamp, gateway id, quality flag, spreading factor, RSSI, schema version, or tenant. A message may include payload plus headers, topic, properties, and broker state. Mixing those terms makes debugging harder because the missing field may not be in the place the report claims it is.

Gateway, router, middleware, and platform also overlap in everyday speech. A router forwards packets between networks. A gateway may translate protocols, buffer offline telemetry, map local identities to cloud identities, normalize timestamps, run rules, and manage credentials. Middleware may transform messages or coordinate services without owning the whole device lifecycle. A platform may own registry, policy, storage, analytics, command routing, and operational workflows. One physical box or cloud product can contain several roles, so the report should name the role being tested rather than only the product name.

Messaging terms hide guarantee boundaries. An MQTT publisher can send at QoS 0, QoS 1, or QoS 2, but the broker’s acknowledgement is not the same as a database write or operator action. A retained message may be useful for last-known state and dangerous when old state looks current. Wildcard topic filters make subscribers powerful and risky. HTTP status codes can confirm that an API accepted a request, but they do not prove that downstream analytics, alerting, or dashboard refresh completed unless those states are separately inspected.

Radio and timing terms hide physical constraints. LoRaWAN delivery depends on spreading factor, channel plan, regional duty-cycle constraints, gateway placement, join state, receive windows, network-server routing, and backhaul. NB-IoT and LTE-M use licensed cellular networks with different mobility, latency, power, and deployment assumptions from unlicensed LPWANs. Latency averages can hide jitter; jitter can break control loops or ordering assumptions even when average delay looks acceptable. MTU and packet-size limits can turn a neat payload design into fragmentation, truncation, or failed uplinks.

Identity terms hide one final boundary. OAuth authorizes access to APIs, often for user or application delegation. It does not by itself prove that a physical device is genuine, that a gateway certificate is still valid, or that a topic namespace is isolated. HTTPS protects transport, but certificate validation, key storage, refresh behavior, authorization scope, broker ACLs, and audit logs remain separate evidence. The technical term is complete only when the implementation guarantee and its limit are both named.

6.7 Deep Dive: G-P Terms Mark Integration Boundaries

Terms from G through P describe the middle of many IoT systems: the gateway that bridges local devices to wider networks, the hardware interface that collects a reading, the protocol that carries the message, the payload format that represents the value, and the platform that stores or displays the result.

Gateway handoff map showing a device stack, gateway translation and buffering responsibilities, cloud broker or API path, and boundary record fields.
Figure 6.1: G-P terms often describe a handoff where translation, buffering, identity, security, ownership, monitoring, or update responsibility changes.

Use each definition to identify the boundary being crossed. A GPIO pin boundary is not the same as an I2C bus boundary. LoRa modulation is not the same layer as LoRaWAN join, routing, and security. An MQTT publisher, broker, topic, payload, and subscriber are separate responsibilities even when a small demo hides them in one script.

The figure gives the main reading pattern for this glossary range. A device stack may own a local link, an application message, and retry evidence. A gateway may translate Modbus, BLE, Zigbee, I2C-derived sensor values, or serial payloads into MQTT, HTTPS, OPC UA, or another upstream contract. The cloud path may be a broker, API, platform registry, subscriber rule, dashboard, database, or audit log. Each handoff changes what “message,” “payload,” “publisher,” “platform,” and “gateway” mean in the evidence.

That is why G-P terms should be read as integration terms, not just vocabulary. Gateway is broader than router when it translates, buffers, validates, maps identity, or survives an outage. LoRa is the radio modulation; LoRaWAN adds MAC behavior, join procedure, network server routing, device classes, regional parameters, and security. MQTT is not a database or dashboard; it is a broker-mediated publish-subscribe protocol whose topic and payload choices still need storage, schema, and access-control decisions.

Boundary Terms That Clarify It
Hardware GPIO, I2C, microcontroller, packet, MTU, and payload terms explain what is sampled, encoded, split, or rejected.
Network Gateway, LoRa, LoRaWAN, LPWAN, LTE-M, NB-IoT, jitter, and latency terms explain reach, timing, airtime, and backhaul behavior.
Application HTTP, HTTPS, MQTT, OAuth, platform, middleware, microservices, metadata, JSON, Protobuf, and publisher terms explain ownership above the device.

6.7.1 Tie the Term to a Configuration or Trace

Before using a glossary term in a capstone explanation, point to the artifact that proves it. Gateway should connect to a protocol-translation rule, buffering policy, route table, or local queue. MQTT should connect to a broker address, client id, topic name, QoS setting, retained-message policy, Last Will and Testament, or session-expiry setting. OAuth should connect to scopes, token lifetime, refresh behavior, and the API that checks the token.

For hardware and payload terms, check the implementation detail that constrains the claim. I2C depends on bus pull-ups, address conflicts, bus capacitance, and clock speed. MTU depends on the link and headers. JSON, CBOR, and Protobuf change payload size, schema enforcement, debugging, and binary-data handling.

For a gateway claim, collect both sides of the handoff. On the device side, record the source protocol, address, sampling interval, retry counter, local timestamp, and raw or normalized payload. On the gateway side, record translation rules, buffer size, offline retention, credential mapping, topic or endpoint construction, and the rule that decides whether bad data is dropped, quarantined, or forwarded with a quality flag. On the cloud side, record broker ACLs, API route, platform device identity, schema version, database target, subscriber filter, and dashboard freshness rule.

For a messaging claim, write the exact topic, payload sample, QoS level, retained flag, and subscriber behavior. A publisher sends to a topic, but it does not know which subscribers will match the filter. A broker routes messages, but it is not automatically the long-term system of record. A platform may manage device registry, command routing, OTA update state, and analytics, but the glossary term “platform” should be tied to the actual service boundary in the project. For OAuth, record the authorization scope and token lifetime, then separately record how the device or gateway proves its own identity.

  1. Choose the artifact. Example: an ESP32 pinout, I2C bus scan, MQTT packet capture, LoRaWAN uplink metadata row, OAuth consent screen, or platform device registry.
  2. Name the boundary. Example: gateway translation, payload serialization, publisher responsibility, LPWAN airtime, or HTTPS endpoint authentication.
  3. State the consequence. Example: duplicate address, fragmented packet, stale dashboard, rejected token, overloaded broker, missed receive window, or wrong platform owner.

6.7.2 Vocabulary Errors Become Architecture Errors

Mislabeling one G-P term usually moves responsibility to the wrong layer. Calling a gateway a router hides protocol translation, buffering, certificate handling, and offline behavior. Treating a payload as the whole message hides headers, metadata, timestamps, units, quality flags, and schema version. Calling every cloud dashboard a platform hides device provisioning, command routing, identity, storage, analytics, and operations ownership.

Protocol terms also carry hidden contracts. HTTP request-response does not behave like MQTT publish-subscribe. LoRa airtime and LoRaWAN duty-cycle limits do not behave like Wi-Fi throughput. OAuth authorization does not prove device identity by itself. A useful project explanation names the term, the layer, the owner, and the failure mode.

Underneath the wording, each G-P term is a contract with a failure mode. GPIO and I2C failures look like wrong voltage, wrong pin mode, duplicate address, bus capacitance, clock stretching, or missing pull-ups. Packet, MTU, and payload failures look like fragmentation, truncation, oversized JSON, lost metadata, or units that disappear between the firmware and the dashboard. MQTT failures look like duplicate QoS 1 deliveries, retained messages that make old state look current, wildcard subscriptions that receive more than intended, or broker ACLs that let one device publish into another device’s namespace.

Gateway and platform terms are even broader because they combine technical and operational ownership. A gateway may translate, buffer, authenticate, normalize timestamps, run local rules, and upload later. A platform may own provisioning, device twins, shadow state, command queues, storage retention, analytics jobs, alert routing, audit logs, and support workflows. If the glossary term does not name which component owns those states, a capstone design can pass a demo while still failing during a backhaul outage, credential rotation, schema migration, or subscriber-rule change.

For capstone work, use G-P terms to identify who owns the next state transition: the microcontroller firmware, gateway process, broker, network server, middleware service, platform registry, database, dashboard, or support operator.

6.8 How It Works: Turn G-P Terms Into Design Decisions

  1. Start with the physical or protocol artifact: a GPIO pin assignment, I2C address, LoRaWAN join log, MQTT topic, HTTPS endpoint, OAuth scope, payload schema, or platform device registry.
  2. Use the glossary term to name the boundary and its neighboring confusion: gateway vs. router, LoRa vs. LoRaWAN, MQTT broker vs. MQTT client, payload vs. metadata, or platform vs. protocol.
  3. Write the design consequence in one sentence: what fails, retries, queues, fragments, rejects, stores, or alerts when the boundary is wrong?

Beginner Example: An ESP32 room sensor reads an I2C temperature sensor, formats a JSON payload, and publishes it to building/room-12/temperature over MQTT. The key terms are I2C, JSON, payload, publisher, MQTT, and broker.

Intermediate Example: A LoRaWAN soil sensor sends a small uplink through a gateway to a network server. The key terms are LoRa, LoRaWAN, LPWAN, gateway, payload, metadata, latency, and platform; the design consequence is that airtime, spreading factor, gateway placement, and backhaul affect delivery timing.

Advanced Example: An industrial gateway reads Modbus registers, maps them into an OPC-UA information model, serializes selected telemetry with Protobuf, publishes MQTT messages to middleware, and exposes an HTTPS API protected by OAuth scopes. The key question is which component owns translation, authorization, retry, schema evolution, and operator visibility.

6.9 Key Concepts

  • Gateway: An edge device that aggregates data from local devices and forwards it to cloud or enterprise systems, often handling protocol translation, buffering, and local processing.
  • MQTT (Message Queuing Telemetry Transport): A lightweight publish-subscribe protocol using a broker to route telemetry between devices and applications.
  • LPWAN (Low Power Wide Area Network): A category of wireless networks that trades bandwidth for long range and low power consumption.
  • LoRaWAN: A network protocol built on LoRa modulation, commonly used for long-range sensor deployments.
  • NB-IoT (Narrowband IoT): A licensed cellular LPWAN technology for low-power devices that send small amounts of data.
  • Platform: A complete software environment for device management, data ingestion, storage, analytics, and dashboards.
  • Publisher: A client that sends messages to topics in a publish-subscribe system without knowing which subscribers will receive them.

6.10 For Beginners: IoT Glossary G-P

This section is a quick reference for important IoT words from G to P. Use it when a chapter, project brief, or diagram mentions a term such as “gateway,” “MQTT,” “LPWAN,” or “payload” and you need the definition, plain-language explanation, common mistakes, and related terms in one place.

Navigation

This is part 2 of the IoT Glossary, covering terms G-P. See also:

Reference Use Metric

Reference usability can be estimated by lookup coverage:

\[ U = \frac{R}{T} \]

where \(R\) is resolved lookups and \(T\) is 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.

6.11 G

6.11.1 Gateway

Definition: A device that connects networks using different protocols, translating between them and enabling communication between IoT devices and external networks or cloud services.

In simple terms: A translator between different languages - connects your Zigbee sensors to your Wi-Fi network by translating between the two “languages” they speak.

Common confusions:

  • Gateway vs. router - gateways translate protocols, routers only forward packets
  • IoT gateways often combine routing, protocol translation, and edge processing

Related terms: Edge Computing, Broker, Middleware

Synonyms: IoT gateway, protocol converter, edge gateway

6.11.2 GPIO (General Purpose Input/Output)

Definition: Programmable digital pins on a microcontroller that can be configured as either inputs (reading signals) or outputs (sending signals) for interfacing with external components.

In simple terms: The connection points on a microcontroller - like USB ports on a computer, but simpler and more flexible, letting you connect sensors, LEDs, buttons, and other hardware.

Common confusions:

  • GPIO is digital only - use ADC for analog input
  • GPIO current, voltage, pull-up/pull-down mode, and bootstrapping constraints should be checked against the board datasheet to avoid damaged pins or failed boot

Related terms: ADC, DAC, Microcontroller, I2C

Synonyms: digital pins, I/O pins

6.12 H

6.12.1 HTTP (Hypertext Transfer Protocol)

Definition: The foundation protocol of the web, using request-response communication over TCP to transfer hypertext documents, APIs, and other resources between clients and servers.

In simple terms: The language of the web - how your browser asks for web pages and receives them, also used by many IoT devices to send data to cloud services.

Common confusions:

  • HTTP vs. HTTPS - HTTPS adds TLS encryption for security
  • HTTP/1.1 vs. HTTP/2 vs. HTTP/3 have significant performance differences

Related terms: HTTPS, REST, API, CoAP

Synonyms: web protocol

6.12.2 HTTPS (HTTP Secure)

Definition: HTTP protocol secured with TLS encryption, ensuring confidentiality, integrity, and authentication for web communications through cryptographic protection.

In simple terms: Secure HTTP - the same web protocol but wrapped in encryption so nobody can eavesdrop on or tamper with your data in transit.

Common confusions:

  • HTTPS requires certificates and adds computational overhead
  • Not all IoT devices support HTTPS due to resource constraints

Related terms: HTTP, TLS, Certificate, Encryption

Synonyms: HTTP over TLS, secure HTTP

6.13 I

6.13.1 I2C (Inter-Integrated Circuit)

Definition: A synchronous serial communication bus using two wires (data and clock) to connect multiple peripheral devices to a microcontroller. Seven-bit addressing provides a large address space, but real bus capacity is constrained by reserved addresses, duplicate device addresses, capacitance, pull-up sizing, and clock speed.

In simple terms: A shared communication line - multiple sensors and devices can talk to one microcontroller using just two wires, taking turns like people on a conference call.

Practical example: Standard I2C speeds are 100 kHz (standard mode), 400 kHz (fast mode), and 1 MHz (fast mode plus). At 400 kHz, one data byte plus its ACK bit uses 9 clock bits, so the transfer takes about 22.5 microseconds before address, start, stop, and clock-stretching overhead.

Common confusions:

  • I2C vs. SPI - I2C needs fewer wires but is slower, SPI is faster but needs more wires
  • I2C addresses need to be unique on each bus; address pins, bus multiplexers, or a second controller bus may be needed when identical sensors collide

Related terms: SPI, UART, GPIO, Microcontroller

Synonyms: IIC, TWI (Two-Wire Interface)

6.13.2 Idempotency

Definition: A property of operations where performing them multiple times produces the same result as performing them once, enabling safe retries without unintended side effects.

In simple terms: “Press as many times as you want” - like an elevator button that does the same thing whether you press it once or ten times.

Common confusions:

  • GET is idempotent, POST typically is not
  • Idempotency keys help make non-idempotent operations safely retriable

Related terms: At-least-once, Retry, Exactly-once

Synonyms: idempotent operation

6.13.3 InfluxDB

Definition: An open-source time series database optimized for fast, high-availability storage and retrieval of time-stamped data, commonly used for IoT metrics, monitoring, and analytics.

In simple terms: A database built for sensor data - specifically designed to handle the millions of time-stamped readings that IoT devices generate, with efficient storage and fast queries.

Common confusions:

  • InfluxDB vs. relational databases - InfluxDB optimizes for time-based queries, not relationships
  • InfluxQL vs. Flux query languages have different capabilities

Related terms: TSDB, TimescaleDB, Time Series, Telemetry

Synonyms: none common

6.14 J

6.14.1 Jitter

Definition: The variation in delay between packets arriving at a destination, causing inconsistency in data arrival times that can affect real-time applications and time-sensitive systems.

In simple terms: Inconsistent timing - like a musician who can’t keep a steady beat, packets arrive at irregular intervals even if the average delay is acceptable.

Common confusions:

  • Jitter vs. latency - latency is average delay, jitter is variation in delay
  • High jitter is problematic even with low average latency

Related terms: Latency, Bandwidth, QoS

Synonyms: packet delay variation (PDV)

6.14.2 JSON (JavaScript Object Notation)

Definition: A lightweight, human-readable data interchange format using key-value pairs and arrays, widely used for API communication and configuration in IoT systems.

In simple terms: A universal data format - a simple way to structure data that both humans can read and machines can process, like a common language everyone understands.

Common confusions:

  • JSON is text-based (larger than binary formats like CBOR or Protobuf)
  • JSON lacks native support for binary data (commonly handled with Base64 or an external binary object)

Related terms: CBOR, Protobuf, Payload, Serialization

Synonyms: none common

6.15 L

6.15.1 Latency

Definition: The time delay between initiating a request and receiving a response, measured in milliseconds, representing how long data takes to travel through a system or network.

In simple terms: Response time - how long you wait between pressing a button and seeing the result, like the delay between flipping a light switch and the light turning on.

Practical example: Total latency combines multiple components: sensor sampling (1-10 ms), processing (1-5 ms), network transmission (10-100 ms for Wi-Fi, 20-200 ms for cellular), and cloud processing (50-200 ms). For a cloud-connected temperature sensor, a typical budget might be 5 ms sensing + 2 ms processing + 50 ms network + 100 ms cloud = 157 ms.

Common confusions:

  • Low latency vs. high bandwidth - you can have fast response with limited throughput or vice versa
  • Network latency is just one component of end-to-end latency

Related terms: Bandwidth, Jitter, Edge Computing

Synonyms: delay, response time, lag

6.15.2 LoRa (Long Range)

Definition: A proprietary spread spectrum modulation technique derived from chirp spread spectrum (CSS) technology, enabling long-range, low-power wireless communication for IoT devices.

In simple terms: A radio technology for distance - sends data over miles using very little power, perfect for sensors in remote locations that need to communicate without Wi-Fi or cellular coverage.

Common confusions:

  • LoRa vs. LoRaWAN - LoRa is the physical layer modulation, LoRaWAN is the network protocol on top
  • LoRa is proprietary to Semtech, not an open standard

Related terms: LoRaWAN, NB-IoT, LTE-M

Synonyms: LoRa modulation, CSS

6.15.3 LoRaWAN

Definition: An open network protocol specification built on LoRa physical layer, defining the network architecture, security, and communication protocols for wide-area IoT deployments.

In simple terms: The complete network system using LoRa - includes not just the radio technology but the whole setup of gateways, servers, and security that creates a working IoT network.

Common confusions:

  • LoRaWAN vs. LoRa - LoRaWAN is the complete protocol stack, LoRa is just the modulation
  • Three device classes (A, B, C) offer different latency/power tradeoffs

Related terms: LoRa, NB-IoT, LPWAN, Gateway

Synonyms: Long Range Wide Area Network

6.15.4 LPWAN (Low Power Wide Area Network)

Definition: A type of wireless network designed to allow long-range communication at low bit rates among connected devices, optimized for battery-powered IoT applications.

In simple terms: Networks for simple, long-range devices - designed for sensors that send small amounts of data over long distances while keeping power use low enough for long battery life when payloads and duty cycle are small.

Common confusions:

  • LPWAN is a category, not a specific technology (includes LoRaWAN, Sigfox, NB-IoT)
  • LPWAN trades bandwidth for range and power efficiency

Related terms: LoRaWAN, NB-IoT, LTE-M, Sigfox

Synonyms: low power network, wide area IoT

6.15.5 LTE-M (LTE for Machines)

Definition: A cellular IoT technology based on LTE networks, providing moderate bandwidth, mobility support, and voice capability for IoT devices requiring higher data rates than NB-IoT.

In simple terms: Cellular for IoT with more features - uses existing cell towers to connect IoT devices, with enough bandwidth for things like wearables that need more data than simple sensors.

Common confusions:

  • LTE-M vs. NB-IoT - LTE-M has higher bandwidth and mobility support, NB-IoT is simpler and lower power
  • LTE-M supports VoLTE for voice applications

Related terms: NB-IoT, LPWAN, Cellular IoT

Synonyms: Cat-M1, eMTC

6.16 M

6.16.1 Matter

Definition: A unified, IP-based connectivity standard for smart home devices, developed by the Connectivity Standards Alliance to improve interoperability across ecosystems such as Apple Home, Google Home, Amazon Alexa, and Samsung SmartThings.

In simple terms: A shared smart home language - helps devices from different brands use common data models, commissioning flows, and local IP networking while still leaving product-specific features to each ecosystem and device type.

Common confusions:

  • Matter doesn’t replace Wi-Fi or Thread - it runs over them as transport
  • Matter certification checks conformance and baseline interoperability, but it does not mean every vendor-specific feature works the same way across platforms

Related terms: Thread, Zigbee, Wi-Fi

Synonyms: Project CHIP (original name)

6.16.2 Mesh

Definition: A network topology where devices connect directly to multiple other devices, creating redundant paths that improve reliability and extend coverage through multi-hop routing.

In simple terms: A web of connections - every device can talk to multiple neighbors and messages hop from device to device, so if one path fails, data finds another route.

Common confusions:

  • Mesh vs. star topology - mesh has multiple paths, star has single central connection
  • Mesh increases reliability but adds complexity and latency

Related terms: Star Topology, Routing, Zigbee, Thread

Synonyms: mesh network, mesh topology

6.16.3 Metadata

Definition: Data that provides information about other data, such as timestamps, device identifiers, data types, units, and quality indicators that contextualize the primary payload.

In simple terms: Information about information - the label on a package that tells you what’s inside, when it was sent, and where it came from, without being the actual contents.

Common confusions:

  • Metadata vs. payload - metadata describes, payload contains actual values
  • Metadata is essential for data management but adds overhead

Related terms: Payload, Timestamp, Schema

Synonyms: meta-information, data context

6.16.4 Microcontroller

Definition: A compact integrated circuit containing a processor, memory, and programmable I/O peripherals, designed for embedded applications and IoT devices with specific control functions.

In simple terms: A tiny computer on a chip - contains everything needed to run simple programs and control hardware, perfect for IoT devices that need to be small, cheap, and power-efficient.

Common confusions:

  • Microcontroller vs. microprocessor - microcontrollers include memory and peripherals on-chip
  • Popular IoT microcontrollers include ESP32, STM32, Arduino-based chips

Related terms: SoC, GPIO, ADC

Synonyms: MCU, embedded controller

6.16.5 Microservices

Definition: An architectural style that structures an application as a collection of loosely coupled, independently deployable services, each implementing specific business capabilities.

In simple terms: Building with LEGO blocks - instead of one big application, break it into many small, independent services that can be developed, deployed, and scaled separately.

Common confusions:

  • Microservices vs. monolith - microservices add complexity but improve scalability and maintainability
  • Microservices require robust communication and orchestration

Related terms: API, Serverless, Platform

Synonyms: microservice architecture

6.16.6 Middleware

Definition: Software that sits between the operating system and applications, providing common services like messaging, authentication, API management, and data transformation.

In simple terms: The glue between systems - handles the complicated work of connecting different parts of a system so application developers can focus on business logic.

Common confusions:

  • Middleware vs. API - middleware provides services, APIs provide access to them
  • IoT middleware often includes message brokers and protocol adapters

Related terms: Broker, API, Gateway

Synonyms: integration layer, message-oriented middleware

6.16.7 Modbus

Definition: A serial communication protocol originally developed for programmable logic controllers (PLCs), now widely used in industrial IoT for connecting electronic devices.

In simple terms: The industrial standard language - an old but reliable way for factory equipment to communicate, like the standard railroad track gauge that ensures all trains can run on the same rails.

Common confusions:

  • Modbus RTU (serial) vs. Modbus TCP (Ethernet) have different physical layers
  • Modbus is simple but lacks built-in security

Related terms: OPC-UA, Industrial IoT, Gateway

Synonyms: Modbus Protocol

6.16.8 MQTT (Message Queuing Telemetry Transport)

Definition: A lightweight publish-subscribe messaging protocol designed for constrained devices and low-bandwidth, high-latency networks, using a broker to route messages between clients.

In simple terms: The postal service for IoT - devices send messages to a central post office (broker) addressed to topics, and anyone subscribed to those topics receives the messages.

Common confusions:

  • MQTT doesn’t actually use message queuing despite its name
  • MQTT 3.1.1 vs. MQTT 5 have significant feature differences

Related terms: Broker, Topic, Publisher, Subscriber, QoS

Synonyms: none common

6.16.9 MTU (Maximum Transmission Unit)

Definition: The largest size of a protocol data unit that can be transmitted in a single network transaction, determining when packets may need fragmentation, segmentation, or rejection.

In simple terms: The maximum package size - like postal limits on how big a box can be, networks have maximum sizes for data chunks before they are split, resized, or rejected.

Practical example: Common size limits include Ethernet MTU near 1500 bytes, IEEE 802.15.4 frames at 127 bytes before 6LoWPAN/IP/UDP overhead, and LoRaWAN maximum application payloads that vary by region, data rate, and MAC commands. Overhead reduces usable payload: a small radio frame can leave much less room after link, IPv6, UDP, security, and adaptation headers.

Common confusions:

  • MTU varies by network type (Ethernet 1500 bytes, 6LoWPAN much smaller)
  • MTU mismatch can cause connectivity issues

Related terms: Packet, Frame, 6LoWPAN

Synonyms: maximum packet size

6.17 N

6.17.1 NB-IoT (Narrowband IoT)

Definition: A cellular IoT technology using a narrow 200kHz bandwidth, providing excellent coverage, low power consumption, and lower cost for simple IoT devices requiring infrequent data transmission.

In simple terms: Cellular for simple sensors - uses licensed cellular networks to connect basic IoT devices that send small amounts of data occasionally, with long battery life when coverage, message size, and reporting interval are well matched.

Common confusions:

  • NB-IoT vs. LTE-M - NB-IoT is simpler and lower power but has less bandwidth and no mobility
  • NB-IoT can work in-band, guard-band, or standalone deployments

Related terms: LTE-M, LPWAN, LoRaWAN

Synonyms: LTE Cat-NB1, Cat-NB2

6.18 O

6.18.1 OAuth

Definition: An open authorization framework that enables secure delegated access, allowing users to grant third-party applications limited access to their resources without sharing credentials.

In simple terms: “Sign in with Google” for machines - lets you give an app permission to access your data without giving it your password, like giving a valet your car key but not your house key.

Common confusions:

  • OAuth 2.0 vs. OAuth 1.0 are significantly different (2.0 is not backward compatible)
  • OAuth is for authorization, not authentication (OpenID Connect adds authentication)

Related terms: Authentication, Authorization, Token

Synonyms: OAuth 2.0

6.18.2 OPC-UA (OPC Unified Architecture)

Definition: A platform-independent, service-oriented architecture providing secure, reliable data exchange for industrial automation, supporting complex data models and standardized communication.

In simple terms: The modern industrial communication standard - enables factory machines from different vendors to share data securely, with rich information models and enterprise-grade security.

Common confusions:

  • OPC-UA vs. OPC Classic - UA is platform-independent, Classic was Windows-only
  • OPC-UA includes security and information modeling that Modbus lacks

Related terms: Modbus, Industrial IoT, Middleware

Synonyms: UA, IEC 62541

6.19 P

6.19.1 Packet

Definition: A unit of data at the network layer (Layer 3) containing header information (addresses, protocol) and payload, routed independently across networks toward its destination.

In simple terms: A data envelope with an address - contains the actual message plus delivery information, like a letter with destination address that postal workers use for routing.

Common confusions:

  • Packet vs. frame - packets are Layer 3 (IP), frames are Layer 2 (Ethernet)
  • Packets may be fragmented if larger than MTU

Related terms: Frame, Payload, Routing

Synonyms: datagram, IP packet

6.19.2 Payload

Definition: The actual data being transported within a message or packet, excluding headers, metadata, and protocol overhead - the meaningful content that applications process.

In simple terms: The actual cargo - in a delivery truck (packet), the payload is the goods being delivered, not the truck itself or the shipping labels.

Common confusions:

  • Payload vs. message - payload is the content portion, message includes headers/metadata
  • Payload format varies (JSON, CBOR, Protobuf, binary)

Related terms: JSON, CBOR, Packet, Metadata

Synonyms: data payload, message body, content

6.19.3 Platform

Definition: A comprehensive software environment providing infrastructure services for IoT applications, including device management, data ingestion, storage, analytics, and visualization.

In simple terms: A complete IoT toolkit - provides all the services you need to build IoT applications without starting from scratch, like a fully equipped kitchen versus building your own stove.

Common confusions:

  • Platform vs. protocol - platforms are complete solutions, protocols are communication standards
  • Examples: AWS IoT Core, Azure IoT Hub, ThingsBoard, Eclipse Ditto, and historical Google Cloud IoT Core deployments that now require migration planning

Related terms: Cloud, Middleware, Digital Twin

Synonyms: IoT platform, cloud platform

6.19.4 Protobuf (Protocol Buffers)

Definition: A language-neutral, platform-neutral binary serialization format developed by Google, using predefined schemas to create compact, efficient data structures for communication.

In simple terms: Efficient data packing with blueprints - you define the structure once (schema), then data is packed tightly according to that blueprint, saving space and processing time.

Common confusions:

  • Protobuf requires schema definition upfront (unlike JSON which is self-describing)
  • Protobuf is more efficient than JSON but less human-readable

Related terms: JSON, CBOR, Schema, Serialization

Synonyms: Protocol Buffers, pb

6.19.5 Publisher

Definition: A client in publish-subscribe messaging that sends messages to topics, without knowledge of or direct connection to the subscribers who will receive those messages.

In simple terms: A broadcaster - sends messages into the system addressed to topics, not caring who’s listening, like a radio station that transmits without knowing who has tuned in.

Common confusions:

  • Publisher vs. producer - essentially the same concept
  • Publishers are decoupled from subscribers (neither knows about the other)

Related terms: Subscriber, Topic, Broker, MQTT

Synonyms: producer, sender, message source

Scenario: Capstone project needs to choose between I2C and SPI for connecting 5 sensors to ESP32. Both protocols work, but which is better?

Glossary lookup (I2C): > “A synchronous serial communication bus using two wires (data and clock)…”

Cross-reference check: “I2C vs. SPI - I2C needs fewer wires but is slower”

Compare: SPI: > “Synchronous serial interface using separate lines for data in/out and clock… faster but requires more wires”

Decision table (derived from glossary):

Factor I2C SPI Winner
Wires needed 2 (shared bus) 4 per device (20 wires for 5 sensors!) I2C
Speed 400 kHz standard 10+ MHz SPI (but not needed)
Complexity Simple addressing Manual chip select I2C
Use case fit Multiple low-speed sensors Single high-speed device I2C

Decision: I2C for this project (5 sensors sharing 2 wires vs. 20 wires for SPI).

Key insight: The glossary’s comparison note on I2C vs. SPI pointed to the key trade-off. For multiple low-speed sensors, I2C’s shared bus advantage outweighs SPI’s speed.

Comparison Needed Glossary Strategy Result
Messaging protocols Look up MQTT, then compare with CoAP MQTT is brokered publish-subscribe; CoAP is REST-like over UDP
Cellular IoT Look up NB-IoT, then compare with LTE-M NB-IoT favors simple low-power telemetry; LTE-M supports more mobility and bandwidth
Hardware interfaces Look up GPIO, then explore ADC, DAC, I2C, and SPI Understand full interface options
Network architectures Look up Gateway, then follow Edge, Fog, and Cloud See where processing and protocol translation happen

Effective protocol comparison workflow:

  1. List candidate protocols (e.g., MQTT, CoAP, HTTP)
  2. Look up each in glossary
  3. Read “Common confusions” for comparisons
  4. Follow “Related terms” for alternatives
  5. Create comparison table from glossary info
  6. Jump to detailed chapters for final decision

Key insight: The glossary provides high-level comparisons that quickly narrow choices. Detailed chapters provide implementation guidance for the selected option.

Common Mistake: Ignoring “Synonyms” When Searching for Solutions

The mistake: Searching for only one phrase can miss useful documentation. For example, “IoT message broker,” “MQTT broker,” “message-oriented middleware,” and “publish-subscribe middleware” may lead to different resources.

Why It Happens: Different communities use different terminology. Academic papers say “publish/subscribe middleware,” industry blogs say “message broker,” hobbyist forums say “MQTT server.”

Real examples:

Your Search Term Gets Poor Results Glossary Synonym Gets Better Results
“IoT platform” Vague marketing “Cloud platform”, “Middleware” Specific architectures
“Serial protocol” Too general “UART”, “I2C”, “SPI” Hardware-specific docs
“Message confirmation” Unclear “Acknowledgment (ACK)” Protocol documentation
“Request authentication” Broad “OAuth”, “Token” Security implementations

The fix: Check the “Synonyms” section of glossary terms and use those terms in searches: 1. Look up concept in glossary 2. Note all synonyms listed 3. Search using each synonym 4. Different terms unlock different documentation

Example: Searching for “microcontroller programming”:

  • Glossary: MCU synonyms = “microcontroller”, “embedded controller”, “MCU”
  • Expanded search: “MCU programming”, “embedded programming”, “firmware development”
  • Better results from diverse sources

Key insight: The glossary’s synonym section helps connect academic, industrial, and maker documentation that may use different vocabulary for the same concept.

Protocol families connect: HTTP becomes HTTPS when TLS is added, LoRa becomes LoRaWAN when the network layer is added, and MQTT relies on TCP while CoAP uses UDP.

Hardware interfaces trade off features:

  • GPIO: Simple digital I/O, many pins available
  • I2C: Shared bus (2 wires), multiple devices, slower speed
  • SPI: Dedicated per device (4+ wires), faster, parallel operation

Messaging patterns emerge: MQTT messages typically move from publisher to broker to subscriber, with topics for routing and filters for selection. Payload format such as JSON, Protobuf, or CBOR affects efficiency.

Network architecture layers: Gateway bridges protocols, Middleware provides services, Platform offers complete solution, Microservices enable modularity.

Glossary navigation:

Referenced chapters (examples from terms covered): - MQTT Protocol - Publisher, subscriber, broker, topics - LoRaWAN - LoRa and LoRaWAN details - Hardware Interfaces - GPIO, I2C, SPI

External resources:

6.20 Mid-Section Knowledge Check

Knowledge Check: Hardware Interfaces
Match the IoT Term to Its Definition

Order the MQTT Publish-Subscribe Flow

Common Pitfalls

MQTT ‘broker’ and ‘server’ are synonymous – both refer to the message routing component. The term ‘server’ is sometimes used in older documentation. What is NOT the broker is the MQTT client (both publishers and subscribers are clients). Calling the broker a ‘server’ is fine but confusing it with an HTTP API server leads to incorrect architecture diagrams.

LoRa (lowercase) is the physical layer modulation technique – a chirp spread spectrum radio. LoRaWAN is the network protocol specification built on top of LoRa, defining the MAC layer, network server architecture, and security. You can use LoRa modulation without LoRaWAN, for example in proprietary point-to-point links. Public or community LoRaWAN networks add the LoRaWAN MAC layer, network-server routing, and security model.

IoT gateways often do far more than protocol translation. Production gateways may buffer sensor data during cloud connectivity loss, run local edge analytics to reduce bandwidth, validate incoming sensor data before forwarding, and manage local device security certificates. Treating gateways as only protocol bridges can create systems that fail during internet outages and have no local intelligence.

Label the Diagram

Code Challenge

6.21 Summary

This section covered 31 essential IoT terms from G through P:

Category Terms Examples
Architecture 5 Gateway, Mesh, Microservices, Middleware, Platform
Hardware and packet interfaces 5 GPIO, I2C, Microcontroller, MTU, Packet
Protocols and standards 8 HTTP, HTTPS, LoRa, LoRaWAN, Matter, Modbus, MQTT, OPC-UA
Networks and performance 5 Jitter, Latency, LPWAN, LTE-M, NB-IoT
Data and messaging 7 Idempotency, InfluxDB, JSON, Metadata, Payload, Protobuf, Publisher
Security and access 1 OAuth

6.22 What’s Next

If you want to… Read this
Look up IoT terms from A through F Glossary A-F
Look up IoT terms from Q through Z Glossary Q-Z
Review the glossary from the first range Glossary A-F
Apply MQTT and gateway concepts in capstone projects Capstone Projects
Deep dive into MQTT protocol details MQTT Fundamentals

6.24 Key Takeaway

Glossary terms from gateways through protocols describe the middle of many IoT systems. Use them to make architecture discussions precise: what is routed, processed, persisted, protected, or exposed to users.