6. IoT Networking, Addressing, and Communication Protocols

Introduction and Context

An Internet of Things system is not merely a collection of sensors connected to the Internet. It is a distributed communication system in which constrained devices, gateways, edge platforms, cloud services, users, and organizational processes exchange information under changing conditions. Networking determines whether sensed data can be delivered reliably, whether devices can be discovered and managed, whether control commands arrive within acceptable time limits, and whether the resulting system can scale economically.

IoT networking is difficult because its endpoints differ greatly in processing power, energy supply, radio range, memory, mobility, and application requirements. A battery-operated environmental sensor may transmit a few bytes every ten minutes, whereas an industrial controller may require deterministic delivery within milliseconds. A smart-home device may communicate through a local wireless mesh, while a logistics asset may move between networks and use cellular connectivity. Consequently, no single protocol is optimal for all IoT situations.

This chapter examines networking across the IoT protocol stack. It begins with IPv6 and adaptation mechanisms for constrained networks, then considers routing, discovery, time synchronization, mobility, software-defined networking (SDN), and network virtualization. It subsequently compares application and messaging protocols—MQTT, CoAP, AMQP, DDS, HTTP, and WebSockets—and develops a framework for selecting among them. The discussion treats protocols not as isolated technologies but as design choices embedded in architecture, governance, security, and operational practice.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain why IPv6 is strategically important for large-scale IoT deployments.

2. Describe how 6LoWPAN adapts IPv6 to low-power and lossy networks.

3. Analyze RPL routing, neighbor discovery, addressing, and time-synchronization mechanisms.

4. Evaluate the networking consequences of mobility, gateways, SDN, and network virtualization.

5. Compare MQTT, CoAP, AMQP, DDS, HTTP, and WebSockets according to communication model and quality of service.

6. Select protocols using requirements such as energy, latency, reliability, scalability, interoperability, and security.

7. Critically identify operational, ethical, governance, and research challenges in IoT networking.

Addressing the Internet of Things: IPv6 and Constrained Networks

IPv6 provides a 128-bit address space and therefore removes the address scarcity associated with large-scale deployment of uniquely addressable devices. Its importance extends beyond the quantity of addresses. IPv6 supports hierarchical allocation, efficient aggregation, standardized autoconfiguration, multicast, and end-to-end architectural possibilities. These features are valuable when millions of devices must be provisioned, identified, monitored, and integrated across organizational boundaries.

An IPv6 address normally consists of a network prefix and an interface identifier. Devices may obtain addresses through Stateless Address Autoconfiguration, DHCPv6, or a combination of mechanisms. In IoT, address assignment must be coordinated with identity management, device lifecycle management, routing policy, and security. An address identifies a network interface; it should not automatically be treated as a permanent human or organizational identity. Devices may be replaced, reconfigured, moved, or represented through gateways.

IPv6 also changes assumptions about network boundaries. Network Address Translation can conceal devices and complicate direct communication, while excessive reliance on NAT may conflict with end-to-end management and security models. Nevertheless, direct reachability is not inherently desirable: industrial and domestic systems often require segmentation, firewalls, authorization gateways, and carefully restricted exposure. IPv6 makes architectural discipline more important, not less.

Low-power and lossy networks (LLNs) introduce constraints that ordinary IPv6 mechanisms were not designed to handle efficiently. Links may have small maximum transmission units, low data rates, intermittent connectivity, high packet loss, and devices with limited RAM and battery capacity. 6LoWPAN, specified through the IETF standards process, is an adaptation layer that enables IPv6 packets to operate over technologies such as IEEE 802.15.4.

6LoWPAN performs several important functions. Header compression reduces the overhead of IPv6 and transport headers. Fragmentation and reassembly allow packets larger than the link-layer frame size to be transported. Mesh-under forwarding can operate beneath the IP layer, whereas route-over forwarding treats each IPv6 hop as an IP router. The choice affects routing visibility, fault diagnosis, mobility, and interoperability with upper-layer IP services.

Compression is beneficial but not free. Context-based compression depends on shared assumptions and correct state at communicating nodes. Fragmentation creates additional loss risk because losing one fragment may invalidate a complete datagram. Designers should therefore minimize payload size, avoid unnecessary transport overhead, and evaluate the interaction between link-layer retransmission, IP fragmentation, and application acknowledgements.

Routing, Discovery, and the Shape of an IoT Network

