Internet and IoT Protocols

Introduction

The value of an Internet of Things (IoT) system depends not only on sensors, processors, and communication hardware, but also on the protocols that allow heterogeneous devices to exchange information reliably and securely. An IoT protocol defines rules for addressing, formatting, transmitting, routing, authenticating, protecting, and interpreting data. Protocol choice affects energy consumption, latency, scalability, interoperability, reliability, maintainability, and cost.

IoT communication is normally layered. A sensing node may use IEEE 802.15.4 or Bluetooth Low Energy at the local link, IPv6 for addressing, 6LoWPAN for adaptation over constrained links, UDP or TCP for transport, and CoAP or MQTT at the application layer. A cellular or Wi-Fi device may use a different lower-layer technology while still using IP and the same application protocol. This separation makes system design modular, but it also introduces interactions between layers that must be analysed carefully.

At postgraduate level, protocol selection should therefore be treated as an engineering design problem rather than as a catalogue of standards. The appropriate protocol depends on the application’s traffic pattern, resource constraints, threat model, timing requirements, deployment scale, and lifecycle expectations.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the roles of Internet and IoT protocol layers.
2. Compare IPv4, IPv6, 6LoWPAN, TCP, UDP, QUIC, HTTP, CoAP, MQTT, AMQP, and WebSocket.
3. Analyse protocol choice using latency, reliability, energy, security, and scalability criteria.
4. Explain addressing, routing, discovery, authentication, encryption, and quality-of-service mechanisms.
5. Design a secure protocol stack for a representative IoT application.
6. Evaluate contemporary developments such as IPv6-only networks, LPWAN, edge computing, and Matter.

1. Protocol Architecture for IoT

A protocol stack divides communication into functional layers. The OSI model is a useful reference, although practical Internet systems commonly follow the TCP/IP architecture.

Encapsulation is central to layered networking. An application message is placed in a transport segment or datagram; this is placed in an IP packet; the packet is then placed in a link-layer frame. At the receiver, the reverse process occurs. Each layer adds headers, so a small payload can experience significant overhead in constrained networks.

A protocol stack must also be distinguished from a communication pattern. Request–response communication is suitable for querying a device. Publish–subscribe is useful when many consumers need selected event streams. Streaming is appropriate for continuous media or measurements. Command–response, store-and-forward, and event-triggered messaging are other common patterns.

2. Internet Protocol Foundations

2.1 IPv4 and IPv6

IPv4 uses 32-bit addresses, conventionally written as four decimal octets. IPv6 uses 128-bit addresses and provides a vastly larger address space, hierarchical addressing, stateless address autoconfiguration, multicast support, and features designed for large-scale networking. IoT deployments benefit from globally structured addressing, although private addressing and gateways remain common.

IPv6 addresses are written in hexadecimal groups separated by colons. Consecutive zero groups may be compressed once using a double colon. Important address categories include:

• Unicast: identifies one interface.
• Multicast: identifies a group of interfaces.
• Anycast: identifies a service available at one of several interfaces.
• Link-local: valid only on the local link and commonly beginning with fe80::/10.
• Global unicast: routable in the broader Internet.

IPv6 Neighbor Discovery uses ICMPv6 messages for router discovery, address resolution, and reachability functions. Blocking ICMPv6 indiscriminately can therefore break essential IPv6 operation. Security controls should distinguish legitimate control traffic from abuse.

2.2 6LoWPAN and SCHC

Many low-power wireless links have small frame sizes, low data rates, lossy channels, and constrained memory. 6LoWPAN enables IPv6 over IEEE 802.15.4 by providing header compression, fragmentation and reassembly, and adaptation mechanisms. Header compression is especially important because an uncompressed IPv6 header is 40 bytes, which can consume much of a small link-layer frame.

6LoWPAN does not itself define a complete application protocol. It makes IP communication feasible over constrained links. Routing in low-power and lossy networks is commonly supported by RPL, the IPv6 Routing Protocol for Low-Power and Lossy Networks. RPL forms a directed acyclic graph rooted at a border router and uses an objective function to select preferred parents according to metrics such as hop count, expected transmission count, or energy.

