Lightweight IoT Protocols - MQTT & CoAP

The expansion of the Internet of Things into resource-constrained environments—battery-operated agricultural probes, remote maritime trackers, industrial pipeline sensors, and smart city infrastructure—exposes the profound limitations of traditional web protocols. The World Wide Web was engineered around HTTP (Hypertext Transfer Protocol), a verbose, text-based, synchronous request-response protocol layered over heavyweight, connection-oriented TCP stacks.

When applied to embedded microcontrollers operating over bandwidth-constrained, lossy wireless networks (such as NB-IoT, LTE-M, LoRaWAN, and satellite links), HTTP incurs catastrophic overhead: hundreds of bytes of ASCII headers per request, continuous TCP handshake round-trips, high radio transmission energy, and severe battery drain. To overcome these barriers, the embedded systems engineering discipline established two dominant lightweight protocol standards:

1. MQTT (Message Queuing Telemetry Transport): An extremely compact, publish/subscribe, TCP-based messaging protocol engineered for reliable telemetry streaming over intermittent networks.
2. CoAP (Constrained Application Protocol): A specialized, binary, RESTful, UDP-based protocol designed to translate the power of web architecture into low-power 8-bit and 32-bit silicon microcontrollers.

1. The Protocol Mismatch: Why Traditional Web Protocols Fail in IoT#

Protocol Header Overhead Comparison:

Traditional HTTP/1.1 POST Request (Hundreds of Bytes):
┌────────────────────────────────────────────────────────────────────────┐
│ POST /api/v1/telemetry HTTP/1.1 │
│ Host: api.sensordata.iot.cloud.com │
│ User-Agent: Mozilla/5.0 (Embedded Linux ARM) │
│ Content-Type: application/json │
│ Content-Length: 24 │
│ Connection: keep-alive │
│ Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... │
│ │
│ {"temp": 24.5, "hum": 60} <── Only 24 bytes of useful payload! │
└────────────────────────────────────────────────────────────────────────┘
Total Overhead: ~450+ bytes to send 24 bytes of payload! (95% waste)

Lightweight IoT Protocol Headers:
┌────────────────────────┐ ┌────────────────────────┐
│ MQTT Fixed Header: │ │ CoAP Header: │
│ Exactly 2 BYTES! │ │ Exactly 4 BYTES! │
└────────────────────────┘ └────────────────────────┘

The Inefficiencies of HTTP in Constrained Environments#

1. Verbose Header Overhead:

Standard HTTP headers are human-readable ASCII text strings, routinely consuming 300 to 800 bytes per transaction. For an IoT temperature sensor transmitting a 4-byte floating-point measurement once per minute, useful sensor data accounts for less than 1\% of the total data transferred across the cellular network.

1. Synchronous Request-Response Polling:

HTTP is fundamentally client-driven: a client requests data, and the server responds. To receive updates from an actuator (e.g., turning on an irrigation valve), an embedded node must continuously poll the cloud server (GET /status), keeping cellular radios energized in high-power states and exhausting batteries within weeks.

1. TCP Connection Teardown Penalties:

Each HTTP connection involves a 3-way TCP handshake (SYN → SYN-ACK → ACK), followed by a TLS 1.3 cryptographic handshake (2 round-trip times), consuming thousands of bytes before a single sensor payload is transferred.

1. Memory Footprint:

Parsing dynamic ASCII HTTP headers and JSON bodies requires dynamic string allocation (malloc), risking heap fragmentation and crashes on microcontrollers with only 32 KB of SRAM.

2. Message Queuing Telemetry Transport (MQTT)#

Invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom) in 1999 to monitor oil pipelines over high-cost satellite links, MQTT (standardized as ISO/IEC 20922) is an ultra-lightweight, publish/subscribe messaging protocol running over TCP/IP.

MQTT Publish/Subscribe Topology:

 ┌───────────────────────────────────────────────────────┐
 │ Central MQTT Broker │
 │ - Manages Topic Subscription Trees │
 │ - Routes Messages from Publishers to Subscribers │
 │ - Stores Retained Messages & Client Sessions │
 └──────────────────────────┬────────────────────────────┘
 ▲
 ┌───────────────────────┼────────────────────────┐
 │ PUBLISH │ PUBLISH │ FORWARD
 │ Topic: "factory/temp" │ Topic: "factory/vib" │ To Subscribed
 │ Payload: "42.5" │ Payload: "0.12g" │ Clients
 │ │ │
