20  IoT Protocols Overview

MVU – Minimum Viable Understanding

IoT devices cannot use standard internet protocols directly because they lack the memory, power, and bandwidth that HTTP and TCP assume. Instead, IoT relies on a specialized protocol stack: 6LoWPAN compresses IPv6 headers so tiny sensors can have internet addresses, CoAP provides RESTful communication over UDP with minimal overhead, and MQTT enables scalable publish-subscribe messaging through a broker. Choosing the right protocol for each layer – link, network, transport, and application – is the single most impactful design decision for power consumption, reliability, and scalability.

Learning Objectives

By the end of this section, you will be able to:

• Explain why traditional internet protocols need adaptation for IoT constraints
• Identify protocols at each layer of the IoT protocol stack
• Differentiate IPv4 and IPv6 for IoT addressing requirements
• Describe the role of 6LoWPAN in enabling IPv6 on constrained networks
• Compare CoAP and MQTT application protocols by overhead and communication pattern
• Map protocols to the TCP/IP layer model accurately
• Select appropriate protocols for different IoT deployment scenarios

In 60 Seconds

IoT devices use specialised protocol stacks because standard TCP/HTTP assumes plentiful memory, power, and bandwidth. 6LoWPAN compresses IPv6 headers for tiny sensors, CoAP provides RESTful messaging over UDP, and MQTT enables scalable pub-sub via a broker — each solving a different constraint at a different layer.

20.1 Prerequisites

Before diving into this chapter, you should be familiar with:

• Networking Basics for IoT: Understanding of fundamental networking concepts, TCP/IP stack, and protocol layers provides the foundation for learning about specialized IoT protocols
• Layered Models: Fundamentals: Knowledge of the OSI and TCP/IP layered models is essential for understanding where each IoT protocol fits in the stack (application, transport, network, link layers)
• IoT Protocols: Fundamentals: Basic understanding of why IoT requires specialized protocols helps contextualize the specific protocols covered in this overview chapter

---

Sensor Squad: How Do IoT Devices Talk to Each Other?

Meet the Sensor Squad!

Sammy the Temperature Sensor wants to tell the cloud that the kitchen is getting too hot. But Sammy is tiny – he only has a small battery and a weak radio. He can’t shout across the whole internet like a big computer can!

The Language Layers Analogy:

Imagine the Sensor Squad members are pen pals in different countries. To send a letter, they need:

1. A language to write in (Application layer) – Sammy writes in “CoAP” because it uses short words. Lila the Light Sensor prefers “MQTT” because she can send messages to a bulletin board that many people read.
2. An envelope style (Transport layer) – Sammy uses a postcard (UDP) because it’s quick and light. Lila uses a tracked package (TCP) because she wants to be sure it arrives.
3. An address (Network layer) – Every sensor gets a special number called an IPv6 address. But the address is too long for tiny Sammy, so 6LoWPAN shrinks it to fit on a tiny envelope!
4. A delivery truck (Link layer) – Wi-Fi, Bluetooth, or Zigbee are the different “trucks” that carry the letters.

Max’s Motion Tip: “Think of protocols like languages. Just like you pick Spanish or French depending on who you’re talking to, we sensors pick CoAP or MQTT depending on whether we need speed or reliability!”

Bella’s Button Fact: “A regular web page uses about 700 bytes just for the header. CoAP uses only 4 bytes – that’s like writing a full address on one tiny sticky note instead of a whole page!”

Try This at Home: Open a browser and visit any website. That used HTTP – a protocol with BIG headers. Now imagine your tiny watch trying to do that a thousand times a day on a coin battery. That’s why we need special IoT protocols!

---

For Beginners: What Are IoT Protocols and Why Do They Matter?

Real-World Analogy: Think of IoT protocols as the rules of the road for data. Just as traffic rules vary between a busy highway (TCP/HTTP) and a quiet neighborhood bike path (UDP/CoAP), different types of network traffic need different rules.