Static fragmentation and header compression may still be insufficient for extremely small or intermittent links. SCHC, or Static Context Header Compression, uses shared static rules to compress headers and fragment packets for technologies such as LPWAN. The main design trade-off is efficiency versus flexibility: static contexts achieve high compression but require carefully coordinated configuration.

2.3 Routing and Discovery

Routing determines the path through which packets travel. In conventional IP networks, routing protocols exchange reachability information. In IoT networks, routing must additionally consider battery energy, link asymmetry, interference, memory, mobility, and sleeping schedules.

Service discovery allows a device or application to identify available services without manually configuring every endpoint. DNS and DNS Service Discovery are widely used on IP networks. Constrained environments may use CoAP Resource Discovery, in which a device exposes metadata about resources, their paths, content formats, and observable properties.

Discovery creates security concerns. Announcing a device, service, or location may reveal sensitive information. A secure design limits disclosure, authenticates responses where necessary, and separates public device capabilities from privileged control operations.

3. Transport Protocols

3.1 UDP

UDP is connectionless and provides datagrams without built-in retransmission, ordering, congestion control, or delivery guarantees. Its eight-byte header is smaller than TCP’s minimum 20-byte header. UDP is useful when applications need low overhead, multicast, rapid exchange, or application-specific reliability.

UDP does not mean that communication is unreliable in every practical system. CoAP, for example, can add confirmable messages, retransmission, duplicate detection, and response matching. However, application-layer reliability must be designed carefully to avoid synchronized retries and congestion collapse.

3.2 TCP

TCP provides a reliable, ordered byte stream with connection establishment, flow control, retransmission, and congestion control. It is appropriate for applications such as HTTP and MQTT where ordered delivery and established ecosystem support are valuable. Its costs include connection state, handshake delay, buffering, and energy consumed by retransmission and keep-alive traffic.

TCP reliability guarantees delivery to the receiving transport endpoint under continuing network and endpoint operation; it does not guarantee that an application has processed the data, nor does it guarantee bounded delay.

3.3 QUIC

QUIC operates over UDP but provides encrypted, multiplexed streams, congestion control, and connection migration. It normally uses TLS 1.3 for handshake security. QUIC can reduce connection establishment delay and avoid some head-of-line blocking between independent streams. Its implementation complexity and memory requirements may be unsuitable for very small embedded nodes, but it is increasingly relevant to gateways, edge services, and capable devices.

3.4 Transport Selection

A useful conceptual latency model is:

Here, T_total is total application-perceived delay; T_processing is endpoint processing time; T_queue is waiting time in buffers; T_transmission is the time to place bits on the medium; T_propagation is signal travel time; and T_retransmission represents delay caused by losses and recovery. The expression is an engineering decomposition, not an exact universal law. In wireless IoT systems, queuing and retransmission are often more important than propagation delay.

For a packet of L bits transmitted at rate R bits/s, the serialization time is:

This excludes protocol processing, contention, propagation, and retransmission. For example, a 1,600-bit message on a 250 kbit/s link requires 6.4 ms of raw serialization time, before medium-access overhead and possible retries.

4. IoT Application Protocols

4.1 HTTP and REST

HTTP uses request–response communication and is the dominant protocol for web services. RESTful design represents resources using uniform identifiers and standard methods such as GET, POST, PUT, and DELETE. HTTP integrates naturally with enterprise software, proxies, cloud platforms, and web security tools.

Its disadvantages for constrained devices include comparatively large headers, connection-management overhead, and a communication pattern that is inefficient for frequent small events. HTTP is often most appropriate between gateways, edge services, and cloud applications rather than between extremely constrained sensors.

4.2 CoAP

The Constrained Application Protocol is designed for constrained nodes and networks. It follows a REST-like resource model but usually uses UDP. CoAP defines methods such as GET, POST, PUT, and DELETE, supports confirmable and non-confirmable messages, and can use block-wise transfer for larger representations. Observe allows a client to register interest in changes to a resource, reducing repeated polling.

CoAP can be secured with DTLS when used over UDP. Object Security for Constrained RESTful Environments provides protection at the message or object level and can be useful when messages pass through intermediaries. CoAP is well suited to sensor resources, actuator commands, local networks, and machine-to-machine interaction.