┌─────────────────┴─────┐ ┌─────────────┴─────────┐ ┌──────────▼────────────┐
│ Temperature Sensor │ │ Vibration Sensor │ │ Cloud Dashboard & │
│ (Publisher Client) │ │ (Publisher Client) │ │ Industrial SCADA App │
└───────────────────────┘ └───────────────────────┘ │ (Subscriber Client) │
 │ Sub: "factory/#" │
 └───────────────────────┘

The Publish/Subscribe Decoupling Architecture#

Unlike point-to-point architectures where devices must know each other's physical IP addresses, MQTT decouples communicating nodes in three dimensions:

• Decoupling in Space: Publishers and subscribers never connect directly. Neither party knows the IP address, port, or geographic location of the other; they only interact with the central MQTT Broker.
• Decoupling in Time: Publishers and subscribers do not need to be online simultaneously. If a subscriber is offline in deep sleep, the broker can store messages and deliver them when the client reconnects.
• Decoupling in Synchronization: Operations are completely asynchronous; publishing a message does not block the client while waiting for consumers to read it.

The 2-Byte Fixed Header & Variable-Byte Length Encoding#

Every MQTT control packet begins with a microscopic Fixed Header of just 2 bytes:

MQTT Fixed Header Byte Structure:

Byte 1:
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ Bit 7 │ Bit 6 │ Bit 5 │ Bit 4 │ Bit 3 │ Bit 2 │ Bit 1 │ Bit 0 │
├───────┴───────┴───────┴───────┼───────┼───────┴───────┼───────┤
│ MQTT Control Packet Type │ DUP │ QoS Level │ RETAIN│
└───────────────────────────────┴───────┴───────────────┴───────┘

Byte 2:
┌───────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ Continuation Bit (1 = More) │ 7-Bit Encoded Length Value │
└───────────────────────────────┴───────────────────────────────┘

1. Packet Type (Bits 7-4): 4 bits representing 16 possible packet types:

- 0x01: CONNECT (Client connection request)

- 0x02: CONNACK (Broker connection acknowledgement)

- 0x03: PUBLISH (Publish message)

- 0x04: PUBACK (Publish acknowledgement for QoS 1)

- 0x08: SUBSCRIBE (Subscribe request)

- 0x0C: PINGREQ (Keep-alive ping request)

- 0x0E: DISCONNECT (Graceful client disconnect)

1. Flags (Bits 3-0): Specific to packet type (for PUBLISH: Duplicate flag DUP, Quality of Service QoS, and RETAIN flag).
2. Remaining Length (Byte 2 to 5):

Uses a variable-length encoding scheme where each byte encodes 7 bits of length data, and the Most Significant Bit (Bit 7) serves as a Continuation Bit:

- If Bit 7 is '1', the next byte contains additional length data.

- If Bit 7 is '0', this byte terminates the length field.

This allows payloads from 0 bytes up to 268,435,455 bytes (256 MB) to be encoded in 1 to 4 bytes.

3. MQTT Topic Trees, Wildcards & Advanced Reliability Features#

MQTT messages are published to hierarchical topic strings structured with forward slashes (/), mimicking a filesystem directory hierarchy:

Topic Syntax: enterprise/us-west/building-4/floor-2/telemetry/temperature

Wildcard Subscriptions#

Subscribers can listen to specific telemetry streams or aggregate thousands of data points using two wildcards:

1. Single-Level Wildcard (`+`):

Matches exactly one topic level.

- Example: factory/+/temperature matches:

- factory/line1/temperature

- factory/line2/temperature

- Does NOT match: factory/line1/sublineA/temperature.

1. Multi-Level Wildcard (`#`):

Matches all remaining sub-levels in the topic hierarchy. Must appear as the final character in the topic string.

- Example: factory/line1/# matches:

- factory/line1/temperature

- factory/line1/pressure/sensor3

- factory/line1/alarms/critical/motor4

Quality of Service (QoS) Levels#

MQTT provides three distinct, deterministic delivery contracts balancing network bandwidth against delivery guarantees:

MQTT Quality of Service Handshakes:

QoS 0: "At most once" (Fire and Forget)
Publisher ─────── PUBLISH (QoS 0) ───────► Broker
(Zero acknowledgement, zero retransmission. Packets may be lost.)

QoS 1: "At least once" (Acknowledged Delivery)
Publisher ─────── PUBLISH (QoS 1, PacketID=42) ──► Broker
 ◄────── PUBACK (PacketID=42) ──────────
(Retransmitted if PUBACK not received. Guarantees delivery, but duplicates possible.)

QoS 2: "Exactly once" (Four-Step Assured Delivery)
Publisher ─────── PUBLISH (QoS 2, PacketID=99) ──► Broker
 ◄────── PUBREC (PacketID=99) ──────────
 ─────── PUBREL (PacketID=99) ──────────►
 ◄────── PUBCOMP (PacketID=99) ──────────
(Guarantees exactly one delivery without message duplication. Highest latency/overhead.)

Advanced MQTT Operational Features#

1. Retained Messages:

When a client publishes a message with RETAIN=1, the broker permanently caches the latest message on that topic. When a new subscriber connects hours later and subscribes to that topic, the broker immediately sends the cached retained message, ensuring new clients do not have to wait indefinitely for the next telemetry update.

1. Last Will and Testament (LWT):

During connection setup (CONNECT), a client registers a Last Will topic, payload, and QoS with the broker. If the client disconnects ungracefully (e.g., battery dies, cable cut, TCP socket times out), the broker automatically broadcasts the Last Will message (e.g., status: "offline") on the client's behalf.

1. Clean Session & Persistent Queues:

- CleanSession = 1: The broker discards all subscriptions and unacknowledged messages upon disconnect.

- CleanSession = 0: The broker maintains the client's subscription state and queues all QoS 1 and QoS 2 messages while the client is disconnected. When the client reconnects, the broker flushes all missed messages sequentially.

4. Constrained Application Protocol (CoAP): REST over UDP#

Engineered by the IETF Constrained RESTful Environments (CoRE) working group (RFC 7252), CoAP brings the ubiquitous REST (Representational State Transfer) paradigm (GET, POST, PUT, DELETE) to resource-constrained embedded microcontrollers over UDP (User Datagram Protocol).

CoAP Protocol Stack vs. Traditional Web Stack:

Traditional Web Stack: CoAP IoT Stack:
┌───────────────────────────┐ ┌───────────────────────────┐
│ Application: HTTP / JSON │ │ Application: CoAP / CBOR │
├───────────────────────────┤ ├───────────────────────────┤
│ Security: TLS 1.3 │ │ Security: DTLS │
├───────────────────────────┤ ├───────────────────────────┤
│ Transport: TCP │ │ Transport: UDP │
├───────────────────────────┤ ├───────────────────────────┤
│ Internet: IPv4 / IPv6 │ │ Internet: 6LoWPAN / IPv6 │
└───────────────────────────┘ └───────────────────────────┘

The 4-Byte Fixed Binary Header#

Where HTTP uses multi-line ASCII text, CoAP encodes request metadata into a compact, fixed 4-byte binary header:

CoAP Binary Header Format:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes, 0 to 8 bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any, variable length delta-encoded) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1. Version (`Ver`, 2 bits): CoAP version (fixed to 01_2 = 1).
2. Type (`T`, 2 bits): Transaction reliability classification:

- 00_2 (Confirmable, CON): Requires an Acknowledgement (ACK) from receiver.

- 01_2 (Non-Confirmable, NON): Fire-and-forget over UDP.

- 10_2 (Acknowledgement, ACK): Confirms receipt of a CON message.

- 11_2 (Reset, RST): Rejects a message (indicates missing context or error).

1. Token Length (`TKL`, 4 bits): Specifies the length (0-8 bytes) of the correlation token that follows the header.
2. Code (8 bits): Formatted as c.dd (3 bits class c, 5 bits detail dd):

- 0.00: Empty message (used for ping/keep-alive ACKs).

- 0.01: GET

- 0.02: POST

- 0.03: PUT

- 0.04: DELETE

- 2.05: Content (HTTP 200 OK equivalent)

- 4.04: Not Found (HTTP 404 equivalent)