Why can’t IoT devices just use regular internet protocols?

Traditional protocols like HTTP were designed for powerful computers with constant electricity, gigabytes of memory, and fast wired connections. IoT devices face the opposite reality:

Resource	Desktop Computer	IoT Sensor
Memory	8-64 GB	32-256 KB
Processor	3-5 GHz	16-240 MHz
Power	Always plugged in	Coin cell battery (years)
Connection	Reliable Ethernet/Wi-Fi	Lossy wireless (10-40% loss)

Because of these constraints, IoT uses lightweight alternatives:

• CoAP instead of HTTP – same RESTful style, but 10x less overhead
• MQTT instead of email-style messaging – publish-subscribe pattern that works well with intermittent connections
• 6LoWPAN instead of raw IPv6 – compresses 40-byte headers down to just 2-7 bytes
• UDP instead of TCP – no handshake overhead, perfect for simple sensor readings

The key insight: Every byte you save in protocol overhead translates directly to longer battery life and more data capacity on constrained wireless links.

Putting Numbers to It

For a soil sensor sending a 4-byte temperature reading every 10 minutes (144 messages/day), protocol overhead dramatically impacts battery life:

HTTP/TCP/IPv4 stack (uncompressed): \[ \begin{align*} \text{Total bytes} &= 4 \text{ (payload)} + 50 \text{ (HTTP)} + 20 \text{ (TCP)} + 20 \text{ (IPv4)} + 14 \text{ (Ethernet)} = 108 \text{ bytes} \\ \text{Efficiency} &= \frac{4}{108} = 3.7\% \\ \text{Daily TX} &= 108 \times 144 = 15.5 \text{ KB/day} \end{align*} \]

CoAP/UDP/6LoWPAN stack (compressed): \[ \begin{align*} \text{Total bytes} &= 4 \text{ (payload)} + 4 \text{ (CoAP)} + 4 \text{ (UDP-comp)} + 6 \text{ (6LoWPAN)} + 8 \text{ (802.15.4)} = 26 \text{ bytes} \\ \text{Efficiency} &= \frac{4}{26} = 15.4\% \\ \text{Daily TX} &= 26 \times 144 = 3.7 \text{ KB/day} \end{align*} \]

Battery impact (250 kbps radio, 20 mA TX, 5 µA sleep, 2000 mAh battery):

HTTP stack: \(\frac{108 \times 8 \times 144}{250{,}000} = 0.50\) sec TX/day → 0.003 mAh + 0.12 mAh sleep = 0.123 mAh/day → 44.5 years

CoAP stack: \(\frac{26 \times 8 \times 144}{250{,}000} = 0.12\) sec TX/day → 0.0007 mAh + 0.12 mAh sleep = 0.121 mAh/day → 45.3 years

At this low frequency, sleep current dominates. But at 10-second intervals (8640 messages/day), CoAP yields 40.5 years vs HTTP’s 26.3 years — a 54% improvement from protocol efficiency alone.

---

20.2 Chapter Overview

IoT protocols form the communication backbone that enables billions of connected devices to exchange data reliably and efficiently. Unlike traditional internet protocols designed for desktop computers and servers, IoT protocols must operate within severe constraints: limited memory (kilobytes, not gigabytes), low processing power (MHz, not GHz), battery operation (years, not hours), and unreliable wireless links (10-40% packet loss).

20.2.1 IoT Protocol Stack Architecture

The following diagram shows how IoT protocols map to the familiar TCP/IP layer model, highlighting the lightweight alternatives at each layer:

This comprehensive guide is organized into six focused chapters, each addressing a critical aspect of IoT protocol design and selection:

20.2.2 Chapter Guide