Routing in an IoT network must account for more than shortest path. A useful route may minimize expected energy consumption, balance traffic, avoid unreliable links, respect latency constraints, and preserve connectivity to a gateway. These objectives can conflict. A path with fewer hops may consume more energy if its links are poor; a highly reliable path may overload a central parent; and a route optimized for energy may violate a control-loop deadline.

RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks, is designed for LLNs. It constructs a Destination-Oriented Directed Acyclic Graph, commonly called a DODAG, rooted at a gateway or sink. Nodes select parents according to an objective function. Rank represents a node's position relative to the root and helps prevent routing loops. Control messages include DIO messages for discovering and joining a DODAG, DIS messages for requesting information, and DAO messages for establishing downward routes.

RPL supports storing and non-storing modes. In storing mode, routers maintain routing information for descendants, which can consume substantial memory. In non-storing mode, the root maintains downward-routing information and may place source-routing information in packets, increasing packet size and processing demands. RPL also uses Trickle-like control behavior to reduce unnecessary routing traffic when the network is stable while responding more rapidly to inconsistency.

RPL is not a universal solution. Its operation can be complicated by mobile nodes, rapidly changing links, asymmetric connectivity, many-to-one traffic patterns, and attacks that manipulate rank or parent selection. Objective functions must be selected carefully. A routing metric based only on hop count can produce poor energy and reliability outcomes, while a complex metric may increase computational and management overhead. Research remains active on multipath RPL, mobility support, trust-aware routing, and routing for time-critical industrial systems.

Neighbor discovery in conventional IPv6 can be chatty for constrained devices. 6LoWPAN Neighbor Discovery reduces unnecessary multicast and supports registration mechanisms suited to sleeping nodes. Discovery also exists at higher layers: a device must be found not only as an IP endpoint but as a temperature sensor, actuator, resource, service, or digital-twin component. Resource directories, DNS-based mechanisms, multicast discovery, and application registries may all be appropriate, depending on scale and administrative control.

A sound discovery design distinguishes three questions: Where is the endpoint? What capability does it offer? Is the requester authorized to use it? Treating discovery as a purely technical lookup can expose sensitive information about homes, factories, or people. Metadata should therefore be minimized, authenticated, and governed by access policies.

Time Synchronization and Temporal Semantics

Many IoT applications depend on time. Energy systems correlate measurements across substations; industrial systems order events; sensor-fusion algorithms align observations; and security protocols validate certificates or detect replay. Time synchronization may concern wall-clock time, monotonic ordering, or bounded coordination rather than exact global time.

Protocols such as the Network Time Protocol provide general Internet synchronization, while the Precision Time Protocol can achieve much tighter coordination in suitable wired or engineered networks. Constrained wireless systems may use lightweight reference broadcasts, flooding, or application-specific synchronization. The appropriate method depends on oscillator quality, radio duty cycle, topology, required accuracy, and energy budget.

A critical distinction is between clock offset and clock drift. Offset is the current difference between clocks; drift is the rate at which that difference changes. Synchronization messages correct offset but consume energy and bandwidth. Timestamp uncertainty should be propagated into analytics and control decisions rather than hidden behind a misleadingly precise timestamp. In safety-critical contexts, systems should define behavior when time quality degrades.

Mobility, Gateways, and Intermittent Connectivity

Mobility occurs at several levels: a device may move between radio cells, a gateway may change its upstream connection, or an application may migrate between edge and cloud locations. Mobility can invalidate routes, change addresses, alter latency, and interrupt long-lived sessions. A mobile sensor attached to a vehicle has different requirements from a wearable that moves among Wi-Fi networks or a robot operating within an industrial mesh.

Mobility management may preserve an IP address, preserve an application identity while allowing the address to change, or tolerate disconnection through store-and-forward techniques. In practice, application-level session continuity is often more important than preserving a particular IP address. Gateways can hide local topology, translate protocols, buffer data, enforce policy, and perform edge analytics. However, gateways may become bottlenecks or single points of failure and can obscure end-to-end security and observability.

Intermittently connected devices require explicit decisions about buffering, duplicate detection, ordering, expiration, and conflict resolution. A system that retries indefinitely may waste energy and amplify congestion. A system that discards all delayed messages may lose safety-relevant evidence. Delivery semantics must therefore be tied to data value and age: a temperature reading may remain useful after delay, while an actuator command may become dangerous if delivered late.