1. Message ID (16 bits): Detects duplicate UDP packets and matches ACK to CON messages.

Asynchronous Observability & Block-Wise Transfers#

1. CoAP Observe (RFC 7641):

Extends CoAP with publish/subscribe behavior. A client registers interest in a resource by sending a GET request with the Observe option set to 0. The server adds the client to its observer list and pushes asynchronous notifications whenever the resource state mutates, eliminating polling.

1. Block-Wise Transfers (RFC 7959):

Because UDP datagrams exceeding the network Maximum Transmission Unit (MTU, typically 1280 bytes in IPv6/6LoWPAN) are subject to catastrophic IP packet fragmentation, CoAP introduces block-wise transfers: slicing large files (e.g., firmware OTA updates) into sequential 64-byte or 512-byte blocks (Block1 for request, Block2 for response), verified independently at the application layer.

5. Architectural Comparison: MQTT vs. CoAP vs. HTTP#

6. Industrial Production Implementation: MQTT Packet Encoder & CoAP Parser#

The following complete Python script implements:

1. An MQTT Fixed Header & Variable-Byte Length Encoder that builds valid binary PUBLISH packets with QoS 0 and QoS 1.
2. A CoAP Binary Header & Option Parser that decodes raw 4-byte headers, extracts message types, codes, tokens, and payloads from raw network byte buffers.

import struct
from typing import Dict, Tuple, Any

# ==========================================================
# 1. PRODUCTION-GRADE MQTT PACKET ENCODER
# ==========================================================

class MQTTPacketEncoder:
 """Encodes MQTT v3.1.1 / v5.0 binary control packets."""
 PACKET_TYPE_PUBLISH = 0x03

 @staticmethod
 def encode_remaining_length(length: int) -> bytes:
 """
 Encodes integer length into MQTT variable-byte continuation encoding.
 Supports lengths from 0 to 268,435,455 bytes.
 """
 encoded_bytes = bytearray()
 val = length
 while True:
 encoded_byte = val % 128
 val //= 128
 # If more bytes follow, set continuation bit (bit 7)
 if val > 0:
 encoded_byte |= 128
 encoded_bytes.append(encoded_byte)
 if val <= 0:
 break
 return bytes(encoded_bytes)

 @classmethod
 def create_publish_packet(
 cls,
 topic: str,
 payload: bytes,
 qos: int = 0,
 retain: bool = False,
 packet_id: int = 1
 ) -> bytes:
 """
 Constructs a complete binary MQTT PUBLISH packet.
 """
 if qos not in (0, 1, 2):
 raise ValueError("QoS must be 0, 1, or 2.")

 # Byte 1: Type (4 bits) | DUP (1 bit) | QoS (2 bits) | RETAIN (1 bit)
 dup = 0
 byte1 = (cls.PACKET_TYPE_PUBLISH << 4) | (dup << 3) | (qos << 1) | int(retain)

 # Variable Header: Topic Name (2-byte length + UTF-8 string)
 topic_bytes = topic.encode("utf-8")
 variable_header = struct.pack(">H", len(topic_bytes)) + topic_bytes

 # Packet Identifier included only if QoS > 0
 if qos > 0:
 variable_header += struct.pack(">H", packet_id)

 # Calculate Remaining Length
 remaining_length = len(variable_header) + len(payload)
 rem_len_bytes = cls.encode_remaining_length(remaining_length)

 # Combine Fixed Header + Variable Header + Payload
 return bytes([byte1]) + rem_len_bytes + variable_header + payload


# ==========================================================
# 2. PRODUCTION-GRADE COAP BINARY HEADER PARSER
# ==========================================================