Chapter	Topic	Key Content	Estimated Time
1	Introduction to IoT Protocols	Why IoT needs specialized protocols, protocol stack layers, deployment scenarios	15 min
2	IPv6 and 6LoWPAN	IPv6 addressing for IoT, 6LoWPAN header compression, Thread integration	20 min
3	Application Layer Protocols	CoAP vs MQTT comparison, interactive comparison tools, protocol selection	25 min
4	Protocol Selection Guide	Decision frameworks, comparison matrices, interactive selector tool	20 min
5	Protocol Overhead Analysis	Battery life calculations, overhead comparison, hands-on labs	25 min
6	Real-World Protocol Examples	Tilt maze case study, use case analysis, deployment patterns	20 min

20.2.3 Protocol Selection Decision Tree

Use this decision tree to quickly identify which application-layer protocol best fits your IoT scenario:

20.2.4 Quick Reference: Protocol Stack

20.2.5 Key Concepts at a Glance

Concept	What It Does	Why It Matters
6LoWPAN	Compresses IPv6 headers from 40 bytes to as few as 2 bytes	Enables IPv6 on constrained 802.15.4 networks
CoAP	RESTful protocol over UDP with 4-byte header	10x more efficient than HTTP for IoT
MQTT	Publish-subscribe messaging over TCP	Scales to millions of devices via broker
IPv6	340 undecillion addresses	Every IoT device gets unique global address
RPL	Routing for lossy networks	Builds mesh routes for battery-powered sensors

20.2.6 Learning Path Recommendations

For Beginners: Start with Introduction to IoT Protocols to understand why specialized protocols matter, then proceed to Application Layer Protocols for practical CoAP vs MQTT comparison.

For Practitioners: Jump to Protocol Selection Guide for decision frameworks, then reference Protocol Overhead Analysis for battery life calculations.

For Deep Understanding: Work through all chapters sequentially, completing the hands-on labs in Protocol Overhead Analysis and studying the Real-World Protocol Examples.

---

20.3 Knowledge Check

Test your understanding of IoT protocol fundamentals before diving into the detailed chapters.

20.4

Inline Check: Protocol Layer Placement

Common Pitfalls

Mistake 1: Using HTTP for battery-powered devices. HTTP headers can exceed 700 bytes per request. For a sensor sending 20 bytes of data, that is 97% overhead. Use CoAP (4-byte header) or MQTT (2-byte fixed header) instead.

Mistake 2: Choosing MQTT when you need request/response. MQTT excels at publish-subscribe but is awkward for request/response patterns (you must simulate them with paired topics). If your device needs to query a server and get a direct reply, CoAP’s GET/PUT/POST/DELETE methods are a better fit.

Mistake 3: Ignoring transport-layer impact. TCP’s three-way handshake requires 1.5 round trips (SYN, SYN-ACK, ACK) before any data is sent. On a network with 500ms round-trip time, that is 750 ms of latency and extra power consumption before a single byte of application data is transmitted. UDP-based protocols (CoAP) avoid this entirely.

Mistake 4: Assuming IPv4 is sufficient for IoT. IPv4 provides ~4.3 billion addresses – already exhausted. With projections of 25+ billion IoT devices, IPv6’s 340 undecillion addresses are not optional; they are essential. Design for IPv6 from day one.

Mistake 5: Forgetting about 6LoWPAN fragmentation. If your application data plus compressed headers exceed the 127-byte 802.15.4 frame limit, 6LoWPAN must fragment across multiple frames. Each fragment increases the chance of packet loss. Design payloads to fit in a single frame whenever possible.

---

20.5 Videos

Protocol Stack Overview

Protocol Stack Overview

Lesson 4 — foundational networking concepts used across IoT protocols.

Application Protocols in Context

Application Protocols in Context

Lesson 4 — MQTT vs CoAP vs HTTP vs AMQP and when to use each.

Interactive: Protocol Comparison Simulator

Decision Framework: Choosing Application Layer Protocol

When to use CoAP (Constrained Application Protocol):