4.3 MQTT

MQTT is a lightweight publish–subscribe protocol. Clients connect to a broker and publish messages to topics. Other clients subscribe to topics and receive matching messages. This decouples publishers from subscribers in space, time, and often implementation.

MQTT quality of service levels are:

• QoS 0: at most once; no protocol-level delivery assurance.
• QoS 1: at least once; duplicates are possible.
• QoS 2: exactly once at the MQTT protocol exchange level; it has greater overhead.

The phrase “exactly once” must be interpreted carefully. It does not automatically guarantee that a physical actuator performs an operation only once. Application commands should be idempotent or carry unique operation identifiers so that duplicate delivery or client retry cannot produce unsafe repeated effects.

MQTT retained messages allow a broker to store the latest value for a topic. Last Will and Testament messages can notify subscribers when a client connection ends unexpectedly. MQTT brokers also provide access-control points, but a broker is not automatically secure: authentication, authorization, encryption, topic design, rate limiting, and monitoring remain necessary.

4.4 AMQP, WebSocket, and DDS

AMQP is designed for reliable enterprise messaging and supports exchanges, queues, routing, acknowledgements, and transactional patterns. It is powerful for backend integration but commonly heavier than MQTT for tiny nodes.

WebSocket begins as an HTTP-based handshake and then provides persistent, bidirectional communication. It is useful for browser dashboards, interactive control panels, and gateway applications.

Data Distribution Service (DDS) uses a data-centric publish–subscribe model with rich quality-of-service policies. It is relevant to robotics, industrial control, and real-time systems where deadline, liveliness, durability, and reliability policies must be expressed explicitly. Its configuration and resource demands may exceed those of simpler sensor networks.

4.5 Comparison of Application Protocols

5. Wireless and Wide-Area IoT Protocols

Wi-Fi offers high throughput and mature IP support but can consume substantial energy. Bluetooth Low Energy is suited to short-range, low-power personal-area applications and uses advertising and connection mechanisms. IEEE 802.15.4 underlies several mesh technologies, including Thread and Zigbee-related ecosystems.

Thread is an IPv6-based, low-power mesh protocol built over IEEE 802.15.4. It supports self-healing networks and IP connectivity, while application interoperability may be supplied by Matter. Matter is an application-layer standard intended to improve interoperability among smart-home devices over transports such as Wi-Fi, Thread, and Ethernet; Bluetooth Low Energy is commonly used for commissioning.

LPWAN technologies address long range and low energy rather than high throughput. LoRaWAN uses a star-of-stars architecture with gateways and network servers. It is effective for small, infrequent messages but has duty-cycle, payload, downlink, and latency constraints that depend on regional regulations and configuration. NB-IoT and LTE-M use cellular infrastructure. They offer operator-managed coverage and stronger mobility or service integration than many unlicensed systems, but subscription cost, modem energy, and network availability must be considered.

A protocol comparison should use application metrics rather than nominal range alone. Important measures include payload efficiency, energy per delivered bit, coverage probability, uplink/downlink asymmetry, mobility support, provisioning method, and security-update capability.

6. Security Protocols and Trust Architecture

IoT security is a systems property. A secure transport connection cannot compensate for weak device identity, exposed debug ports, unsafe firmware, or excessive cloud privileges.

6.1 Security Objectives

The principal objectives are confidentiality, integrity, authentication, authorization, availability, accountability, and privacy. Threats include eavesdropping, replay, spoofing, broker compromise, denial of service, malicious firmware, credential extraction, traffic analysis, and unsafe physical access.

TLS protects TCP-based protocols such as HTTPS and MQTT. DTLS provides analogous protection for datagram-oriented communication. TLS 1.3 reduces obsolete cryptographic options and normally provides forward secrecy when ephemeral key exchange is used. Cryptographic protection must be combined with certificate or pre-shared-key lifecycle management.

A typical device trust chain is:

1. A unique device identity is provisioned in protected storage.
2. The device authenticates to a gateway, broker, or service.
3. Authorization maps the identity to permitted resources and commands.
4. Messages are encrypted and integrity-protected in transit.
5. Firmware updates are signed and verified before installation.
6. Keys are rotated, revoked, and retired according to lifecycle policy.