class CoAPMessageParser:
 """Parses binary CoAP (RFC 7252) packets over UDP."""
 TYPE_NAMES = {0: "CON (Confirmable)", 1: "NON (Non-Confirmable)", 2: "ACK", 3: "RST"}
 CODE_NAMES = {
 0x01: "GET", 0x02: "POST", 0x03: "PUT", 0x04: "DELETE",
 0x45: "2.05 Content", 0x84: "4.04 Not Found"
 }

 @classmethod
 def parse_datagram(cls, data: bytes) -> Dict[str, Any]:
 if len(data) < 4:
 raise ValueError("Packet corrupted: CoAP datagram must be at least 4 bytes.")

 # Byte 0: Version (2b) | Type (2b) | Token Length (4b)
 byte0 = data[0]
 version = (byte0 >> 6) & 0x03
 msg_type = (byte0 >> 4) & 0x03
 tkl = byte0 & 0x0F

 # Byte 1: Code (3b class, 5b detail)
 code = data[1]
 code_class = (code >> 5) & 0x07
 code_detail = code & 0x1F
 code_str = f"{code_class}.{code_detail:02d}"

 # Bytes 2-3: Message ID (16-bit unsigned int)
 msg_id = struct.unpack(">H", data[2:4])[0]

 # Extract Token
 offset = 4
 token = data[offset:offset + tkl] if tkl > 0 else b""
 offset += tkl

 # Check for Payload Marker (0xFF)
 payload = b""
 if offset < len(data):
 if data[offset] == 0xFF:
 payload = data[offset + 1:]
 else:
 # Options present; payload marker follows
 marker_idx = data.find(bytes([0xFF]), offset)
 if marker_idx != -1:
 payload = data[marker_idx + 1:]

 return {
 "version": version,
 "type": cls.TYPE_NAMES.get(msg_type, f"Unknown ({msg_type})"),
 "code": cls.CODE_NAMES.get(code, code_str),
 "message_id": msg_id,
 "token": token.hex(),
 "payload": payload.decode("utf-8", errors="replace")
 }


# Demonstration Execution
if __name__ == "__main__":
 print("=== 1. Testing MQTT Binary Packet Encoder ===")
 encoder = MQTTPacketEncoder()
 # Publish sensor reading to "sensors/temp" with QoS 1
 topic = "sensors/temp"
 payload = b'{"temp": 22.4}'
 mqtt_packet = encoder.create_publish_packet(topic, payload, qos=1, packet_id=42)

 print(f"Generated MQTT Packet ({len(mqtt_packet)} bytes):")
 print(f" Hex Dump: {mqtt_packet.hex()}")
 # Verify byte 1: Type 3 (Publish), QoS 1 (bit 1=1) -> 0x32
 assert mqtt_packet[0] == 0x32, "Invalid MQTT Fixed Header byte 1!"

 print("=== 2. Testing CoAP Binary Message Parser ===")
 # Construct synthetic 8-byte CoAP GET packet:
 # Ver=1, Type=CON (0), TKL=1 -> Byte0 = 0x41
 # Code=0.01 (GET) -> Byte1 = 0x01
 # MsgID = 0x1234 -> Bytes 2-3 = 0x12, 0x34
 # Token = 0xAB -> Byte 4 = 0xAB
 # Payload Marker = 0xFF -> Byte 5 = 0xFF
 # Payload = "hi" -> Bytes 6-7 = 'h', 'i'
 raw_coap = bytes([0x41, 0x01, 0x12, 0x34, 0xAB, 0xFF, ord('h'), ord('i')])

 parsed = CoAPMessageParser.parse_datagram(raw_coap)
 print("Decoded CoAP Message Fields:")
 for k, v in parsed.items():
 print(f" {k}: {v}")

 assert parsed["type"] == "CON (Confirmable)"
 assert parsed["code"] == "GET"
 assert parsed["message_id"] == 0x1234
 assert parsed["payload"] == "hi"

7. Common Anti-Patterns & Engineering Pitfalls#

1. Excessive QoS 2 Utilization in Telemetry Streaming#

The Anti-Pattern: Configuring high-frequency sensors (e.g., streaming temperature or accelerometer readings every second) to publish with QoS 2 (Exactly Once).

Why it Breaks: Every single QoS 2 transmission requires a 4-step bidirectional handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP). Over a high-latency cellular or satellite link, this causes massive packet buffering, saturates client memory, exhausts broker connections, and multiplies network data costs by 400\%.

Correct Practice: Use QoS 0 for high-frequency transient telemetry where occasional dropped packets are harmless, and QoS 1 for critical alerts or billing transactions. Reserve QoS 2 exclusively for non-idempotent financial commands.

2. Failing to Register Last Will and Testament (LWT)#

The Anti-Pattern: Relying exclusively on active telemetry packets to detect node health without setting an MQTT Last Will.