Criterion	Assessment	Reason
Device power	Battery-operated (years)	4-byte header + UDP = minimal overhead
Communication pattern	Request-response	RESTful GET/PUT/POST/DELETE fits direct queries
Network type	Lossy mesh (802.15.4)	UDP with CON messages handles loss efficiently
Payload size	Small (< 1 KB)	Efficient for sensor readings
Subscriber count	Few (1-3 endpoints)	Direct addressing avoids broker overhead

Example use case: Soil moisture sensor queried by local gateway every 15 minutes.

---

When to use MQTT (Message Queue Telemetry Transport):

Criterion	Assessment	Reason
Device power	Mains or rechargeable	TCP connection overhead acceptable
Communication pattern	Publish-subscribe	One-to-many data distribution
Network type	Reliable (Wi-Fi, Ethernet)	TCP performs well without frequent retransmissions
Payload size	Variable (bytes to KB)	2-byte header scales with larger messages
Subscriber count	Many (10+ dashboards)	Broker efficiently fans out to subscribers

Example use case: Factory temperature sensors streaming to dashboard, analytics, and alert systems.

---

When to use HTTP (Hypertext Transfer Protocol):

Criterion	Assessment	Reason
Device power	Mains-powered gateway	Large header overhead (100-200 bytes) doesn’t matter
Communication pattern	Cloud integration	Standard REST APIs for enterprise systems
Network type	High-bandwidth (Wi-Fi, Ethernet)	Works well with reliable, fast connections
Payload size	Large (KB to MB)	Overhead negligible for firmware/images
Integration need	Web services	Universal tooling and libraries

Example use case: IoT gateway aggregating 100 sensors and pushing data to cloud via REST API.

---

Decision tree: Start with power budget → If battery (years), choose CoAP. If mains-powered → Check subscriber count. If many subscribers → choose MQTT. If web API integration → choose HTTP. If request-response with few endpoints → choose CoAP.

Hybrid approach: Many real-world systems use CoAP from sensors to gateway, then MQTT from gateway to cloud, combining the efficiency of CoAP for constrained devices with the scalability of MQTT for cloud integration.

Try It: Protocol Overhead Calculator

Adjust the parameters below to see how protocol choice affects overhead efficiency and estimated battery life for a constrained IoT sensor.

viewof payload_size = Inputs.range([1, 100], {value: 4, step: 1, label: "Payload size (bytes)"})
viewof msg_interval = Inputs.range([1, 3600], {value: 600, step: 1, label: "Message interval (seconds)"})
viewof battery_mah = Inputs.range([100, 10000], {value: 2000, step: 100, label: "Battery capacity (mAh)"})
viewof protocol_stack = Inputs.select(
  ["CoAP/UDP/6LoWPAN (802.15.4)", "MQTT/TCP/IPv6 (Wi-Fi)", "HTTP/TCP/IPv4 (Ethernet)"],
  {value: "CoAP/UDP/6LoWPAN (802.15.4)", label: "Protocol stack"}
)

overhead_bytes = {
  if (protocol_stack === "CoAP/UDP/6LoWPAN (802.15.4)") return {app: 4, transport: 4, network: 6, link: 8, label: "CoAP+UDP-comp+6LoWPAN+802.15.4"};
  if (protocol_stack === "MQTT/TCP/IPv6 (Wi-Fi)") return {app: 2, transport: 20, network: 40, link: 34, label: "MQTT+TCP+IPv6+Wi-Fi"};
  return {app: 50, transport: 20, network: 20, link: 14, label: "HTTP+TCP+IPv4+Ethernet"};
}

