IoT Protocols

M4-R5.1 · Chapter 1: Introduction to Internet of Things – Applications/Devices, Protocols andCommunication Model · 9 min read

IoT Protocol

1. Link Layer (Network Interface Layer)

This is the foundational, first layer of the IoT protocol stack. This layer determines how data is physically sent over the network (the physical layer and cable/wireless transmission).

Key Link Layer Protocols:

  • 802.3 (Ethernet): Ethernet is a set of technologies and protocols used primarily in Local Area Networks (LANs). It defines the physical layer and the Media Access Control (MAC) sublayer for wired network communication.
  • 802.11 (Wi-Fi): This specifies the MAC and physical layer protocols for implementing a Wireless Local Area Network (WLAN). It commonly uses the 2.4 GHz and 5 GHz frequency bands.
  • 802.16 (WiMAX): This technology is the standard for Wireless Metropolitan Area Networks (WMANs). It specializes in point-to-point to multipoint broadband wireless access.
  • Cellular Networks (2G, 3G, 4G, 5G): These are different generations of telecommunication technologies used by IoT devices to communicate over a cellular network.

2. Network Layer

The Network Layer is responsible for the logical addressing of connected devices. This layer determines the route used for data communication.

Key Network Layer Protocols:

  • IPv4 (Internet Protocol version 4): An IP address is a numerical label assigned to each device connected to a computer network. It serves two main functions: network interface identification and location addressing. It is a 32-bit address containing four sectors (each ranging from 0 to 255), separated by dots.
  • IPv6 (Internet Protocol version 6): IPv6 is the most recent version of IP, developed by the IETF (Internet Engineering Task Force) in 1998. It was designed to solve the long-anticipated problem of IPv4 address exhaustion.
  • 6LoWPAN: This stands for IPv6 over Low-Power Wireless Personal Area Networks.

3. Transport Layer

This layer provides functions such as flow control, segmentation, and reassembly of data. It provides end-to-end message transfer capabilities independent of the underlying network.

Key Transport Layer Protocols:

  • TCP (Transmission Control Protocol): TCP is a standard, connection-oriented protocol that defines how to establish and maintain a network conversation for applications to exchange data. It works directly with the Internet Protocol (IP), which defines how computers send packets of data to each other. TCP and IP are the basic rules defining the internet, maintained by the IETF.
  • UDP (User Datagram Protocol): Unlike TCP, UDP is an unreliable, connectionless transport layer protocol. Because it is connectionless, there is no need to establish a connection prior to data transfer.

4. Application Layer

  • This uppermost layer is responsible for data formatting and presentation.
  • Application layer protocols define how application data interfaces with the lower layers to be sent over the network.

Protocols

1. HTTP / HTTPS

HTTP (HyperText Transfer Protocol) is the foundation of data communication on the web. It works on a classic request-response model — a client (like a browser or app) sends a request, and a server sends back a response. HTTPS is just HTTP with TLS encryption on top.

How it works in IoT: A sensor or device acts as a client. It sends an HTTP POST to a cloud server with its data (e.g., temperature readings). The server responds with a 200 OK. Simple and universally supported.

Ports: HTTP → 80, HTTPS → 443

Real-life examples:

  • A smart thermostat sends temperature data to a cloud API every 10 minutes via HTTPS POST.
  • A weather station uploads readings to a web dashboard.
  • Firmware update checks — a device calls a URL to check if a new version exists.

Limitations: HTTP is stateless and heavy. Each request opens a new connection (in HTTP/1.1). Not ideal for battery-powered devices that need to talk thousands of times a day.

2. WebSockets

WebSockets solve the biggest problem with HTTP — the connection has to be re-opened for every request. WebSockets establish a persistent, full-duplex connection over a single TCP connection. Once open, both sides (client and server) can send data to each other at any time without waiting for a request.

Real-life examples:

  • A smart home dashboard (in your browser) that shows live sensor readings updating every second — no page refresh needed.
  • Live monitoring of a hospital patient's vitals on a nurse's screen.
  • Real-time stock price tickers on trading platforms.

Why better than HTTP here: Instead of polling ("do you have new data?") every second, the server pushes data the moment it's available.

 

MQTT(Message Queue Telemetry Transport )

MQTT is the most widely used IoT protocol today. Developed originally by IBM for monitoring oil pipelines via satellite (where bandwidth was scarce), it follows a publish-subscribe model.

How it works:

  • Devices (publishers) publish data to a topic (like home/bedroom/temperature).
  • Other devices or apps (subscribers) subscribe to topics they care about.
  • A central broker (like Mosquitto, HiveMQ, or AWS IoT Core) sits in the middle and routes all messages.
  • No device needs to know about any other device — they only talk to the broker.

Real-life examples:

  • Amazon Echo / Google Home devices report state to AWS IoT Core via MQTT.
  • Tesla cars communicate with Tesla's cloud using MQTT-like protocols.
  • Smart agriculture — soil moisture sensors publish to a farmer's app.

Port: 1883 (unencrypted), 8883 (TLS encrypted MQTTS)

Limitation: Runs over TCP, which requires a persistent connection — not ideal for devices that sleep to save battery.

4. CoAP (Constrained Application Protocol)

CoAP is essentially HTTP redesigned for tiny, battery-powered devices (microcontrollers, sensors with very little memory). It mirrors HTTP's GET/POST/PUT/DELETE methods but runs over UDP instead of TCP, making it much lighter.

It also supports observe mode — a client can subscribe to a resource and get updates automatically when it changes (like pub-sub, but simpler).

Real-life examples:

  • A street light node with a tiny microcontroller (like an Arduino) sending power consumption data.
  • Smart metering — electricity meters in remote areas sending readings over LTE-M.
  • Wearable health devices (heart rate monitors) sending data to a gateway.

Key difference from HTTP: CoAP uses binary encoding (much smaller packet size) and UDP (no connection setup). This dramatically reduces power usage.

5. AMQP (Advanced Message Queuing Protocol)

AMQP is a full-featured, enterprise-grade messaging protocol. Unlike MQTT's simple pub-sub, AMQP adds queues, exchanges, routing keys, and acknowledgements — making it suitable for mission-critical systems where no message can be lost.

How it works:

  • A producer sends a message to an exchange.
  • The exchange routes it to one or more queues based on routing rules.
  • Consumers pull from queues (or receive pushed messages).
  • Every message is acknowledged — the broker knows it was received and processed.

Real-life examples:

  • A bank's payment processing system — every transaction must be processed exactly once.
  • Hospital systems — patient alerts routed to the right nurse station

Why not MQTT here: AMQP is heavier but guarantees delivery, routing, and persistence. It's for enterprise back-ends, not tiny sensors.

6. XMPP (Extensible Messaging and Presence Protocol)

XMPP was originally built for instant messaging (it powers Jabber, Google Talk's old backend, and WhatsApp's early infrastructure). It is XML-based and excels at real-time presence — knowing if a device or user is online, offline, or busy.

Real-life examples in IoT:

  • Smart home hubs where devices report presence ("light bulb is ON/reachable").
  • Push notifications for IoT devices — when a device changes state, an XMPP message is sent immediately.
  • Industrial monitoring — knowing in real-time if a machine is online or has gone offline.
  • Online gaming servers (presence and messaging between players).

Limitation: XML is verbose. Packets are large compared to MQTT. Not ideal for constrained devices.