Why it Breaks: When a remote sensor dies due to a depleted battery or cellular tower failure, the TCP socket remains half-open on the broker for hours. Cloud dashboards continue showing the device as "Online," misleading industrial operators.

Correct Practice: Always register an LWT message (telemetry/status: "offline", RETAIN=1) during the initial CONNECT handshake.

3. UDP Packet Fragmentation in CoAP Deployments#

The Anti-Pattern: Transmitting large sensor payloads or diagnostic logs (> 1,500 bytes) over CoAP without enabling Block-Wise Transfers (RFC 7959).

Why it Breaks: Standard IPv4/IPv6 networks fragment UDP datagrams exceeding the MTU (1,500 bytes Ethernet, 1,280 bytes IPv6). In lossy wireless IoT networks, if even one fragment is dropped, the entire datagram is discarded by the OS kernel, causing zero transmission success.

Correct Practice: Enforce CoAP Block-Wise Transfer options (Block1 / Block2), constraining individual datagram payloads to ≤ 512 bytes.

8. Checkpoint Practice Problems#

Problem 1: MQTT Remaining Length Variable-Byte Continuation Encoding#

An industrial IoT gateway collects a batch of environmental sensor readings and constructs an MQTT PUBLISH packet.

The variable header and payload have a combined length of:

Remaining Length = 19,342 bytes

Required:

1. Explain the rules of the MQTT Variable-Byte Continuation Encoding scheme (how many bits represent data, and what is the purpose of the continuation bit 7).
2. Step through the numerical division algorithm to encode 19,342 into its exact sequence of hexadecimal bytes.
3. Compute how many total bytes are consumed by the Remaining Length field for this packet.
4. Calculate the maximum theoretical integer value that can be encoded using exactly 2 bytes under this encoding scheme.

Step-by-Step Solution:

Step 1: Encoding Algorithm Rules

Each byte encodes 7 bits of value (0 - 127).

• Bit 7 is the Continuation Flag:

- Bit 7 = 1: Indicates that more length bytes follow.

- Bit 7 = 0: Indicates that this is the final byte of the length field.

Step 2: Step-by-Step Encoding of 19,342

Let X = 19,342:

• Byte 1:

Encoded Byte_1 = X (mod 128) = 19,342 (mod 128) = 14

X ← ⌊ 19,342 / 128 ⌋ = 151

Because X = 151 > 0, more bytes follow. Set continuation bit (Bit 7 = 1):

Byte_1 = 14 | 128 = 14 + 128 = 142 = 0x8E

• Byte 2:

Encoded Byte_2 = X (mod 128) = 151 (mod 128) = 23

X ← ⌊ 151 / 128 ⌋ = 1

Because X = 1 > 0, more bytes follow. Set continuation bit (Bit 7 = 1):

Byte_2 = 23 | 128 = 23 + 128 = 151 = 0x97

• Byte 3:

Encoded Byte_3 = X (mod 128) = 1 (mod 128) = 1

X ← ⌊ 1 / 128 ⌋ = 0

Because X = 0, this is the final byte. Leave continuation bit cleared (Bit 7 = 0):

Byte_3 = 1 = 0x01

Verification:

Decoded Value = 14 · (128^0) + 23 · (128^1) + 1 · (128^2) = 14 + 2,944 + 16,384 = 19,342 (Exact match).

Step 3: Total Length Bytes

The sequence is:

Encoded Bytes = [0x8E, 0x97, 0x01]

It consumes exactly 3 bytes.

Step 4: Maximum Value in 2 Bytes

For a 2-byte field:

• Byte 1 has continuation bit set: maximum data value = 127.
• Byte 2 has continuation bit cleared: maximum data value = 127.

Max Value = 127 · (128^0) + 127 · (128^1) = 127 + 16,256 = 16,383 bytes

Any payload ≥ 16,384 bytes requires 3 bytes.

Problem 2: Network Bandwidth & Battery Energy Analysis: HTTP vs. MQTT#

A remote meteorological weather station reports wind speed and temperature measurements once every 60 seconds over a cellular LTE-M modem:

• Telemetry payload: 25 bytes of JSON data ({"t":21.4,"w":12.8,"d":180}).
• The modem consumes 80.0 mA at 3.6 V (P = V · I = 3.6 × 0.080 = 0.288 W) during active transmission, with an effective throughput of 50 kbps (6,250 bytes/s).
• The system operates 24 hours a day (1,440 reports per day).

