Internet and Messaging Protocols

Introduction

The Internet of Things (IoT) depends on communication protocols that allow constrained sensors, actuators, gateways, cloud services and human applications to exchange information. No single protocol is optimal for every IoT deployment. A battery-powered temperature sensor may use IEEE 802.15.4, 6LoWPAN, IPv6 and CoAP, whereas an industrial gateway may use Ethernet, IPv6, TCP and MQTT over TLS. Protocol selection therefore requires analysis of addressing, packet overhead, reliability, latency, energy consumption, interoperability, security and quality of service (QoS).

This chapter examines the principal Internet and messaging protocols used in IoT: IPv6, 6LoWPAN, TCP, UDP, HTTP, MQTT and CoAP. It also introduces service discovery, routing and protocol-selection methods. A central principle is that protocols are layered and encapsulated, not simply placed in one universal sequence. CoAP commonly operates over UDP, while standard MQTT normally operates over TCP. Other MQTT transports exist, but they should be treated as explicit alternatives rather than assumed defaults.

Learning Objectives

After studying this chapter, you should be able to:

• explain IPv6 addressing, autoconfiguration and neighbor mechanisms;
• describe how 6LoWPAN adapts IPv6 to low-power wireless networks;
• compare TCP and UDP in terms of reliability, overhead and latency;
• distinguish HTTP, MQTT and CoAP by communication model and operating environment;
• explain discovery and routing mechanisms used in constrained networks;
• evaluate QoS, interoperability and security trade-offs;
• select an appropriate protocol stack for an IoT application.

1. Protocol Layering and Encapsulation

IoT communication is organized into layers. At the link layer, technologies such as IEEE 802.15.4, Wi-Fi, Ethernet, Bluetooth Low Energy and cellular radio transmit frames. The network layer provides global or internetwork addressing, principally through IP. The transport layer provides end-to-end delivery services, commonly TCP or UDP. The application layer defines message meaning and interaction patterns, such as HTTP, MQTT or CoAP.

Encapsulation means that an application message is placed inside a transport segment or datagram, which is placed inside an IP packet, which is finally placed inside a link-layer frame. Each layer adds its own header. At the receiver, headers are removed in reverse order. Protocols at the same conceptual layer are alternatives; they are not necessarily sequential stages.

Figure: Correctly separated and encapsulated protocol-stack alternatives. Standard MQTT is normally carried over TCP; CoAP is commonly carried over UDP.

2. IPv6 for IoT

IPv6 uses 128-bit addresses, written as eight groups of hexadecimal digits. Consecutive zero groups may be compressed once using ::; for example, 2001:db8:1:0:0:0:0:25 can be written as 2001:db8:1::25. The address space contains 2¹²⁸ possible bit patterns, although practical allocation is governed by addressing policy and reserved ranges.

An IPv6 unicast address generally contains a routing prefix and an interface identifier. A common conceptual division is a 64-bit subnet prefix and a 64-bit interface identifier, although the exact design depends on the addressing architecture and deployment. Global unicast addresses support end-to-end routing. Link-local addresses begin with fe80::/10 and are valid only on the local link. Multicast addresses begin with ff00::/8; IPv6 has no broadcast address.

Address configuration

IPv6 hosts may use:

• SLAAC (Stateless Address Autoconfiguration): routers advertise prefixes and hosts construct addresses, often using a random or stable interface identifier.
• DHCPv6: a stateful service may allocate addresses and configuration parameters.
• Static configuration: useful for selected infrastructure devices, but less flexible at scale.

Duplicate Address Detection (DAD) helps determine whether an address is already in use. Neighbor Discovery Protocol (NDP), carried through ICMPv6, performs functions that include router discovery, neighbor resolution and reachability detection. Blocking ICMPv6 indiscriminately can therefore break essential network operation.

IPv6 also supports extension headers, multicast listener functions and network-layer security through IPsec specifications. In practice, application-layer security such as TLS or DTLS is frequently used because it can provide identity and authorization at the service boundary.

3. 6LoWPAN Adaptation

Low-power wireless personal-area networks have small frames, low data rates, sleeping nodes, lossy links and limited memory. IEEE 802.15.4 permits a maximum MAC frame size of 127 octets. After link-layer security and other headers, the payload available to upper layers can be considerably smaller. A normal IPv6 minimum link MTU is 1280 octets, so direct transmission of an IPv6 packet is often impossible.

6LoWPAN is an adaptation technology that enables IPv6 packets to operate over constrained IEEE 802.15.4 networks. Its main functions are:

1. Header compression: repeated or inferable fields in IPv6 and UDP headers are omitted or encoded compactly.
2. Fragmentation and reassembly: packets larger than the link-layer frame capacity are divided and reconstructed.
3. Mesh delivery support: forwarding information may be carried for certain link-layer mesh arrangements, although modern deployments often rely on IP routing at the adaptation boundary.
4. Addressing integration: link-layer and IPv6 identifiers can be related without requiring every application to understand the radio technology.

Fragmentation increases risk: if one fragment is lost, the complete datagram may be unusable. It also consumes buffer memory and energy. Designers should therefore reduce application payload size, avoid unnecessary headers and choose suitable link-layer frame sizes and retransmission policies.

6LoWPAN is not a routing protocol by itself. In routed low-power and lossy networks, RPL is commonly used above the link/adaptation environment. A border router connects the constrained IPv6 network to other IP networks and may perform forwarding, security enforcement, device management or application protocol translation.

4. TCP and UDP

TCP

TCP is a connection-oriented, byte-stream transport protocol. Its principal mechanisms include a three-way handshake, sequence numbers, acknowledgements, retransmission, flow control and congestion control. TCP provides ordered, reliable delivery to an application, but it does not preserve application message boundaries. An application must define framing, for example by using a length field or delimiter.

TCP is appropriate when reliable ordered transfer is more important than minimum latency or memory use. MQTT and HTTP commonly use TCP. Connection setup, state maintenance and retransmissions can be expensive for sleeping sensors, although persistent connections and modern connection-management strategies reduce repeated setup costs.

UDP

UDP is connectionless and datagram-oriented. It preserves message boundaries but does not itself guarantee delivery, ordering, duplicate suppression or congestion control. Its header is only 8 octets, compared with a minimum 20-octet TCP header without options. Applications can add acknowledgements, sequence numbers, retransmission and rate control when required.

UDP is useful for short exchanges, multicast, discovery and constrained devices. CoAP commonly uses UDP and adds message identifiers, request/response tokens and optional reliability through confirmable messages. UDP is not automatically faster or more reliable; its benefit is lower transport complexity and the ability to design application-specific behavior.

Comparative selection

5. HTTP and Web Interoperability

HTTP uses a request-response model in which a client sends a method such as GET, POST, PUT or DELETE and a server returns a status code, headers and an optional representation. HTTP is highly interoperable and integrates naturally with browsers, proxies, caches, REST APIs and cloud platforms.

Its disadvantages in constrained IoT include verbose headers, relatively large messages, TCP connection overhead and a client-driven interaction model. HTTP is therefore often used by gateways and application servers rather than the smallest battery-powered nodes. HTTP over TLS, commonly called HTTPS, protects confidentiality and integrity, provided certificates, hostname verification and trust configuration are correctly managed.

REST design commonly treats device data as resources. For example, /devices/17/temperature might support GET, while a command resource might accept POST. Idempotence matters: repeating a PUT should produce the same intended resource state, while repeating a command POST may cause repeated effects unless an application identifier prevents duplication.

6. MQTT

MQTT is a lightweight publish-subscribe messaging protocol. Clients connect to a broker and publish messages to topics. Other clients subscribe to topic filters and receive matching publications. Publishers and subscribers are decoupled in time, location and identity.

A typical arrangement is:

publisher → MQTT broker → subscriber

Standard MQTT normally uses TCP; MQTT can also be secured with TLS. MQTT-SN is a related protocol designed for sensor networks and may use non-TCP transports, but it should not be confused with ordinary MQTT over TCP.

Important MQTT concepts include:

• Topic: hierarchical UTF-8 name such as factory/line1/motor7/vibration.
• Topic filter: subscription pattern; + matches one level and # matches multiple levels at the end.
• Client identifier: identifies a connection to the broker.
• Retained message: the broker stores the most recent publication for a topic and sends it to a new subscriber.
• Last Will and Testament: a broker-published message can announce unexpected disconnection.
• Persistent session features: subscriptions and undelivered messages may be retained according to protocol version and configuration.

MQTT QoS levels are:

• QoS 0: at most once; no protocol-level delivery confirmation.
• QoS 1: at least once; duplicates are possible.
• QoS 2: exactly once at the MQTT protocol transaction level; it requires more exchanges and state.

“Exactly once” does not automatically mean exactly-once physical actuation. A subscriber must still design command processing to be idempotent or use application-level deduplication. MQTT 5 adds features such as reason codes, message expiry, user properties and more expressive subscription behavior.

7. CoAP