Programmable Networks: SDN and Network Virtualization

Software-defined networking separates, conceptually, the control plane that decides forwarding behavior from the data plane that forwards packets. A controller can maintain a broader view of topology and apply policies centrally or hierarchically. In IoT, SDN may support segmentation of industrial traffic, dynamic quality-of-service policies, isolation of vulnerable devices, service-chain placement, and rapid response to failures.

Centralization does not eliminate complexity. A controller must receive trustworthy telemetry, scale to large and intermittent populations, and continue operating when connectivity to devices is lost. Distributed control, local autonomy, and controller federation are often necessary. SDN policies must also account for radio interference and energy constraints, which are not adequately represented by conventional wired-network metrics.

Network virtualization creates logical networks over shared physical infrastructure. Virtual networks can separate tenants, applications, trust domains, or service classes. Network functions such as firewalls, gateways, protocol translators, and brokers may be implemented as software instances at the edge or in the cloud. Network slicing is a related approach in which differentiated logical services are created over common infrastructure.

Virtualization improves utilization and flexibility but introduces placement, isolation, monitoring, and failure-domain questions. A virtual firewall that shares a host with untrusted workloads may weaken assurance. A virtual broker placed too far from sensors may increase latency. Researchers and practitioners should evaluate not only performance but also verifiability, portability, and the consequences of orchestration errors.

Messaging and Application Protocols

MQTT

MQTT is a lightweight publish/subscribe protocol usually transported over TCP, often with TLS. Clients publish messages to topics, and a broker routes them to subscribers. This decouples producers and consumers in space and time and is particularly useful for telemetry, event distribution, and device-to-cloud integration. MQTT quality-of-service levels commonly express at-most-once, at-least-once, and exactly-once delivery intentions. At-least-once delivery can produce duplicates, so consumers should be idempotent. Retained messages, persistent sessions, wills, and topic-based access control support practical device management.

MQTT is efficient and widely supported, but the broker can become a scaling or availability concern. Topic design, authorization, message ordering, payload schemas, and broker clustering require careful governance. MQTT does not by itself guarantee that a physical action occurred; it only defines messaging behavior.

CoAP

CoAP is designed for constrained nodes and networks. It follows a REST-oriented resource model with methods analogous to GET, POST, PUT, and DELETE and commonly uses UDP. Confirmable messages provide acknowledgement and retransmission, while non-confirmable messages reduce overhead. CoAP supports resource discovery and can be secured with OSCORE or transport mechanisms such as DTLS, depending on the deployment.

CoAP is suitable for direct device resource access, local automation, and constrained request/response interactions. Proxies can translate between CoAP and HTTP, enabling web integration. Designers must account for UDP filtering, congestion control, duplicate requests, multicast behavior, and the difference between message reliability and application transaction correctness.

AMQP

AMQP is a feature-rich messaging protocol emphasizing reliable enterprise messaging, queues, routing, acknowledgements, transactions, and broker-managed delivery. It is appropriate where message durability, complex routing, and integration with business systems are more important than minimal device overhead. Its richer semantics generally require more resources than a sensor node can provide, so AMQP is often placed at gateways, edge services, or cloud platforms rather than directly on highly constrained endpoints.

DDS

Data Distribution Service uses a data-centric publish/subscribe model and is designed for distributed real-time systems. It supports rich quality-of-service policies concerning reliability, durability, deadline, ownership, liveliness, and resource limits. DDS can offer decentralized discovery and fine-grained control, making it relevant to robotics, autonomous systems, and industrial automation. Its configuration and implementation complexity may be excessive for simple telemetry applications.

HTTP and WebSockets

HTTP has exceptional ecosystem support, mature tools, and straightforward integration with web services, APIs, identity systems, and observability platforms. Its request/response model is appropriate for configuration, administration, and cloud integration, but repeated connections and verbose headers can be inefficient for small, battery-powered devices. HTTP/2 and HTTP/3 improve transport behavior in some contexts but do not remove the need to evaluate device constraints.

WebSockets begin with an HTTP handshake and then provide a persistent, bidirectional channel. They are useful for dashboards, interactive control, and real-time browser communication. Persistent connections consume resources and require careful handling of reconnection, authentication renewal, backpressure, and intermediary failures. WebSockets should not be selected merely because an application is described as real time; the required latency, directionality, and reliability semantics must be specified first.

A Framework for Protocol Selection