6.2 Authentication and Authorization

Authentication answers “who or what is communicating?” Authorization answers “what is it allowed to do?” These must not be conflated. A sensor may be authenticated but authorized only to publish temperature readings, not to issue actuator commands.

Role-based access control assigns privileges to roles, while attribute-based access control evaluates attributes such as device type, location, time, and operational state. Least privilege, separation of duties, secure defaults, and fail-safe handling are especially important for actuators.

Replay protection commonly uses nonces, sequence numbers, timestamps, or freshness windows. A timestamp alone is insufficient if clocks are not trustworthy. Sequence numbers require persistence or careful session management to prevent reuse after reboot.

6.3 Secure Boot and Updates

Secure boot verifies a chain of signed software components before execution. Secure over-the-air update mechanisms must provide authenticity, integrity, version control, rollback protection, recovery from interrupted updates, and key compromise response. Dual-image or A/B update designs can preserve a known-good image while a new image is tested.

7. Engineering Analysis of Protocol Choice

Protocol selection can be expressed as a multi-criteria decision. Candidate protocols should be evaluated against measurable requirements rather than chosen from popularity.

For a device transmitting n messages per hour, each of L bits, the offered payload rate is:

where R_payload is in bits per second if L is in bits. Actual link load is higher because of headers, acknowledgements, retransmissions, encryption records, and beacons.

If a packet delivery attempt succeeds with probability p, and attempts are independent, the expected number of attempts until success is:

This applies to an unlimited-retry geometric model. If the system permits at most k attempts, the probability of success is:

These expressions assume independent attempts and a constant success probability. Real wireless links may exhibit burst losses, so field measurements are necessary.

Worked Example: Telemetry Traffic

An environmental node sends 120 messages per hour. Each application payload is 80 bytes. Ignoring protocol overhead, the payload rate is:

n = 120, L = 80 × 8 = 640 bits.

The average payload rate is therefore approximately 21.3 bit/s. This low average rate does not prove that any particular LPWAN or mesh protocol is suitable. The design must also consider maximum payload size, permitted airtime, burst timing, downlink acknowledgements, loss recovery, battery budget, and regulatory constraints.

If each transmission attempt succeeds with probability 0.9 and three attempts are allowed:

The idealized success probability is 99.9%, assuming independent attempts. Correlated interference could make the actual probability lower.

A practical decision matrix may score candidates from 1 (poor) to 5 (excellent), with weights whose sum is 1. The weighted score is:

where w_i is the importance weight for criterion i, r_i is the candidate rating, and S is the total score. This is a decision aid, not an objective measurement; sensitivity analysis should test whether a small change in weights changes the recommendation.

8. Illustrative Case: Cold-Chain Monitoring

Background

A logistics company needs to monitor temperature, door state, location, and battery condition in refrigerated containers. Sensors operate for several months, connectivity is intermittent, and non-compliance can lead to product loss.

Problem

The system must support low-energy telemetry, alarm delivery, secure device identity, delayed synchronization, and auditability. A design based only on high-throughput Wi-Fi would fail where Wi-Fi coverage is unavailable and would impose unnecessary energy cost.

Analysis

Temperature readings are small and periodic, while alarms are rare but important. The device may cross jurisdictions and networks. Measurement data must be retained during outages, and the system must distinguish a real temperature excursion from a sensor fault or stale data.

Approach

A suitable architecture uses a low-power sensor microcontroller connected to a cellular LTE-M or NB-IoT modem where coverage exists, with local flash storage for store-and-forward operation. MQTT over TLS can connect the gateway or capable modem to a cloud broker. CoAP may be appropriate between constrained local sensors and a gateway. Each device receives a unique credential, and topic authorization limits it to its own telemetry namespace. Alarm messages carry sequence numbers, measurement time, sensing quality, and device status.

The cloud service validates message freshness, detects missing sequence ranges, and stores both raw measurements and derived events. A signed update mechanism permits security patches. A dashboard uses HTTPS or WebSocket toward authorized operators, avoiding direct exposure of field devices.

Outcome