total_overhead = overhead_bytes.app + overhead_bytes.transport + overhead_bytes.network + overhead_bytes.link
total_packet = payload_size + total_overhead
efficiency = (payload_size / total_packet * 100)
msgs_per_day = Math.floor(86400 / msg_interval)
daily_bytes = total_packet * msgs_per_day
tx_rate_bps = protocol_stack === "CoAP/UDP/6LoWPAN (802.15.4)" ? 250000 : (protocol_stack === "MQTT/TCP/IPv6 (Wi-Fi)" ? 1000000 : 10000000)
tx_current_ma = protocol_stack === "CoAP/UDP/6LoWPAN (802.15.4)" ? 20 : (protocol_stack === "MQTT/TCP/IPv6 (Wi-Fi)" ? 80 : 50)
sleep_current_ua = 5
tx_time_sec = (total_packet * 8 * msgs_per_day) / tx_rate_bps
tx_mah = (tx_time_sec * tx_current_ma) / 3600
sleep_mah = ((86400 - tx_time_sec) * sleep_current_ua / 1000) / 3600
total_daily_mah = tx_mah + sleep_mah
battery_years = battery_mah / total_daily_mah / 365.25

html`<div style="display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin-top: 12px;">
  <div style="background: #f0f7f4; border-left: 4px solid #16A085; padding: 16px; border-radius: 4px;">
    <div style="font-size: 0.85em; color: #7F8C8D;">Protocol Overhead</div>
    <div style="font-size: 1.6em; font-weight: bold; color: #2C3E50;">${total_overhead} bytes</div>
    <div style="font-size: 0.8em; color: #7F8C8D;">App: ${overhead_bytes.app} | Transport: ${overhead_bytes.transport} | Network: ${overhead_bytes.network} | Link: ${overhead_bytes.link}</div>
  </div>
  <div style="background: #fef9f0; border-left: 4px solid #E67E22; padding: 16px; border-radius: 4px;">
    <div style="font-size: 0.85em; color: #7F8C8D;">Payload Efficiency</div>
    <div style="font-size: 1.6em; font-weight: bold; color: #2C3E50;">${efficiency.toFixed(1)}%</div>
    <div style="font-size: 0.8em; color: #7F8C8D;">${payload_size} useful bytes out of ${total_packet} total</div>
  </div>
  <div style="background: #f0f4f8; border-left: 4px solid #3498DB; padding: 16px; border-radius: 4px;">
    <div style="font-size: 0.85em; color: #7F8C8D;">Daily Data Volume</div>
    <div style="font-size: 1.6em; font-weight: bold; color: #2C3E50;">${(daily_bytes / 1024).toFixed(1)} KB/day</div>
    <div style="font-size: 0.8em; color: #7F8C8D;">${msgs_per_day} messages/day at ${total_packet} bytes each</div>
  </div>
  <div style="background: ${battery_years > 5 ? '#f0f7f4' : battery_years > 1 ? '#fef9f0' : '#fdf0f0'}; border-left: 4px solid ${battery_years > 5 ? '#16A085' : battery_years > 1 ? '#E67E22' : '#E74C3C'}; padding: 16px; border-radius: 4px;">
    <div style="font-size: 0.85em; color: #7F8C8D;">Estimated Battery Life</div>
    <div style="font-size: 1.6em; font-weight: bold; color: #2C3E50;">${battery_years.toFixed(1)} years</div>
    <div style="font-size: 0.8em; color: #7F8C8D;">TX: ${tx_mah.toFixed(4)} mAh/day | Sleep: ${sleep_mah.toFixed(4)} mAh/day</div>
  </div>
</div>`

Try It: Protocol Selection Helper

Answer the questions below to get a protocol recommendation for your IoT scenario.

viewof power_source = Inputs.select(
  ["Battery (must last years)", "Rechargeable (charged periodically)", "Mains-powered (always on)"],
  {label: "Power source", value: "Battery (must last years)"}
)
viewof comm_pattern = Inputs.select(
  ["Request-response (query and reply)", "Publish-subscribe (broadcast to many)", "Cloud API integration (REST)"],
  {label: "Communication pattern", value: "Request-response (query and reply)"}
)
viewof subscriber_count = Inputs.select(
  ["1-3 endpoints", "4-10 endpoints", "10+ endpoints or dashboards"],
  {label: "Number of data consumers", value: "1-3 endpoints"}
)
viewof network_type = Inputs.select(
  ["Lossy mesh (802.15.4, Zigbee)", "Reliable wireless (Wi-Fi)", "Wired (Ethernet)"],
  {label: "Network type", value: "Lossy mesh (802.15.4, Zigbee)"}
)