Protocol selection should begin with requirements rather than popularity. The following dimensions are especially important:

• Payload size and message frequency.
• Energy budget, memory, processor capacity, and radio constraints.
• Latency, jitter, ordering, and deadline requirements.
• Delivery semantics, duplicate tolerance, durability, and offline behavior.
• Communication pattern: request/response, publish/subscribe, streaming, or data-centric exchange.
• Network topology, mobility, intermittency, and administrative boundaries.
• Security requirements, including confidentiality, integrity, authentication, authorization, and key lifecycle management.
• Interoperability, existing tools, operational skills, and lifecycle cost.

A useful engineering method is to define scenarios, assign measurable thresholds, eliminate protocols that violate hard constraints, and then compare the remaining choices through a weighted decision matrix or prototype. Tests should include loss, congestion, sleep cycles, broker or gateway failure, clock uncertainty, firmware updates, and credential rotation. Average latency alone is inadequate; tail latency, energy per successfully delivered message, recovery time, and duplicate or stale-command rates may be more informative.

Protocols can be combined. A constrained device may use CoAP over a local LLN, a gateway may translate or publish selected data through MQTT, and an enterprise platform may use AMQP or HTTP. Such composition is useful but introduces semantic translation risks. A QoS concept in DDS does not map perfectly to an MQTT QoS level, and a CoAP confirmable message does not guarantee the same outcome as a committed business transaction. Gateways must preserve, explicitly weaken, or reject semantics rather than silently misrepresent them.

Applied Case: A Connected Cold-Chain Monitoring System

Background

Consider an illustrative logistics company transporting vaccines in refrigerated containers. Battery-powered sensors measure temperature, humidity, door state, and battery condition. Containers move through warehouses, vehicles, and distribution centers, often crossing networks with intermittent connectivity.

Situation and Problem

The company initially sends every reading directly to a cloud HTTP endpoint. Sensors consume batteries quickly, data is lost during cellular outages, and the cloud application cannot distinguish a delayed temperature observation from a current actuator command. Multiple vendors also use incompatible identifiers and timestamp formats.

Analysis

The sensing network is constrained and intermittently connected. Temperature readings are valuable even when delayed, but a refrigeration-control command has a short validity period. The system needs local buffering, authenticated device identity, reliable event delivery for alarms, and efficient routine telemetry. It also needs synchronized time with an explicit uncertainty estimate.

Approach and Solution

Sensors communicate through a low-power local network using IPv6 adaptation and a suitable LLN routing design. A gateway performs local discovery, buffers readings, validates timestamps, and exposes a controlled management interface. CoAP is used for lightweight local resource access and configuration. The gateway publishes telemetry and alarm events through MQTT over TLS, using separate topics and authorization policies for each organizational role. At-least-once delivery is selected for alarms, with message identifiers and idempotent cloud processing. Routine readings may tolerate loss and are batched when connectivity is expensive.

The gateway uses a monotonic sequence number in addition to wall-clock time. Commands include an expiry time, target version, and authorization context. Network segmentation prevents sensor interfaces from reaching unrelated corporate systems. Monitoring measures battery consumption, message age, duplicate rate, gateway backlog, and alarm-delivery time.

Outcome

The architecture reduces radio and cellular overhead, preserves data through temporary outages, and prevents stale commands from being treated as current instructions. It also makes responsibility clearer: the gateway handles local continuity, the broker handles distribution, and the cloud platform handles long-term analytics. The design remains dependent on secure gateway maintenance and accurate policy configuration.

Learning Points

First, protocol choice follows operational semantics, not simply payload format. Second, buffering and expiry are essential for intermittent IoT systems. Third, translation between protocols must preserve identity, timestamps, delivery status, and authorization. Finally, reliability must be measured at the application outcome level rather than inferred from transport acknowledgements.

Risks, Limitations, and Professional Governance

Common mistakes include selecting a protocol because it is familiar, treating QoS as a guarantee of physical action, using one shared credential for all devices, exposing discovery metadata publicly, ignoring clock uncertainty, and assuming that a gateway solves every interoperability problem. Another mistake is optimizing average energy consumption while overlooking retransmission storms, firmware-update traffic, or failure recovery.

Security must be layered. Link protection, IP security, transport encryption, application authorization, secure boot, protected key storage, and auditable provisioning address different threats. Encryption does not prevent an authorized but compromised device from issuing harmful commands. Least privilege, network segmentation, anomaly detection, credential rotation, signed updates, and revocation procedures are therefore essential.