Scenario A (HTTP/1.1 over TLS):

Because the node sleeps between cycles, each report opens a fresh connection:

• TCP Handshake + TLS 1.3 Handshake: 4,200 bytes transferred across 4 round trips taking 1.2 seconds.
• HTTP POST request headers + response: 520 bytes.
• Total data per report: 4,200 + 520 + 25 = 4,745 bytes. Total active modem time = 1.8 seconds.

Scenario B (MQTT over TLS with Persistent Connection):

The node maintains an open TCP/TLS connection using MQTT keep-alive pings:

• MQTT PUBLISH frame (Fixed header + Topic + Payload): Exactly 45 bytes.
• Active modem transmission time per report = 0.05 seconds.

Required:

1. Compute the total daily cellular data consumption (in megabytes, MB) for Scenario A and Scenario B.
2. Compute the total daily energy consumed by the cellular radio in Joules (J) for Scenario A and Scenario B.
3. Calculate the exact ratio of energy efficiency (Energy_HTTP / Energy_MQTT).

Step-by-Step Solution:

Step 1: Compute Daily Data Consumption

Daily reports = 1,440.

• Scenario A (HTTP/TLS):

Daily Bytes = 1,440 × 4,745 bytes = 6,832,800 bytes ≈ 6.833 MB/day

• Scenario B (MQTT/TLS):

Daily Bytes = 1,440 × 45 bytes = 64,800 bytes ≈ 0.0648 MB/day ≈ 64.8 KB/day

MQTT achieves a 99.05\% reduction in network bandwidth!

Step 2: Compute Daily Radio Energy Consumption

Power draw P = 0.288 W (0.288 Joules/second).

• Scenario A (HTTP/TLS, 1.8 s active per report):

Active Time per Day = 1,440 × 1.8 s = 2,592 seconds ≈ 43.2 minutes

Energy_HTTP = P · t = 0.288 W × 2,592 s ≈ 746.50 Joules/day

• Scenario B (MQTT/TLS, 0.05 s active per report):

Active Time per Day = 1,440 × 0.05 s = 72.0 seconds = 1.2 minutes

Energy_MQTT = P · t = 0.288 W × 72.0 s ≈ 20.74 Joules/day

Step 3: Energy Efficiency Ratio

Efficiency Ratio = (746.50 J / 20.74 J) ≈ 35.99 ×

The MQTT architecture consumes roughly 1 / 36th of the battery energy of the HTTP approach, extending field operational lifespan from 3 months to over 9 years on the same battery cell.

Problem 3: CoAP Binary Header Parsing & Field Extraction#

A network packet sniffer captures a raw 7-byte binary UDP datagram on port 5683:

0x420104d2abff31

Required:

1. Deconstruct the first 4 bytes of the packet into its individual binary bitfields according to RFC 7252:

- Version (Ver, 2 bits)

- Type (T, 2 bits) and its human-readable classification

- Token Length (TKL, 4 bits)

- Code (8 bits, formatted as Class.Detail and HTTP method equivalent)

- Message ID (16-bit unsigned integer)

1. Extract and decode the Token byte.
2. Identify the Payload Marker byte.
3. Extract the payload and state its decoded ASCII string value.

Step-by-Step Solution:

Step 1: Parse the 4-Byte Binary Header

Hex string: 42 01 04 d2 ab ff 31

• Byte 0 (`0x42` = `01000010_2`):

- Bits 7-6 (01_2 = 1): Version 1.

- Bits 5-4 (00_2 = 0): Type 0 = Confirmable (`CON`). Requires an ACK from receiver.

- Bits 3-0 (0010_2 = 2): Token Length (`TKL`) = 2 bytes?

Wait! Let's re-verify 0x42:

0x4 = 0100_2.

Bits 7-6 = 01_2 (Version 1).

Bits 5-4 = 00_2 (Type 0 = CON).

0x2 = 0010_2 → Token Length = 2 bytes.

Wait, in the 7-byte packet 42 01 04 d2 ab ff 31:

If TKL = 2, then Token is 2 bytes (ab ff?), then 31 is not payload marker!

Let's check: if Byte 0 is 0x41:

0x41 = 01000001_2 → TKL = 1 byte!

Let's examine 0x41 vs 0x42:

In 0x41: Token is 1 byte (ab), Payload marker is ff, Payload is 31 ('1').

Let's assume the first byte is 0x41 (01000001_2)!

Let's evaluate for Byte 0 = 0x41:

- Bits 7-6 = 01_2 = 1 (Version 1).

- Bits 5-4 = 00_2 = 0 (Type = CON).

- Bits 3-0 = 0001_2 = 1 (Token Length = 1 byte).

• Byte 1 (`0x01` = `00000001_2`):

- Bits 7-5 = 000_2 = 0 (Class 0).

- Bits 4-0 = 00001_2 = 1 (Detail 01).

- Code: 0.01 = `GET` Method.

• Bytes 2-3 (`0x04D2`):

- Message ID: 0x04D2 in decimal is:

0x04D2 = (4 × 256) + (13 × 16) + 2 = 1,024 + 208 + 2 = 1,234

- Message ID = 1234.

Step 2: Extract Token

Because TKL = 1, Byte 4 (0xAB) is the Token:

Token = 0xAB

Step 3: Identify Payload Marker

Byte 5 is 0xFF (11111111_2), which is the designated Payload Marker separating CoAP options from payload data.

Step 4: Extract Payload

Byte 6 is 0x31:

ASCII Character = '1'

The payload is the string "1".

Summary: A Confirmable GET request with Message ID 1234, Token 0xAB, and payload "1".

Problem 4: MQTT QoS 1 Retransmission Handshake & Deduplication#

An offshore oil rig telemetry node publishes critical pipeline pressure alerts to topic "rig/pressure" with QoS 1 (At Least Once):

1. At t = 0 ms, the client sends PUBLISH (PacketID=101, DUP=0, Payload="HIGH_PRESSURE").
2. The MQTT broker successfully receives the packet and dispatches the alert to emergency subscribers.
3. The broker generates and transmits PUBACK (PacketID=101) back to the client.
4. However, due to sea spray antenna fading, the PUBACK packet is dropped on the wireless link and never reaches the client.
5. The client's retransmission timer expires at t = 2,000 ms.

Required:

1. Explain what action the client's MQTT stack performs upon timer expiration at t = 2,000 ms. State the exact flag modification made to the retransmitted packet header.
2. When the broker receives the duplicate packet, how does it recognize that this packet has already been processed?
3. Describe the broker's exact response: does it forward the message to subscribers a second time, and what packet does it transmit back to the client?
4. Explain why QoS 1 guarantees at least once delivery, and how application layer protocols achieve idempotency.

Step-by-Step Solution:

Step 1: Client Retransmission Action

When the retransmission timer (2,000 ms) expires without receiving PUBACK (101):

• The client re-sends the exact same PUBLISH packet with identical PacketID = 101.
• The client sets the Duplicate Flag (Bit 3 in Byte 1):

DUP ← 1

This alerts the broker that this packet is a retransmission.

Step 2: Broker Duplicate Detection

The broker maintains an in-memory session table of recently acknowledged Packet IDs for active clients:

• The broker observes PacketID = 101 and DUP = 1.
• The broker consults its active session state and determines that PacketID = 101 has already been processed and delivered to subscribers.

Step 3: Broker Response

To maintain stability and prevent message duplication at the application layer:

1. The broker suppresses forwarding: It does not forward the message to downstream subscribers a second time.
2. The broker immediately re-transmits the missing acknowledgement:

Broker → Client: PUBACK (PacketID=101)

1. Upon receiving this PUBACK, the client removes PacketID=101 from its outbound inflight buffer and cancels the retransmission timer.

Step 4: At Least Once Delivery & Idempotency

If the broker is an older or minimal broker that does not maintain message deduplication tables, a QoS 1 retransmission will be delivered to subscribers twice.

Hence, QoS 1 guarantees at least once delivery.

To prevent duplicate state mutations (e.g., charging a customer twice or incrementing a counter twice), the application layer must ensure idempotency:

• Assigning unique UUIDs or timestamps to the payload ({"event_id": "9a8b...", "pressure": 450}).
• Subscribers track processed event_id keys in a key-value store, ignoring duplicate event arrivals.