recommendation = {
  let score_coap = 0;
  let score_mqtt = 0;
  let score_http = 0;

  if (power_source === "Battery (must last years)") { score_coap += 3; score_mqtt += 0; score_http += 0; }
  else if (power_source === "Rechargeable (charged periodically)") { score_coap += 2; score_mqtt += 2; score_http += 1; }
  else { score_coap += 1; score_mqtt += 2; score_http += 3; }

  if (comm_pattern === "Request-response (query and reply)") { score_coap += 3; score_mqtt += 0; score_http += 2; }
  else if (comm_pattern === "Publish-subscribe (broadcast to many)") { score_coap += 0; score_mqtt += 3; score_http += 0; }
  else { score_coap += 0; score_mqtt += 1; score_http += 3; }

  if (subscriber_count === "1-3 endpoints") { score_coap += 2; score_mqtt += 1; score_http += 2; }
  else if (subscriber_count === "4-10 endpoints") { score_coap += 1; score_mqtt += 2; score_http += 1; }
  else { score_coap += 0; score_mqtt += 3; score_http += 1; }

  if (network_type === "Lossy mesh (802.15.4, Zigbee)") { score_coap += 3; score_mqtt += 0; score_http += 0; }
  else if (network_type === "Reliable wireless (Wi-Fi)") { score_coap += 1; score_mqtt += 2; score_http += 2; }
  else { score_coap += 0; score_mqtt += 2; score_http += 3; }

  let best = "CoAP";
  let best_score = score_coap;
  let reason = "Lightweight UDP-based protocol ideal for constrained devices with direct request-response needs.";
  if (score_mqtt > best_score) { best = "MQTT"; best_score = score_mqtt; reason = "Broker-based publish-subscribe ideal for scaling to many consumers over reliable networks."; }
  if (score_http > best_score) { best = "HTTP"; best_score = score_http; reason = "Standard REST protocol ideal for mains-powered gateways integrating with cloud APIs."; }

  return {best, score_coap, score_mqtt, score_http, reason};
}

html`<div style="background: #f0f7f4; border: 2px solid #16A085; border-radius: 8px; padding: 20px; margin-top: 12px;">
  <div style="font-size: 0.9em; color: #7F8C8D; margin-bottom: 4px;">Recommended Protocol</div>
  <div style="font-size: 1.8em; font-weight: bold; color: #2C3E50; margin-bottom: 8px;">${recommendation.best}</div>
  <div style="font-size: 0.95em; color: #2C3E50; margin-bottom: 16px;">${recommendation.reason}</div>
  <div style="display: flex; gap: 24px; font-size: 0.85em;">
    <span style="color: ${recommendation.best === 'CoAP' ? '#16A085' : '#7F8C8D'}; font-weight: ${recommendation.best === 'CoAP' ? 'bold' : 'normal'};">CoAP: ${recommendation.score_coap} pts</span>
    <span style="color: ${recommendation.best === 'MQTT' ? '#16A085' : '#7F8C8D'}; font-weight: ${recommendation.best === 'MQTT' ? 'bold' : 'normal'};">MQTT: ${recommendation.score_mqtt} pts</span>
    <span style="color: ${recommendation.best === 'HTTP' ? '#16A085' : '#7F8C8D'}; font-weight: ${recommendation.best === 'HTTP' ? 'bold' : 'normal'};">HTTP: ${recommendation.score_http} pts</span>
  </div>
</div>`

20.6 Concept Relationships