The Constrained Application Protocol (CoAP) is designed for constrained nodes and low-power lossy networks. It follows REST principles and supports methods such as GET, POST, PUT and DELETE. Its compact binary format is more suitable than ordinary HTTP for small devices.

CoAP commonly operates over UDP and can use DTLS for transport security. Confirmable messages require an acknowledgement; non-confirmable messages reduce overhead when occasional loss is acceptable. CoAP also defines duplicate detection and retransmission behavior for confirmable exchanges. A response may be sent separately when processing takes longer than the initial exchange permits.

CoAP supports observation, allowing a client to register interest in a resource and receive notifications when its state changes. This reduces repeated polling. CoAP resources can be discovered through the well-known core resource directory, conventionally at /.well-known/core, using link-format metadata. Discovery may also be supported by a resource directory or application-specific mechanisms.

CoAP can be proxied to HTTP. A proxy translates methods, representations and response semantics while preserving the resource-oriented model. Translation is not always perfect: differences in caching, security identity, timing and error semantics must be addressed explicitly.

8. Discovery and Routing

Service discovery

Discovery answers questions such as: Which devices exist? Which resources do they provide? What data formats and methods are supported? Mechanisms include:

• DNS and DNS-SD for conventional IP networks;
• multicast DNS in local networks;
• CoRE Link Format and resource directories for CoAP;
• MQTT topic conventions and broker metadata;
• manufacturer registries or cloud device directories.

Discovery should expose capability, version, units, access rights and expiry information. An unsecured discovery service can reveal device identities and operational details, so access control and privacy need consideration.

Routing in constrained networks

RPL is designed for IPv6 routing in low-power and lossy networks. Nodes form a Destination-Oriented Directed Acyclic Graph (DODAG) rooted at a border router. An objective function selects preferred parents using metrics such as hop count, expected transmissions, latency or energy. RPL supports upward routes toward a root and may support downward routes, depending on mode and state-management approach.

Routing metrics involve trade-offs. Minimum hop count may select unreliable links. A reliability-aware metric may increase path length. Energy-aware routing can extend network life but may concentrate traffic on particular nodes. Routing loops, stale parent information and control-message overhead are practical concerns.

9. Quality of Service and Performance

IoT QoS is multidimensional. Relevant measures include delivery probability, latency, jitter, throughput, energy per message, availability and freshness. A protocol’s named QoS level does not guarantee an end-to-end service level across radio, gateway, broker and cloud components.

For a simple message, transmission time can be approximated by:

where L is the number of transmitted bytes, R is the bit rate in bits per second, and t_tx is seconds. This is only serialization time; propagation, processing, contention, retransmission and sleep delays are excluded.

For example, a 100-byte payload sent at 250 kbit/s has:

The actual end-to-end latency may be much larger because headers, fragmentation, channel access, routing and acknowledgements add delay. If a packet is sent over n independent links with success probabilities p₁, p₂, ..., p_n, and no link-layer recovery is assumed, the one-attempt end-to-end success probability is:

For three links with probabilities 0.95, 0.90 and 0.98:

Thus the one-attempt success probability is 83.79 percent. This calculation assumes independence and excludes retransmissions; real wireless links may violate both assumptions.

QoS design should therefore specify measurable requirements, such as maximum acceptable latency, minimum delivery probability, tolerated duplication and acceptable energy cost. MQTT QoS, CoAP confirmability and link-layer retries should be evaluated together rather than treated as interchangeable guarantees.

10. Security, Governance and Interoperability

Security must be designed across layers. Important controls include:

• mutual authentication of devices and services;
• authorization by device, user, topic or resource;
• encryption in transit using TLS for TCP protocols and DTLS for UDP protocols;
• secure key storage, credential rotation and certificate lifecycle management;
• replay protection, sequence validation and freshness checks;
• secure boot, signed firmware and vulnerability management;
• logging, monitoring and incident response.

A broker ACL should prevent a temperature sensor from publishing commands to unrelated actuators. A CoAP resource should similarly enforce authorization rather than relying only on an obscure URI. Sensitive telemetry may reveal occupancy, production rates or personal behavior, creating privacy obligations under applicable data-protection law.

Interoperability requires more than using IP. Devices must agree on data models, units, encodings, timestamps, error semantics and versioning. JSON is broadly accessible but verbose; CBOR is compact and common in constrained environments. Designers should specify whether a temperature is Celsius or Fahrenheit, whether timestamps are UTC, and how missing or stale values are represented.

11. Protocol Selection Framework

A practical selection process is:

1. Characterize the device and link: memory, battery, radio MTU, bandwidth, loss rate and sleep behavior.
2. Define interaction: request-response, event publication, command delivery, streaming or file transfer.
3. Define reliability: acceptable loss, duplication, ordering and recovery time.
4. Select transport: TCP for established reliable streams; UDP when compact datagrams, multicast or application-specific reliability are valuable.
5. Select application protocol: CoAP for constrained REST; MQTT for brokered event distribution; HTTP for broad web integration.
6. Specify security and identity: TLS/DTLS, credentials, authorization and lifecycle management.
7. Test realistic failure modes: packet loss, broker failure, clock error, duplicate commands, reboot and network partition.

These are starting points, not automatic answers. A gateway may translate CoAP sensor resources into MQTT topics or HTTP APIs, but translation introduces semantic, security and operational boundaries.

12. Applied Case: Smart Cold-Chain Monitoring

Background

The following is an illustrative case. A logistics company monitors temperature in refrigerated containers. Battery-powered sensors operate over a low-power wireless mesh, while gateways have cellular or Ethernet connectivity to a cloud platform.

Problem

The system must report temperature periodically, alert on threshold violations, continue operating during intermittent connectivity and prevent unauthorized users from issuing commands. Sensors have limited energy and cannot maintain large numbers of TCP connections.

Analysis

Sensor traffic is small and periodic. Local resource access is naturally request-response, while event alerts need distribution to multiple cloud consumers. The wireless segment has a small MTU and occasional loss. The cloud requires persistent ingestion and integration with dashboards and analytics.

Approach

Sensors use IPv6 over 6LoWPAN with RPL routing. CoAP over UDP provides local resource access and observation. Confirmable CoAP messages are used for alarm transitions, while non-confirmable messages may be used for frequent readings when occasional loss is acceptable. The gateway acts as a border router and protocol bridge. It publishes normalized readings to an MQTT broker over TCP with TLS. Topic authorization restricts each gateway to its assigned container. The cloud exposes an HTTPS API for enterprise users.

The data model records value, unit, timestamp, sensor identity, quality indicator and calibration version. Alarm processing uses an event identifier so that repeated delivery does not create duplicate incident records. Gateway buffering allows store-and-forward operation during a cellular outage. Certificates are provisioned securely and rotated before expiry.

Outcome

The design separates constrained local communication from reliable cloud distribution. CoAP reduces local message overhead, MQTT decouples cloud consumers, and HTTPS supports enterprise interoperability. Testing must still measure battery life, fragment loss, alarm latency, broker outage behavior and recovery after gateway reboot.

Learning points

• Protocol choice follows interaction and constraints, not popularity.
• Reliability must be defined end to end.
• A gateway can bridge protocols, but it must preserve identity, units, timestamps and authorization.
• Duplicate-resistant application logic is necessary even when transport or messaging QoS is enabled.

13. Challenges and Contemporary Developments

IoT deployments increasingly combine IPv6 with Wi-Fi, Thread, cellular IoT, Ethernet and satellite links. Matter demonstrates the value of common application semantics across different lower-layer networks, while edge computing reduces latency and bandwidth use by processing data near devices. MQTT 5 improves message metadata and error reporting; CoAP continues to support constrained REST and observation patterns.

Emerging deployments must address software supply-chain risk, long device lifetimes, post-quantum migration planning, digital twins and automated fleet management. Artificial intelligence may classify anomalies at the edge, but the underlying telemetry still requires accurate timestamps, reliable identity and explicit data governance. AI does not remove the need for protocol engineering; poor-quality or unauthenticated data can produce unsafe decisions.

Chapter Summary

IPv6 supplies scalable addressing, autoconfiguration and end-to-end internetworking for IoT. 6LoWPAN adapts IPv6 to small, low-power IEEE 802.15.4 frames through compression and fragmentation, while RPL supports routing in low-power and lossy networks. TCP provides reliable ordered byte streams and commonly carries MQTT and HTTP. UDP provides datagrams with lower transport overhead and commonly carries CoAP, although reliability must then be designed at another layer when required.

HTTP offers strong web interoperability. MQTT uses brokered publish-subscribe communication and provides selectable delivery semantics through QoS levels. CoAP provides compact RESTful communication, discovery and observation for constrained nodes. Effective design evaluates latency, loss, energy, security, interoperability, data semantics and failure recovery together. The correct protocol stack is therefore an engineering decision based on requirements, not a fixed universal sequence.

Key Terms

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

SLAAC: Stateless Address Autoconfiguration for IPv6 hosts.

NDP: ICMPv6-based Neighbor Discovery Protocol.

6LoWPAN: Adaptation technology for IPv6 over low-power wireless networks.

