Communication protocols for constrained devices notes — Unit 3

The traditional internet is built on protocols like TCP/IP and HTTP. These were designed for desktop computers with continuous power supplies and high-bandwidth wired connections. They are fundamentally unsuitable for the majority of IoT devices.

⇒1.1 The Constraints

IoT protocols must be engineered to operate under severe limitations:

• Power Constraints: Devices often run on coin-cell batteries that must last for years. Transmitting radio waves is the most power-hungry operation an MCU performs.
• Bandwidth Constraints: IoT networks often operate over noisy, low-bitrate RF channels where sending a few kilobytes takes seconds.
• Memory Constraints: The protocol stack (the code required to handle networking) must be tiny enough to fit into an MCU's 32KB of RAM, ruling out full TCP/IP stacks in many cases.

For personal area networks (PANs) or local home automation, devices only need to transmit data a few meters.

⇒2.1 Bluetooth Low Energy (BLE)

BLE (Bluetooth 4.0+) is entirely different from classic Bluetooth used for audio. It is designed to sleep most of the time, wake up instantly, transmit a tiny burst of data, and go back to sleep. A BLE beacon can run on a watch battery for 3 years.

⇒2.2 Zigbee & Z-Wave

These are IEEE 802.15.4 based protocols designed specifically for home/industrial automation. Their defining feature is Mesh Networking. Instead of all devices talking directly to a central router (like Wi-Fi), devices talk to their nearest neighbor, passing messages bucket-brigade style across the network. This extends range and eliminates single points of failure.

Low Power Wide Area Networks (LPWANs) are the breakthrough technology that made Smart Agriculture and Smart City deployments possible. They solve the problem of transmitting data for miles on a battery.

⇒3.1 LoRa and LoRaWAN

LoRa (Long Range) uses a proprietary spread-spectrum modulation technique derived from chirp spread spectrum (CSS) technology. It trades data rate for extreme range and penetration. A soil sensor in a field can transmit to a gateway 15 kilometers away, piercing through foliage and buildings, while consuming minimal power. However, the data rate is measured in bits per second. You can send a temperature reading, but you cannot stream a photo.

⇒3.2 NB-IoT (Narrowband IoT)

This is the cellular industry's answer to LoRa. NB-IoT operates on existing 4G/5G cell towers using a tiny sliver of dedicated spectrum. It offers better quality of service and higher data rates than LoRa, but typically consumes slightly more power and requires a paid SIM subscription to a telco.

HTTP uses a Request-Response model. A client asks a server for data, the server responds. This is highly inefficient for IoT for two reasons:

• Overhead: HTTP headers are massive (often larger than the actual sensor data payload).
• Polling: If a smartphone app wants to know if an IoT door sensor was opened, it has to constantly ask the server ('Is it open?', 'Is it open?'). This wastes battery and bandwidth.

⇒4.1 Enter MQTT

Message Queuing Telemetry Transport (MQTT) is a lightweight, publish-subscribe network protocol. It was designed by IBM specifically for connections with remote locations where a small code footprint is required and network bandwidth is at a premium (originally used to monitor oil pipelines over satellite links).

MQTT fundamentally changes the communication paradigm from point-to-point to a centralized hub model.

⇒5.1 The Broker and Topics

In MQTT, devices do not talk directly to each other. They connect to a central server called a Broker. Data is organized by hierarchical strings called Topics (e.g., `home/livingroom/temperature`).

• Publishing: A sensor (Publisher) measures 22°C and sends a tiny message to the Broker addressed to `home/livingroom/temperature`. The sensor doesn't care who is listening.
• Subscribing: A mobile app (Subscriber) connects to the Broker and says 'Send me any message published to `home/livingroom/temperature`'.

When the Broker receives the temperature message, it instantly pushes it to the mobile app. No polling is required. This drastically reduces network traffic and battery drain on the sensor node.

Because IoT networks are unreliable (radios drop packets), MQTT has built-in mechanisms to guarantee message delivery, known as Quality of Service levels.

While MQTT is brilliant for pub-sub messaging over TCP, what if we still need the Request-Response model of the web (RESTful APIs) but don't have the bandwidth for HTTP?

⇒7.1 Constrained Application Protocol (CoAP)

CoAP is essentially a stripped-down, binary version of HTTP. It uses the exact same methods (`GET`, `POST`, `PUT`, `DELETE`) and URLs.

However, unlike HTTP which relies on the heavy TCP protocol, CoAP runs over UDP. UDP is connectionless and has almost zero overhead. Because UDP drops packets, CoAP has its own tiny reliability mechanism built-in (retransmission timers) and a minimal binary header format (typically just 4 bytes, compared to hundreds of bytes in HTTP).

This unit bridges hardware and cloud. Expect questions comparing these protocols based on range, power, and architecture.

• Mesh vs Star: Understand why Zigbee (Mesh) provides better reliability in a smart home than Wi-Fi (Star topology).
• LPWANs: Be able to explain the trade-off LoRa makes: extreme range in exchange for extremely low data rates.
• MQTT Architecture: The Pub-Sub model is guaranteed to appear in exams. Understand the role of the Broker, Topics, and why it eliminates the need for HTTP polling.
• MQTT QoS: Memorize the three QoS levels (0, 1, 2) and their use cases regarding delivery guarantees.
• CoAP vs MQTT: Understand that MQTT is Pub-Sub over TCP, while CoAP is Request-Response (RESTful) over UDP.