Understanding the IoT protocol landscape requires connecting multiple concepts:

Related Concepts:

• Resource constraints drive protocol design: constrained devices (KB RAM, µA sleep current) need specialized protocols
• Layered architecture enables mixing protocols: CoAP at application layer can run over TCP or UDP
• Overhead efficiency scales inversely with payload size: 4-byte reading makes protocol choice critical
• QoS mechanisms differ by layer: MQTT has application-level QoS, TCP provides transport-level reliability
• Address space exhaustion motivates IPv6: 4.3 billion IPv4 addresses cannot support billions of IoT devices

Prerequisite Knowledge:

• Networking Basics - TCP/IP fundamentals provide context for IoT adaptations
• Layered Models - Understanding OSI/TCP-IP stack clarifies protocol placement

Builds Foundation For:

• Protocol Labs and Selection - Hands-on protocol comparison and selection exercises
• IPv6 and 6LoWPAN - Deep dive into network layer protocols
• CoAP vs MQTT - Application protocol comparison

20.7 See Also

Protocol Specifications:

• RFC 7252 - CoAP - Official CoAP specification
• MQTT v5.0 Specification - MQTT standard
• RFC 6282 - 6LoWPAN Compression - Header compression details

Interactive Tools:

• Protocol Comparison Simulator - Compare protocols side-by-side
• Simulations Hub - Interactive protocol demonstrations

Community Resources:

• CoAP Technology Community - CoAP implementations and tools
• MQTT.org - MQTT resources and broker comparisons

Match IoT Protocols to Their Characteristics

Order the IoT Protocol Stack (Top to Bottom)

Label the Diagram

Code Challenge

20.8 Summary and Key Takeaways

This overview chapter introduced the IoT protocol landscape and the fundamental challenge: traditional internet protocols are too heavy for constrained devices. Here are the essential points to carry forward:

Takeaway	Details
IoT needs specialized protocols	HTTP/TCP assume abundant resources; IoT devices have KB of memory, MHz processors, and coin-cell batteries
The stack has four layers	Application (CoAP, MQTT), Transport (UDP, TCP), Network (IPv6, 6LoWPAN), Link (802.15.4, BLE, LoRa, Wi-Fi)
CoAP = lightweight REST	4-byte header, UDP-based, request/response – ideal for battery-powered devices with infrequent communication
MQTT = scalable pub/sub	2-byte fixed header, TCP-based, broker-mediated – ideal for thousands of devices publishing telemetry
6LoWPAN is essential	Compresses 40-byte IPv6 headers to 2-7 bytes, making IP-based communication possible on 127-byte frames
Protocol choice = battery life	Selecting CoAP over HTTP can extend battery life by 10x or more due to reduced overhead and no TCP handshake

One-sentence summary: IoT protocol selection is not about finding the “best” protocol – it is about matching each layer’s protocol to your specific constraints of power, bandwidth, latency, and scale.

20.9 What’s Next?

Start your journey through IoT protocols with Introduction to IoT Protocols to understand why traditional internet protocols need adaptation for resource-constrained devices.

Next Chapter	Description
Introduction to IoT Protocols	Why IoT needs specialized protocols and the protocol stack layers
IoT Protocols: Fundamentals	Core concepts behind constrained device communication
IPv6 and 6LoWPAN	Network layer addressing and header compression for IoT

Related Chapters

Deep Dives:

• MQTT Fundamentals - Publish-subscribe messaging protocol
• CoAP Architecture - Constrained Application Protocol
• HTTP for IoT - RESTful API design
• AMQP vs MQTT - Enterprise messaging comparison

Comparisons:

• IoT Protocols Review - Comprehensive protocol comparison
• Protocol Selection Framework - Decision tree for protocol choice
• Transport Protocols - TCP vs UDP for IoT

Architecture:

• Layered Network Models - Protocol stack organization
• IoT Reference Models - Where protocols fit in IoT architecture