Governance includes data minimization, retention limits, ownership of telemetry, lawful monitoring, and accountability for automated decisions. Location, occupancy, health, and industrial data can reveal sensitive information even when payloads appear technically harmless. Procurement contracts should define protocol versions, patch obligations, vulnerability disclosure, interoperability tests, and exit strategies. Standards compliance should be verified through conformance testing rather than assumed from a product label.

Emerging Directions and Research Questions

Current research explores deterministic wireless networking, time-sensitive edge control, low-power wide-area integration, semantic interoperability, network digital twins, intent-based orchestration, and learning-assisted routing. Machine-learning methods may predict link quality, detect routing attacks, or place services at the edge, but models can fail under distribution shift and may be difficult to verify in safety-critical environments. AI should therefore complement, not replace, explicit safety constraints and interpretable operational policies.

Future IoT networks are likely to be heterogeneous: short-range mesh, cellular, satellite, wired industrial networks, and opportunistic links will coexist. The research challenge is not merely to connect more devices but to provide composable assurances about identity, timing, reliability, privacy, and energy across administrative and technological boundaries. Protocol designers must also address long device lifetimes, post-quantum migration, sustainable energy use, and the governance of autonomous network decisions.

Best-Practice Guidance

A robust IoT networking program should:

1. Model devices, data, services, and identities separately.

2. Define application-level delivery and freshness requirements before selecting protocols.

3. Use IPv6 and constrained-network adaptations where they improve lifecycle management and interoperability.

4. Treat routing metrics, time quality, mobility, and gateway failure as explicit design variables.

5. Use least privilege, mutual authentication, secure updates, and network segmentation from the beginning.

6. Test under loss, congestion, sleep cycles, mobility, clock error, and partial failure.

7. Make protocol translation semantics explicit and observable.

8. Measure energy, tail latency, data age, duplicate rate, recovery time, and operational cost.

9. Maintain versioned schemas, identifiers, and configuration policies.

10. Design for decommissioning, replacement, and organizational change—not only initial deployment.

Chapter Summary

IoT networking links constrained devices to edge, enterprise, and cloud systems under demanding energy, reliability, timing, and security conditions. IPv6 provides scalable addressing and an extensible Internet foundation, while 6LoWPAN adapts IPv6 to low-power and lossy links. RPL constructs routing structures suited to LLNs, although mobility, unstable links, routing attacks, and competing metrics remain difficult. Neighbor discovery, time synchronization, gateway behavior, and intermittent connectivity determine whether a network is operationally useful rather than merely connected.

SDN and virtualization provide programmability, segmentation, and flexible service placement but introduce controller, isolation, and orchestration risks. MQTT, CoAP, AMQP, DDS, HTTP, and WebSockets embody different communication models and resource assumptions. No protocol supplies universal reliability or security; selection must be based on measurable application requirements and validated through realistic failure testing. Effective IoT architecture preserves semantics across protocol boundaries, incorporates governance and lifecycle management, and treats security, privacy, and operational observability as network-design requirements.

Key Terms

IPv6: Internet Protocol version 6 using 128-bit network addresses.

6LoWPAN: Adaptation technology enabling IPv6 communication over low-power wireless personal-area networks.

LLN: Low-power and lossy network characterized by constrained resources and unreliable links.

RPL: IPv6 routing protocol designed for low-power and lossy networks.

DODAG: Destination-Oriented Directed Acyclic Graph constructed by RPL around a root.

Rank: RPL value representing a node’s relative position in a DODAG.

Neighbor discovery: Processes through which nodes identify reachable neighbors, addresses, and services.

Header compression: Reduction of protocol-header overhead to conserve constrained-link capacity.

Fragmentation: Division of a large packet into smaller link-compatible units.

MQTT: Broker-based publish/subscribe messaging protocol widely used for IoT telemetry.

CoAP: Lightweight REST-oriented protocol designed for constrained devices and networks.

AMQP: Enterprise messaging protocol supporting queues, acknowledgements, routing, and durable delivery.

DDS: Data-centric publish/subscribe middleware with rich real-time quality-of-service policies.

WebSockets: Persistent, bidirectional communication channel established through HTTP.

SDN: Networking approach separating forwarding functions from programmable control functions.

Network virtualization: Creation of logical networks or network functions over shared physical resources.