The architecture separates constrained sensing from enterprise integration. Local buffering prevents data loss during temporary outages, while brokered messaging decouples devices from dashboards and analytics. Security controls reduce the impact of stolen credentials, although physical tampering and cellular coverage remain operational risks.

Learning Points

1. The best protocol may differ at each architectural boundary.
2. Reliability must be defined at the application level, not inferred from a transport label.
3. Store-and-forward is essential when connectivity is intermittent.
4. Device identity, updateability, and authorization are as important as packet delivery.
5. Operational metrics should include freshness, missing data, alarm latency, and energy consumption.

9. Limitations, Governance, and Contemporary Directions

Protocol standards do not eliminate vendor lock-in. Proprietary cloud APIs, undocumented broker behaviour, and incompatible data models can make migration difficult even when the network layer is open. Standards compliance should therefore be tested through interoperability exercises and conformance profiles.

Privacy is a major concern because IoT traffic can reveal occupancy, health, industrial activity, or travel patterns. Data minimization, purpose limitation, retention controls, pseudonymization, and access logging should be built into the design. Regulatory obligations vary by sector and jurisdiction, but secure-by-design principles increasingly require vulnerability handling, update support, and transparent risk management.

AI at the edge can reduce bandwidth by classifying events locally, but it introduces model-update, explainability, bias, and adversarial-input concerns. A device should not silently discard raw data when that data is needed for safety investigation or regulatory evidence. Protocol metadata can support AI systems by preserving timestamps, provenance, calibration state, confidence, and quality indicators.

Current development trends include IPv6-only constrained networks, deterministic and time-sensitive industrial communication, satellite IoT, ambient backscatter, digital twins, edge-native messaging, and stronger software supply-chain assurance. The research challenge is not simply to invent another protocol, but to coordinate interoperability, security, energy efficiency, and verifiable performance across highly heterogeneous systems.

Best-Practice Design Checklist

• Begin with application requirements and threat modelling.
• Separate telemetry, commands, alarms, and configuration namespaces.
• Use IPv6 where end-to-end addressing and interoperability are valuable.
• Select UDP or TCP according to application behaviour, not assumed speed.
• Define delivery, freshness, ordering, and duplicate-handling semantics explicitly.
• Authenticate devices individually and apply least-privilege authorization.
• Protect traffic with current TLS or DTLS profiles and managed keys.
• Sign firmware, verify versions, and test recovery from interrupted updates.
• Buffer measurements during outages and expose data-quality indicators.
• Measure energy, latency, loss, jitter, coverage, and operational cost in the field.
• Plan protocol and credential migration before deployment at scale.

Chapter Summary

Internet and IoT protocols form a layered system extending from physical links to application semantics. IPv6 provides scalable addressing, while 6LoWPAN and SCHC adapt IP to constrained links. UDP offers low overhead, TCP offers reliable ordered streams, and QUIC combines secure multiplexing with modern transport features. At the application layer, HTTP supports web integration, CoAP supports constrained RESTful interaction, MQTT supports brokered publish–subscribe telemetry, AMQP supports enterprise messaging, WebSocket supports interactive sessions, and DDS supports rich quality-of-service requirements.

Protocol selection must consider traffic patterns, latency, reliability, energy, overhead, scale, mobility, security, and lifecycle management. TLS and DTLS protect communication, but complete IoT security also requires identity, authorization, secure boot, signed updates, replay protection, privacy controls, and operational monitoring. The cold-chain example demonstrates why different protocols may be appropriate at different architectural boundaries. Effective IoT engineering therefore treats protocols as components of a secure, measurable, and maintainable system rather than as isolated technical choices.

Key Terms

Protocol: A defined set of rules for communication between systems.

Encapsulation: Placement of data from one protocol layer inside the unit of another layer.

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

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

SCHC: Static Context Header Compression and fragmentation for highly constrained links.

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

UDP: Connectionless datagram transport protocol.

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

QUIC: Encrypted, multiplexed transport protocol implemented over UDP.

CoAP: Constrained Application Protocol for resource-oriented machine communication.

MQTT: Lightweight broker-based publish–subscribe messaging protocol.

QoS: Quality of service; policies describing communication properties such as reliability or deadline.

