8 IoT Glossary: I-P
8.1 Start With the Situation
A system description now moves from gateways and HTTP into interfaces, IoT architecture, long-range radio, messaging, payloads, and platforms. This second route provides the I-P vocabulary for those decisions.
8.2 Overview
This route covers I-P terms, connecting interfaces and networking to messaging, payload, platform, and protocol language.
This is part 2 of 2. Review IoT Glossary: G-H when you need the first route.
8.3 Learning Objectives
By the end of this chapter, you will be able to:
- define I-P IoT terms precisely
- distinguish interface, messaging, payload, and platform responsibilities
- apply protocol and network vocabulary to IoT scenarios
8.4 Chapter Roadmap
Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.
8.5 I
8.5.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)
8.5.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
8.5.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
8.6 J
8.6.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)
8.6.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
8.7 L
8.7.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
8.7.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
8.7.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
8.7.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
8.7.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
8.8 M
8.8.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)
8.8.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
8.8.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
8.8.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
Synonyms: MCU, embedded controller
8.8.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
8.8.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
8.8.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
8.8.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
8.8.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
8.9 N
8.9.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
8.10 O
8.10.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
8.10.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
8.11 P
8.11.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
8.11.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
8.11.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
8.11.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
8.11.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:
Step 1 — List candidate protocols (e.g., MQTT, CoAP, HTTP) Step 2 — Look up each in glossary Step 3 — Read “Common confusions” for comparisons Step 4 — Follow “Related terms” for alternatives Step 5 — Create comparison table from glossary info Step 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.
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:
- Look up concept in glossary
- Note all synonyms listed
- Search using each synonym
- 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:
Glossary A-F - ACL through Frame Glossary Q-Z - QoS through 6LoWPAN
Referenced chapters (examples from terms covered): MQTT Protocol - Publisher, subscriber, broker, topics LoRaWAN - LoRa and LoRaWAN details Hardware Interfaces - GPIO, I2C, SPI
External resources:
IETF RFCs - HTTP, HTTPS, protocol specs LoRa Alliance - LoRaWAN specification I2C Specification - Official I2C standard
8.12 Mid-Section Knowledge Check
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.
8.13 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 |
8.14 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 |
8.16 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.