Quality of service: Policies describing communication properties such as reliability, latency, deadline, or durability.

Idempotence: Property whereby repeating an operation produces the same intended result as performing it once.

Edge gateway: Intermediate system that connects local devices to wider networks and may buffer, translate, or analyze data.

Clock drift: Gradual change in the rate of one clock relative to another.

Review Questions

Short Answer Questions

1. Why is IPv6 important for large-scale IoT deployments beyond its larger address space?

2. What are the principal functions of 6LoWPAN?

3. How does RPL use rank and parent selection?

4. Distinguish clock offset from clock drift.

5. What is the difference between MQTT and CoAP communication models?

Long Answer Questions

1. Explain the architecture and limitations of RPL in a low-power and lossy network.

2. Compare MQTT, CoAP, AMQP, DDS, HTTP, and WebSockets using communication model, resource demands, and application suitability.

3. Discuss how gateways, SDN, and network virtualization affect IoT scalability and security.

4. Explain why transport acknowledgements do not necessarily guarantee successful physical action in an IoT system.

5. Develop a protocol-selection framework for a large industrial IoT deployment.

Analytical / Application Questions

1. A battery-powered agricultural sensor sends small measurements every fifteen minutes across an unreliable mesh and must operate for several years. Which networking and application-layer choices would you evaluate, and why?

2. A mobile robot requires bounded latency, coordinated time, and dependable peer-to-peer data exchange. Compare DDS with MQTT and HTTP for this scenario, identifying the conditions under which each might be selected.

3. Design an architecture for an intermittently connected monitoring system in which routine data may be delayed but emergency commands expire quickly. Specify addressing, buffering, messaging, security, and measurement decisions.

22. Multiple Choice Questions with Answers

Question 1

Which feature most directly enables large-scale unique addressing of IoT interfaces?

A. IPv6’s 128-bit address space

B. MQTT retained messages

C. RPL’s Trickle mechanism

D. WebSocket persistence

Correct Answer: A. IPv6’s 128-bit address space

Question 2

What is a principal purpose of 6LoWPAN?

A. Replacing all application-layer protocols

B. Adapting IPv6 packets to constrained wireless links

C. Providing enterprise message transactions

D. Synchronizing clocks globally

Correct Answer: B. Adapting IPv6 packets to constrained wireless links

Question 3

In RPL, rank primarily helps nodes to do what?

A. Compress application payloads

B. Encrypt routing messages

C. Represent relative position and help avoid loops

D. Assign human-readable device names

Correct Answer: C. Represent relative position and help avoid loops

Question 4

Which protocol is most strongly associated with broker-based publish/subscribe telemetry?

A. MQTT

B. CoAP

C. HTTP

D. DDS

Correct Answer: A. MQTT

Question 5

A constrained device needs lightweight REST-style resource access over UDP. Which protocol is the most appropriate initial candidate?

A. AMQP

B. CoAP

C. WebSockets

D. HTTP/1.1

Correct Answer: B. CoAP

Question 6

Why should an MQTT consumer be designed to tolerate duplicates when at-least-once delivery is used?

A. The broker deliberately removes message identifiers

B. Retransmission can cause the same message to arrive more than once

C. IPv6 prohibits message ordering

D. RPL always duplicates application packets

Correct Answer: B. Retransmission can cause the same message to arrive more than once

Question 7

Which protocol is especially suited to distributed real-time systems requiring rich deadline, durability, and liveliness policies?

A. DDS

B. CoAP

C. DNS

D. 6LoWPAN

Correct Answer: A. DDS

Question 8

What is a major risk of assuming that a transport acknowledgement proves an actuator has completed an action?

A. Acknowledgements always imply encryption failure

B. Transport success does not establish physical execution or current validity

C. IPv6 addresses cannot identify interfaces

D. Gateways cannot buffer commands

Correct Answer: B. Transport success does not establish physical execution or current validity

Question 9

Which measurement is particularly important for an intermittently connected IoT system?

A. Only average packet size

B. Data age and recovery time after disconnection

C. Number of web browser tabs

D. Screen resolution of the gateway

Correct Answer: B. Data age and recovery time after disconnection

Question 10

What is a central benefit of SDN in IoT environments?

A. It eliminates the need for authentication

B. It enables programmable policy and segmentation across network resources

C. It guarantees wireless links never fail

D. It converts every device into a cloud server

Correct Answer: B. It enables programmable policy and segmentation across network resources