5 IoT Glossary: A
5.1 Overview
This first reference route keeps the substantial A-term family together, from access control and ADCs through architecture and authentication.
This is part 1 of 2. Continue with IoT Glossary: B-F for the second focused route.
5.2 In 60 Seconds
Use Each Term to Clarify a Boundary
Picture a review note filled with five unexplained initials and a device role. Every word may be correct, yet the sentence does not say which boundary each one controls or what proof the team should inspect.
A protocol is an agreed set of message and timing rules. An application programming interface is a named way for software to ask another system for data or action; it is often shortened to API. Bluetooth Low Energy (BLE) is a short-range radio system. Constrained Application Protocol (CoAP) is a protocol for small devices. Transport layer security is protection for data moving across a network. Datagram Transport Layer Security (DTLS) applies that protection to message-based paths. A gateway is a device that joins one network to another.
Choose one term and attach it to a real artifact. For an interface, inspect a request and reply. For a radio link, inspect a connection or received record. For protection, inspect identity, permission, and a denied case. Then replace the term with a nearby but wrong one and state what part of the claim changes.
A short definition cannot teach the whole subject or prove a design. The deeper glossary entries add common confusions, related terms, examples, and chapter routes so each word becomes a precise starting point rather than a substitute for evidence.
This glossary section covers IoT terminology from A through F. Use the filter below or browser search to jump to a term, then read the definition, common confusions, related terms, and synonyms together. The most frequently reused terms in this range include API, BLE, CoAP, DTLS, Edge Computing, Authentication, Authorization, and Frame.
5.3 Start With The Boundary
When a new IoT term appears in a report, first ask what boundary it names. Authentication sits at the boundary between an unknown actor and a known identity. Authorization sits at the boundary between identity and permission. A frame sits at a local link boundary, while an API call sits at an application boundary. That boundary tells you which evidence to inspect.
This habit keeps glossary lookup practical. Instead of memorizing “BLE,” “CoAP,” “DTLS,” or “edge computing” as isolated phrases, attach each one to the artifact that proves it: a GATT characteristic, a confirmable message trace, a certificate chain, or a gateway placement decision. The definition becomes useful only when it helps a learner find the right piece of the system.
Use this A-F section as a boundary map. If two terms sound similar, compare the boundary each one owns and the failure it does not prevent.
5.4 Learning Objectives
After reviewing this section, you should be able to:
- Define key IoT terms from A to F with technical precision.
- Differentiate commonly confused concepts such as ACL vs. RBAC, authentication vs. authorization, edge vs. fog computing, and frame vs. packet.
- Apply appropriate terminology when discussing IoT protocols, architectures, hardware interfaces, data formats, and security.
- Use cross-references to move from a quick definition to deeper system-level understanding.
5.5 A-F Terms Name Boundaries
A glossary page is not only a vocabulary list. In IoT, the term usually names a boundary where responsibility changes. ACL, authentication, authorization, certificate, DTLS, encryption, and firewall name security boundaries. ACK, AMQP, at-least-once, at-most-once, exactly-once, BLE, CoAP, and frame name protocol or delivery boundaries. API, broker, cloud, digital twin, edge computing, and fog computing name architecture boundaries.
Read each term by asking what it lets you prove. Authentication proves identity, but it does not prove permission. Authorization limits actions, but it does not prove the device is genuine. Encryption protects bytes in transit or at rest, but it does not prove the endpoint certificate was validated. A frame is visible at a local link boundary, while an MQTT message or CoAP request is visible at an application boundary.
The A-F range is especially dense because it spans hardware, protocols, data representation, and security. ADC and DAC name conversion at a device pin. BLE and CoAP name communication models with different roles and reliability assumptions. CBOR, compression, aggregation, ETL, and data lake name different transformations of telemetry. Edge computing, fog computing, and cloud name operational placement, not just where software happens to run.
| Term Family | Boundary Question | Evidence To Inspect | Common Misread |
|---|---|---|---|
| Security | Who is the actor, and what may it do? | Certificate, token, ACL, role, topic permission, firewall rule | Identity is treated as permission |
| Delivery | Which layer acknowledged what state? | ACK, QoS setting, broker log, CoAP response, retry record | Receipt is treated as application processing |
| Data | Did the payload change form or meaning? | CBOR or JSON payload, schema version, ETL step, aggregation window | Encoding is treated as validation |
| Placement | Where is state processed and owned? | Edge node, fog gateway, cloud service, API contract, digital twin update | Location is treated as ownership |
Use each A-F term as a boundary test: identify the artifact, the owner, and the promise the term actually makes.
5.6 Attach Every Term To An Artifact
When a glossary term appears in a lab report, design review, or capstone submission, attach it to an artifact. For API, inspect the endpoint contract, request method, status code, authentication requirement, and error behavior. For BLE, inspect the advertiser role, connection interval, GATT service, characteristic UUID, permissions, and phone or gateway role. For CoAP, inspect the method, confirmable or non-confirmable message type, response code, token, retransmission behavior, and whether DTLS is required.
Do the same for security terms. Authentication evidence might be a device certificate, pre-shared key exchange, login trace, signed token, or mutual TLS handshake. Authorization evidence might be an ACL entry, IAM policy, OAuth scope, topic permission, role mapping, or denied-action log. A firewall rule is useful only when the report names the address, port, protocol, owner, and reason the rule exists.
Data terms need a different artifact trail. CBOR, JSON, compression, aggregation, ETL, filter, and data lake should be tied to a payload sample, schema, transform step, retention policy, and query that proves the interpretation still matches the original measurement. If a gateway aggregates one-minute readings into hourly averages, the report should say which outliers disappear and whether alerting uses raw or aggregated data.
The practical method is four fields: term, artifact, boundary, next check. The artifact is what the learner can inspect. The boundary states what the term proves and what it does not. The next check points to the chapter, packet capture, dashboard query, datasheet, standard, or bench test that can settle the design question. That turns the glossary from memorization into engineering review.
Use the same four fields when reviewing someone else’s wording. If a teammate writes “the edge filters the data,” ask which edge node, which filter rule, which input fields, which output record, and which fallback exists when the node is offline. If the answer cannot be shown in a log, configuration file, capture, or test record, the term is still too abstract for a project claim.
5.7 Words Hide Protocol Scope
Under the hood, many A-F terms look similar because they are often described with short textbook phrases. The implementation scope is what separates them. An ACK can mean a TCP segment arrived, a CoAP confirmable message was received, an AMQP broker accepted a delivery, or an application command was processed. Those events sit at different layers and give different guarantees. A report that only says “the ACK was received” has not yet named the contract.
Exactly-once is another scope-sensitive term. It may describe stream-processing state inside a broker, idempotent application writes, deduplicated storage commits, or a transaction boundary. It rarely means that every physical sensor event is acted on exactly once across device resets, retries, network partitions, and dashboard refreshes. At-least-once and at-most-once also need a boundary: packet delivery, broker acceptance, database row, command execution, or user-visible state.
Security terms hide similar scope. DTLS protects UDP traffic, but endpoint validation, key rotation, certificate expiry, authorization, logging, and recovery remain separate design decisions. Encryption can protect bytes while metadata, topic names, timestamps, or access policies still leak operational meaning. A certificate can establish a trust chain while a misconfigured ACL still grants the wrong device action.
Architecture terms hide ownership. Edge computing may reduce latency and bandwidth, but it also moves update, observability, and failure-recovery responsibilities closer to the device. Fog computing may coordinate several local nodes, but it still needs a contract for cloud sync and local fallback. Cloud may simplify storage and dashboards, but it introduces dependency on identity, quota, retention, network reachability, and service-owner response.
Data representation terms hide one more layer of scope. CBOR can reduce payload size, but it does not define units, calibration, retention, or semantic validity. Compression can shrink a signal while making local inspection harder. Aggregation can stabilize dashboards while erasing spikes that matter for safety or maintenance. The technical term is therefore only complete when the report names what evidence survived the transformation.
5.8 Deep Dive: A-F Terms Mark System Boundaries
A glossary entry is useful when it helps you name the right boundary. Terms in A-F cover security boundaries such as ACL, authentication, authorization, certificate, DTLS, encryption, and firewall; protocol boundaries such as ACK, AMQP, BLE, CoAP, at-most-once, at-least-once, and exactly-once; and architecture boundaries such as API, broker, cloud, digital twin, edge computing, fog computing, and frame. Read Figure 5.1 from application protocols down to physical constraints before assigning ownership.
Read Figure 5.1 from application protocols down through transport, network, local link, and physical constraints. Each row assigns responsibility to a different layer. Use the definition to recognize the term, then use the common-confusion notes to avoid treating nearby concepts as interchangeable: authentication is not authorization, a frame is not a routed packet, and edge is not cloud placement.
Read Figure 5.1 from top to bottom: MQTT, CoAP, and HTTP sit at the application boundary; TCP and UDP supply transport; IPv4, IPv6, ICMP, and RPL supply network behavior; and Ethernet, Wi-Fi, IEEE 802.15.4, and MAC addresses govern local delivery. At the bottom, RSSI, interference, MTU, cable, and channel quality constrain the path. That order keeps a glossary lookup tied to the component that can actually fix a fault.
Use the same habit for terms outside the stack diagram. ACL and RBAC name different authorization models. A certificate supports identity and trust, but it does not automatically prove an account has the right permission. Cloud, edge, and fog name placement and operational ownership, not just where code happens to run. Broker, API, and digital twin name different contracts in the system. If a term changes who owns a fault, who validates data, or where state is stored, treat it as a design boundary.
| Check | Question to Ask |
|---|---|
| Definition | What does the term mean in an IoT architecture, protocol, hardware, or security context? |
| Boundary | What does the term not mean, and which adjacent term is it often confused with? |
| Next action | Which cross-reference, lab, quiz, or project decision changes if this term is interpreted correctly? |
5.8.1 Check the Term Against a Real Artifact
Do not memorize a glossary term in isolation. Tie it to an artifact: an MQTT QoS setting, a CoAP message type, a BLE GATT characteristic, a REST API endpoint, an ACL rule, an OAuth scope, a DTLS handshake, a frame capture, an edge deployment diagram, or a data-pipeline step. The term becomes useful when it helps explain what the artifact is doing.
For delivery terms, name the operational consequence. At-most-once can lose messages. At-least-once can duplicate messages and needs idempotent handling. Exactly-once usually depends on coordination, deduplication, transactions, or stream-processing semantics, and the contract often applies only inside a defined boundary.
When a term appears in a project report, attach it to evidence. For authentication, show the login flow, device certificate, pre-shared key, or token exchange that proves identity. For authorization, show the ACL, IAM policy, OAuth scope, topic permission, or role mapping that limits action. For BLE, show the GATT service, characteristic UUID, advertising interval, connection interval, and phone or gateway role. For CoAP, show whether the message is confirmable, what method and response code appear, and whether DTLS is used. For frame, show the capture layer, header fields, payload length, checksum, and whether a gateway converts that local frame into a routed packet or application record.
A useful glossary note therefore has four fields: term, artifact, boundary, and next check. The artifact is the object being inspected. The boundary says what the term promises and what it does not. The next check sends the learner to the chapter, standard, datasheet, packet capture, or bench test that can settle the claim. That pattern is especially important for A-F terms because many of them look simple in a list but become risky when they control security, delivery guarantees, device placement, or data meaning.
- Pick the artifact. Example: a broker log, packet trace, IAM policy, board pinout, or cloud API response.
- Name the term. Example: authorization, ACK, CBOR, dead letter queue, duty cycle, or frame.
- State the boundary. Example: what changes if the protocol, device role, trust model, or processing location changes?
5.8.2 Glossary Precision Prevents Design Errors
Small vocabulary errors become implementation errors. Confusing authentication with authorization can produce accounts that prove identity but receive the wrong permissions. Confusing encryption with certificate validation can protect data in transit while still accepting the wrong endpoint. Confusing aggregation with raw telemetry can hide outliers that a device-health workflow needs.
The same is true for protocol semantics. MQTT QoS 1, AMQP acknowledgements, CoAP confirmable messages, and stream-processing exactly-once claims do not all mean the same thing. Each defines a scope: packet receipt, broker acceptance, application processing, storage commit, or downstream consumer state. Read glossary terms with that scope in mind.
Underneath the vocabulary, every term is tied to a state transition or contract. An ACK may confirm that a TCP segment arrived, that a CoAP confirmable message was received, that an AMQP broker accepted a delivery, or that application code processed a command. Those are different guarantees. Encryption may protect bytes on the wire, while certificate validation decides whether the endpoint is trusted. A firewall may filter at an address, port, or protocol boundary, while an application authorization rule may decide whether a device can write to a specific topic or API route.
Data terms have the same hidden scope. CBOR, JSON, compression, aggregation, ETL, and data lake are not interchangeable labels for “data handling.” They describe representation, size trade-offs, transformation, storage, retention, and later interpretation. A frame may include link-layer headers and checksums, while an application record may include stable field names, units, timestamps, schema version, and device identity. If the report says “the broker received the frame,” the wording is probably mixing layers; the gateway or radio stack sees the frame, while the broker sees a message or application payload.
A good capstone explanation should use these terms to identify responsibility: which device, broker, gateway, cloud service, dashboard, or human operator owns the next state transition.
5.9 Key Concepts
API (Application Programming Interface): A defined contract that lets software components communicate. In IoT, REST APIs expose device data to applications, while device APIs let firmware interact with hardware peripherals. Actuator: A hardware component that converts electrical signals to physical action such as motor rotation, valve opening, or LED illumination. BLE (Bluetooth Low Energy): A short-range wireless protocol optimized for periodic low-power data transmission. CoAP (Constrained Application Protocol): A lightweight REST-like protocol for constrained devices, using UDP with optional reliability and compact encoding. DTLS (Datagram TLS): A security protocol that brings TLS-like authentication and encryption to UDP traffic. Edge Computing: Processing data near the source device to reduce latency, bandwidth use, cloud cost, and dependence on continuous connectivity.
5.10 How It Works: Turn a Term into a Design Choice
A glossary lookup should end with a better design choice, not just a remembered definition. Start with the artifact you are inspecting: an ACL rule, BLE GATT characteristic, CoAP confirmable message, ADC reading, broker topic, DTLS handshake, edge gateway, or frame capture. Then check the definition and its nearest confusion so the boundary is explicit; authentication is not authorization, encryption is not certificate validation, and a frame is not a routed packet. Finally choose the next action, such as adding idempotency, moving filtering, or separating cloud access. The three visuals below apply that sequence at system, protocol, and data boundaries.
First read Figure 5.2 from the sensor node and gateway toward the actuator, user interface, and cloud backend. Ask where the term changes responsibility and which artifact would prove that handoff.
In Figure 5.2, actuator belongs at the physical-output boundary, edge computing and gateway describe local processing or translation, and broker, API, and cloud refer to different upstream contracts. This placement prevents one broad term from hiding several owners. Next, use Figure 5.3 to inspect the same system by communication layer.
Follow Figure 5.3 upward from media and local framing through network routing and transport to application protocols. Frame, channel, and bandwidth constrain lower-layer delivery; DTLS protects a datagram transport; CoAP and AMQP define application exchanges. The walk-through clarifies which header, trace, or configuration should carry the evidence. Finally, Figure 5.4 shows what happens to the payload itself.
Read Figure 5.4 from device payload through encoding and validation, then through transformation and storage to downstream use. CBOR and compression change representation or size, filters and aggregation change the retained evidence, and ETL or a data lake changes where later interpretation occurs. This final view connects vocabulary to data lineage, completing the artifact-boundary-action method.
5.11 For Beginners: IoT Glossary A-F
A glossary is a focused dictionary for course vocabulary. When you meet a term such as “CoAP” or “edge computing,” use this page to get the short definition, the plain-language explanation, and the common mistakes to avoid.
This is part 1 of the IoT Glossary, covering terms A-F. See also:
Glossary A-F - start of the glossary sequence and quick navigation Glossary G-P - Gateway through Publisher Glossary Q-Z - QoS through 6LoWPAN
5.12 Quick Lookup
Reference usability can be estimated by lookup coverage:
Worked example: If learners perform 220 glossary lookups and 198 are resolved without leaving the section, usability is . Improving cross-references and examples should push this ratio higher.
5.13 A
5.13.1 ACL (Access Control List)
Definition: A security mechanism that specifies which users, devices, or systems are granted or denied access to particular resources, and what operations they can perform.
In simple terms: A list that says who can do what - like a VIP list for a club that specifies which guests can enter which rooms.
Common confusions:
- ACL vs. RBAC (Role-Based Access Control) - ACLs are resource-centric while RBAC is role-centric
- ACLs define permissions per resource, not per user globally
Related terms: Authentication, Authorization, OAuth
Synonyms: access list, permission list
5.13.2 Acknowledgment (ACK)
Definition: A signal or message sent by a receiving device to confirm successful receipt of data, enabling the sender to know transmission was successful.
In simple terms: A “message received” confirmation - like texting “got it” when someone sends you important information.
Common confusions:
- ACK vs. response - ACK confirms receipt, response contains actual reply data
- Different protocols implement ACKs differently (TCP vs. UDP)
Related terms: QoS, At-least-once, Retry
Synonyms: ACK, confirmation
5.13.3 Actuator
Definition: A device that converts electrical signals or energy into physical action, enabling IoT systems to affect the physical world through motion, heat, light, or other outputs.
In simple terms: The “muscles” of an IoT system - while sensors are the eyes and ears, actuators are the hands that actually do things like turn on lights or open valves.
Common confusions:
- Actuator vs. sensor - sensors read data, actuators perform actions
- Not all output devices are actuators (displays show data but don’t perform physical actions)
Related terms: Sensor, GPIO, DAC
Synonyms: effector, output device
5.13.4 ADC (Analog-to-Digital Converter)
Definition: An electronic circuit that converts continuous analog signals (like voltage from a sensor) into discrete digital values that can be processed by a microcontroller.
In simple terms: A translator that converts real-world measurements (like temperature as voltage) into numbers a computer can understand.
Common confusions:
- ADC resolution (bits) determines precision, not accuracy
- Sampling rate and resolution are independent specifications
Related terms: DAC, Sensor, GPIO, Sampling
Synonyms: A/D converter, analog-digital converter
5.13.5 Aggregation
Definition: The process of combining multiple data points into summary statistics (sum, average, min, max, count) to reduce data volume while preserving meaningful information.
In simple terms: Summarizing lots of small measurements into useful totals - like calculating your average daily steps from thousands of individual step counts.
Common confusions:
- Aggregation loses individual data points (cannot recover original values)
- Different aggregation functions suit different use cases (average vs. sum vs. max)
Related terms: Time Series, Sampling, Telemetry
Synonyms: summarization, rollup
5.13.6 AMQP (Advanced Message Queuing Protocol)
Definition: An open standard application layer protocol for message-oriented middleware, providing reliable queuing, topic-based publish-subscribe, flexible routing, and transactions.
In simple terms: A sophisticated postal system for software - it ensures messages get delivered reliably with options for different delivery patterns and confirmations.
Common confusions:
- AMQP vs. MQTT - AMQP is more feature-rich but heavier; MQTT is simpler and lighter
- AMQP 0.9.1 (RabbitMQ) vs. AMQP 1.0 are quite different protocols
Related terms: MQTT, Broker, Publisher, Subscriber
Synonyms: none common
5.13.7 API (Application Programming Interface)
Definition: A set of defined rules, protocols, and tools that specify how software components should interact, enabling different applications to communicate and share data.
In simple terms: A menu at a restaurant - it tells you what you can order (available functions) and how to order it (required format), without needing to know how the kitchen works.
Common confusions:
- API vs. SDK - API defines the interface, SDK provides tools to use it
- REST API vs. API - REST is one style of API, not all APIs are RESTful
Related terms: REST, HTTP, Microservices
Synonyms: interface, service endpoint
5.13.8 At-least-once
Definition: A message delivery contract where the sender retries until an acknowledgement boundary is reached, reducing loss within that boundary but potentially causing duplicates that receivers must handle.
In simple terms: “Better safe than sorry” delivery - the system keeps trying until it’s sure you got the message, even if that means sending it twice.
Common confusions:
- At-least-once requires idempotent receivers to handle duplicates properly
- More reliable than at-most-once but less than exactly-once
Related terms: QoS, At-most-once, Exactly-once, Idempotency
Synonyms: QoS 1 (in MQTT)
5.13.9 At-most-once
Definition: A message delivery contract where messages are sent zero or one time, providing best-effort delivery without retries, which may result in message loss.
In simple terms: “Fire and forget” delivery - send the message once and hope it arrives, like shouting across a noisy room.
Common confusions:
- At-most-once is not unreliable by design - it’s appropriate for frequent, non-critical data
- Often used for high-frequency sensor data where occasional loss is acceptable
Related terms: QoS, At-least-once, Exactly-once
Synonyms: QoS 0 (in MQTT), best-effort delivery
5.13.10 Authentication
Definition: The process of verifying the identity of a user, device, or system, typically through credentials like passwords, certificates, tokens, or biometrics.
In simple terms: Proving who you are - like showing your ID at a security checkpoint before being allowed in.
Common confusions:
- Authentication vs. authorization - authentication proves identity, authorization grants permissions
- Strong authentication often requires multiple factors (MFA)
Related terms: Authorization, Certificate, Token, OAuth
Synonyms: identity verification, login
5.14 Continue to Part 2
Continue with IoT Glossary: B-F.