Broker: An intermediary that receives, routes, and distributes messages.

TLS: Transport Layer Security for protecting stream-oriented communications.

DTLS: Datagram Transport Layer Security.

Authentication: Verification of an entity’s identity.

Authorization: Determination of the operations an authenticated entity may perform.

Secure boot: Verification of software authenticity before execution.

LPWAN: Low-power wide-area network technology for long-range, low-rate communication.

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

Review Questions

Short Answer Questions

1. What is the principal difference between MQTT publish–subscribe and HTTP request–response communication?
2. Why is header compression important in constrained IoT networks?
3. State the three MQTT quality-of-service levels.
4. Distinguish authentication from authorization.
5. What is the purpose of secure boot?

Long Answer Questions

1. Explain the role of IPv6, 6LoWPAN, and RPL in a low-power mesh network.
2. Compare UDP, TCP, and QUIC for IoT applications, including reliability, overhead, and security considerations.
3. Discuss CoAP and MQTT as alternative application protocols for sensor networks.
4. Explain how TLS or DTLS, device identity, authorization, and signed firmware updates combine to form an IoT security architecture.
5. Develop a protocol-selection framework for an industrial monitoring system with strict latency and high availability requirements.

Analytical / Application Questions

1. A sensor sends 240 messages per hour, each containing a 100-byte payload. Calculate the average payload rate in bit/s, ignoring overhead. Then identify at least four factors that could make the required link capacity higher.
2. A wireless transmission attempt succeeds with probability 0.8. Assuming independent attempts, calculate the probability of success within four attempts and discuss why field performance may differ.
3. Design a secure communication architecture for a smart-building system containing battery-powered sensors, door actuators, a local gateway, and a cloud dashboard. Justify the protocol choice at each boundary and address duplicate commands, outages, and firmware updates.

Multiple Choice Questions with Answers

Question 1

Which protocol is primarily based on brokered publish–subscribe communication?

A. HTTP

B. MQTT

C. CoAP

D. FTP

Correct Answer: B. MQTT

Question 2

What is the main purpose of 6LoWPAN?

A. To provide video compression

B. To replace IPv6 routing

C. To support IPv6 over constrained low-power links

D. To authenticate cloud users

Correct Answer: C. To support IPv6 over constrained low-power links

Question 3

Which MQTT QoS level permits duplicate delivery?

A. QoS 0

B. QoS 1

C. QoS 2 only

D. None of the levels

Correct Answer: B. QoS 1

Question 4

For a packet of 1,600 bits transmitted at 250,000 bit/s, what is the raw serialization time?

A. 0.64 ms

B. 6.4 ms

C. 64 ms

D. 640 ms

Correct Answer: B. 6.4 ms

Question 5

Which statement best describes UDP?

A. It provides an ordered reliable byte stream

B. It is a connectionless datagram protocol

C. It requires a three-way handshake for every message

D. It automatically guarantees bounded latency

Correct Answer: B. It is a connectionless datagram protocol

Question 6

What does authorization determine?

A. Whether a message is encrypted

B. The physical location of a device

C. Which operations an authenticated entity may perform

D. The radio frequency used by a sensor

Correct Answer: C. Which operations an authenticated entity may perform

Question 7

Which protocol is specifically designed for constrained REST-like communication and commonly uses UDP?

A. CoAP

B. AMQP

C. SMTP

D. WebSocket

Correct Answer: A. CoAP

Question 8

If an independent transmission attempt succeeds with probability 0.9, what is the probability of success within three attempts?

A. 0.729

B. 0.900

C. 0.990

D. 0.999

Correct Answer: D. 0.999

Question 9

Which mechanism helps prevent execution of unauthorized firmware?

A. Secure boot

B. DNS caching

C. Payload fragmentation alone

D. MQTT topic retention

Correct Answer: A. Secure boot

Question 10

Why should actuator commands be designed to be idempotent where possible?

A. To increase radio frequency

B. To ensure repeated delivery does not cause unsafe repeated effects

C. To eliminate the need for authentication

D. To make IPv6 addresses shorter

Correct Answer: B. To ensure repeated delivery does not cause unsafe repeated effects