RPL: Routing Protocol for Low-Power and Lossy Networks.

TCP: Reliable, ordered, connection-oriented transport protocol.

UDP: Connectionless datagram transport protocol.

HTTP: Web request-response application protocol.

MQTT: Brokered publish-subscribe messaging protocol.

Broker: MQTT server that receives, filters and distributes publications.

Topic: Hierarchical name used to classify MQTT messages.

CoAP: Constrained Application Protocol for RESTful IoT communication.

Confirmable message: CoAP message requiring acknowledgement and allowing retransmission.

Service discovery: Process of identifying available devices, resources and capabilities.

Encapsulation: Placement of one protocol data unit inside another.

QoS: Quality-of-service characteristics such as reliability, latency and freshness.

DTLS: Datagram Transport Layer Security for UDP-based communication.

TLS: Transport Layer Security commonly used with TCP protocols.

Idempotence: Property whereby repeating an operation has the same intended effect as performing it once.

Review Questions

Short Answer Questions

1. What is the purpose of 6LoWPAN in an IoT network?
2. How do TCP and UDP differ in their delivery guarantees?
3. What role does an MQTT broker perform?
4. What is the difference between an IPv6 link-local address and a global unicast address?
5. Why can IPv6 fragmentation be costly in a low-power network?

Long Answer Questions

1. Explain IPv6 addressing, SLAAC, NDP and the role of ICMPv6 in IoT operation.
2. Compare MQTT and CoAP in terms of communication model, transport, reliability and constrained-device suitability.
3. Describe RPL operation and analyze the trade-off between hop count, reliability and energy.
4. Explain how HTTP, CoAP and MQTT can be integrated through an IoT gateway.
5. Develop a security architecture for a multi-year battery-powered sensor deployment.

Analytical / Application Questions

1. A sensor network has small MTU frames, intermittent loss and periodic telemetry. Select a protocol stack and justify each layer, including security and discovery.
2. A system requires cloud fan-out, retained latest state and offline buffering. Compare MQTT and CoAP and recommend an architecture.
3. Three wireless links have independent one-attempt success probabilities of 0.96, 0.92 and 0.95. Calculate the end-to-end one-attempt success probability and explain why retransmissions could change the result.

Multiple Choice Questions with Answers

Question 1

Which transport protocol is normally used by standard MQTT?

A. TCP

B. UDP

C. ICMPv6

D. RPL

Correct Answer: A. TCP

Question 2

What is a principal function of 6LoWPAN?

A. Replacing IPv6 with an application protocol

B. Compressing and adapting IPv6 for low-power wireless links

C. Providing cloud data analytics

D. Managing MQTT topic permissions

Correct Answer: B. Compressing and adapting IPv6 for low-power wireless links

Question 3

Which statement about UDP is correct?

A. It guarantees ordered delivery

B. It is a byte-stream protocol

C. It preserves datagram boundaries but provides no default reliability guarantee

D. It always performs a three-way handshake

Correct Answer: C. It preserves datagram boundaries but provides no default reliability guarantee

Question 4

Which MQTT QoS level permits duplicate delivery?

A. QoS 0 only

B. QoS 1

C. No MQTT QoS level

D. TLS QoS

Correct Answer: B. QoS 1

Question 5

Which protocol is designed for compact RESTful communication in constrained devices?

A. CoAP

B. SMTP

C. FTP

D. RPL

Correct Answer: A. CoAP

Question 6

What is the main role of an MQTT broker?

A. Assigning IPv6 prefixes only

B. Routing radio frames at the physical layer

C. Receiving publications and distributing them to matching subscribers

D. Fragmenting every IPv6 packet

Correct Answer: C. Receiving publications and distributing them to matching subscribers

Question 7

What is the one-attempt success probability across independent links with probabilities 0.95, 0.90 and 0.98?

A. 0.8379

B. 0.9500

C. 0.9800

D. 2.8300

Correct Answer: A. 0.8379

Question 8

Which IPv6 address type is restricted to the local link?

A. Global unicast

B. Link-local

C. Anycast only

D. Documentation address only

Correct Answer: B. Link-local

Question 9

A 100-byte transmission at 250000 bits per second has a serialization time of:

A. 0.32 ms

B. 3.2 ms

C. 32 ms

D. 320 ms

Correct Answer: B. 3.2 ms

Question 10

Which protocol commonly supports CoAP resource discovery through a well-known resource?

A. CoRE Link Format at /.well-known/core

B. MQTT retained topics only

C. TCP three-way handshake

D. IPv4 ARP broadcast

Correct Answer: A. CoRE Link Format at /.well-known/core