19 IEEE and IETF IoT Standards

In 60 Seconds

IEEE 802.15.4 defines the physical/MAC layers for low-power IoT (foundation for Zigbee, Thread, 6LoWPAN). CoAP brings REST to constrained devices using UDP with 4-byte headers, while 6LoWPAN compresses IPv6 headers from 40 bytes to 2-7 bytes, enabling IP connectivity on devices with 127-byte packet limits.

Minimum Viable Understanding

IEEE 802.15.4 defines the physical and MAC layers for low-power IoT, serving as the foundation for Zigbee, Thread, and 6LoWPAN.
CoAP (IETF) brings REST-like communication to constrained devices using UDP with just 4-byte headers, while MQTT provides reliable publish-subscribe messaging with three QoS levels.
6LoWPAN compresses IPv6 headers from 40 bytes down to 2-7 bytes, enabling IP connectivity on tiny devices with 127-byte packet limits.

19.1 Learning Objectives

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

Classify key IEEE standards shaping IoT physical and data link layers (802.15.4, P2413)
Explain how IEEE 802.15.4 serves as the foundation for Zigbee, Thread, and WirelessHART
Evaluate IETF protocols (CoAP, MQTT, 6LoWPAN) for constrained IoT environments
Contrast CoAP and HTTP for resource-constrained device communication
Select appropriate MQTT QoS levels based on delivery guarantees and use case requirements
Calculate 6LoWPAN header compression savings for IPv6 over IEEE 802.15.4

19.2 Prerequisites

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

IoT Reference Models: Understanding layered architectures helps you see how standards apply at different system levels
IoT Protocols Overview: Basic protocol knowledge helps you understand why standardization matters

Related Chapters & Resources

Protocol Standards:

CoAP Protocol - IETF constrained protocol
MQTT Protocol - Messaging standard

Networking Standards:

Zigbee - IEEE 802.15.4 based
Thread - IP-based mesh

Sensor Squad: The Standards Superheroes

Sammy the Sensor was confused. “I want to talk to Lila the LED, but she speaks a different language! How do we understand each other?”

Max the Microcontroller smiled. “That’s what standards are for! Think of them like the rules of a language. If we all agree to follow the same rules, we can all understand each other – even if we’re made by different companies!”

“Like how everyone uses the same alphabet?” asked Bella the Battery.

“Exactly!” said Max. “IEEE 802.15.4 is like the alphabet for tiny, low-power devices like us. It tells us HOW to send signals through the air. Then CoAP is like a simple way to ask questions and get answers – like raising your hand in class. And MQTT is like a bulletin board where you post messages and anyone who cares can read them!”

Sammy beamed. “So standards are the rules that let ALL sensors, LEDs, and microcontrollers be friends – even if they come from different factories!”

“And that saves MY energy,” added Bella. “Because when everyone follows the same rules, we don’t waste power trying to figure out how to talk!”

For Beginners: What Are IoT Standards?

Standards are agreed-upon rules that ensure devices from different manufacturers can communicate. Think of them like road traffic rules – everyone drives on the same side of the road so there are no collisions.

In IoT, two main organizations create standards:

IEEE (Institute of Electrical and Electronics Engineers): Defines how devices physically send radio signals (like which radio frequencies to use and how to share airtime)
IETF (Internet Engineering Task Force): Defines how devices communicate over the internet (like how to send a sensor reading to a cloud server)

Without standards, every manufacturer would create their own incompatible system, and your smart thermostat from one brand could never work with your smart lights from another brand.

19.3 IEEE IoT Standards

The Institute of Electrical and Electronics Engineers (IEEE) develops foundational standards for physical layer and data link layer communications, as well as higher-level IoT architecture frameworks.

19.3.1 IEEE 802.15.4: The Foundation of Low-Power IoT

IEEE 802.15.4 defines the physical layer (PHY) and media access control (MAC) layer for low-rate wireless personal area networks (LR-WPANs). It serves as the foundation for:

Zigbee: Home automation and smart building protocols
Thread: IP-based mesh networking for smart home
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Networks
WirelessHART: Industrial process automation

Three protocol stacks showing Zigbee with ZCL clusters, Thread with CoAP/IPv6, and WirelessHART with HART commands, all sharing the IEEE 802.15.4 PHY and MAC layers as their common foundation — Figure 19.1: Protocol stacks built on IEEE 802.15.4: Zigbee, Thread, and WirelessHART share the same PHY and MAC layers (highlighted) but implement different network and application layers for their specific use cases.

19.3.1.1 Key 802.15.4 Characteristics

Feature	Specification
Frequency Bands	868 MHz (EU), 915 MHz (US), 2.4 GHz (Global)
Data Rate	20-250 kbps
Range	10-100 meters typical
Topology	Star, Peer-to-Peer, Mesh
Power	Designed for battery operation (years)
Addressing	16-bit short or 64-bit extended

19.3.2 IEEE P2413: IoT Architectural Framework

IEEE P2413 provides an architectural framework for IoT, defining:

Abstraction layers for IoT system decomposition
Common terminology across domains
Cross-domain interaction patterns
Trust and security considerations

IEEE P2413 architecture diagram showing smart home, healthcare, and industrial domains connecting to a common framework that provides abstraction layers, security framework, and interoperability guidelines — Figure 19.2: IEEE P2413 provides a common framework enabling cross-domain IoT interoperability through shared abstraction layers, security frameworks, and interoperability guidelines.

19.4 IETF Protocols for IoT

The Internet Engineering Task Force (IETF) develops protocols for constrained IoT environments, focusing on bringing IP connectivity to resource-limited devices.

19.4.1 CoAP: Constrained Application Protocol

CoAP (RFC 7252) is a specialized web transfer protocol for constrained nodes and networks:

Sequence diagram showing a sensor sending a CoAP GET request over UDP to a gateway, which translates it to HTTP for cloud communication, then returns the response back through the proxy chain — Figure 19.3: CoAP request/response flow showing protocol translation at the gateway: constrained devices use lightweight CoAP over UDP while the gateway proxies to HTTP for cloud services.

19.4.1.1 CoAP vs HTTP Comparison

Feature	CoAP	HTTP
Transport	UDP (default)	TCP
Header Size	4 bytes fixed	Variable (100+ bytes typical)
Message Model	Request/Response + Observe	Request/Response
Methods	GET, POST, PUT, DELETE	Full REST
Caching	ETags, Max-Age	Full HTTP caching
Discovery	/.well-known/core	Various mechanisms
Security	DTLS	TLS

19.4.2 MQTT: Message Queuing Telemetry Transport

MQTT (ISO/IEC 20922, OASIS Standard) is a publish-subscribe messaging protocol designed for constrained devices and low-bandwidth networks:

MQTT architecture diagram showing three publishers (temperature, humidity, motion sensors) publishing to topics on a central broker, which distributes messages to three subscribers (dashboard, analytics, alerts) based on their topic subscriptions — Figure 19.4: MQTT publish-subscribe architecture: sensors publish to topic hierarchies on a central broker, subscribers receive messages by topic subscription, enabling decoupled communication patterns.

19.4.2.1 MQTT QoS Levels

QoS Level	Name	Guarantee	Use Case
0	At most once	Fire and forget	High-frequency telemetry
1	At least once	Delivered, may duplicate	General sensor data
2	Exactly once	Delivered exactly once	Critical commands, billing

19.4.3 6LoWPAN and IPv6 for IoT

6LoWPAN (RFC 4944, RFC 6282) enables IPv6 over IEEE 802.15.4 networks:

Comparison showing standard IPv6 header (40 bytes) plus UDP header (8 bytes) being compressed by 6LoWPAN to only 2-7 bytes using IPHC and NHC compression, critical for the 127-byte MTU of 802.15.4 — Figure 19.5: 6LoWPAN header compression: standard IPv6+UDP headers (48 bytes) are compressed to 2-7 bytes using IPHC/NHC, essential for fitting within IEEE 802.15.4’s 127-byte MTU.

19.4.3.1 6LoWPAN Key Features

Feature	Description
Header Compression	IPHC reduces IPv6 header from 40 to 2-7 bytes
Fragmentation	Handles packets larger than 127-byte MTU
Mesh Addressing	Supports multi-hop routing at link layer
Neighbor Discovery	Optimized for low-power networks

Putting Numbers to It

Let’s calculate the bandwidth and energy savings from 6LoWPAN header compression for a WSN with 100 sensors transmitting every 10 minutes.

Without 6LoWPAN (standard IPv6 + UDP):

\[\text{Header size} = 40\text{ bytes (IPv6)} + 8\text{ bytes (UDP)} = 48\text{ bytes}\]

With 10-byte sensor payload: Total packet = 48 + 10 = 58 bytes

With 6LoWPAN IPHC/NHC compression:

\[\text{Compressed headers} = 2\text{-}7\text{ bytes (typical: 4 bytes)}\]

Total packet = 4 + 10 = 14 bytes (76% smaller!)

Bandwidth savings over one day:

\[N_{\text{messages}} = 100\text{ sensors} \times \frac{24 \times 60}{10}\text{ messages/day} = 14,400\text{ messages/day}\]

\[\text{Bandwidth}_{\text{uncompressed}} = 14,400 \times 58 = 835,200\text{ bytes} = 815\text{ KB/day}\]

\[\text{Bandwidth}_{\text{6LoWPAN}} = 14,400 \times 14 = 201,600\text{ bytes} = 197\text{ KB/day}\]

Savings: 618 KB/day (76%), or 226 MB/year

Energy savings: Radio energy is proportional to bytes transmitted. At 250 kbps (802.15.4):

\[T_{\text{tx, uncompressed}} = \frac{58 \times 8\text{ bits}}{250,000\text{ bps}} = 1.86\text{ ms}\]

\[T_{\text{tx, 6LoWPAN}} = \frac{14 \times 8\text{ bits}}{250,000\text{ bps}} = 0.45\text{ ms}\]

At 20 mA TX current, 3V supply (P = 60 mW):

\[E_{\text{uncompressed}} = 60\text{ mW} \times 1.86\text{ ms} = 111.6\text{ µJ}\]

\[E_{\text{6LoWPAN}} = 60\text{ mW} \times 0.45\text{ ms} = 27.0\text{ µJ}\]

Result: 111.6 µJ vs 27.0 µJ = 76% energy savings per transmission!

Interactive 6LoWPAN Savings Calculator: Explore how compression saves bandwidth and energy:

Show code

{
  const ipv6Header = 40;
  const udpHeader = 8;
  const compressedHeader = 4; // typical 6LoWPAN
  const uncompressedTotal = ipv6Header + udpHeader + payloadBytes;
  const compressedTotal = compressedHeader + payloadBytes;
  const msgsPerDay = numSensors6lo * (24 * 60 / reportIntervalMin);
  const rawKBPerDay = (msgsPerDay * uncompressedTotal) / 1024;
  const compKBPerDay = (msgsPerDay * compressedTotal) / 1024;
  const savingsPct = ((rawKBPerDay - compKBPerDay) / rawKBPerDay * 100);
  const txPowerMW = 60; // 20mA x 3V
  const dataRateBps = 250000;
  const rawEnergyUJ = txPowerMW * (uncompressedTotal * 8 / dataRateBps) * 1000;
  const compEnergyUJ = txPowerMW * (compressedTotal * 8 / dataRateBps) * 1000;

  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB; margin-top: 0.5rem;">
    <p><strong>Packet size:</strong> Without 6LoWPAN: ${uncompressedTotal} bytes | With 6LoWPAN: ${compressedTotal} bytes</p>
    <p><strong>Daily bandwidth:</strong> ${rawKBPerDay.toFixed(0)} KB/day → ${compKBPerDay.toFixed(0)} KB/day (${savingsPct.toFixed(0)}% reduction)</p>
    <p><strong>Energy per TX:</strong> ${rawEnergyUJ.toFixed(1)} µJ → ${compEnergyUJ.toFixed(1)} µJ (at 250 kbps, 60 mW TX)</p>
  </div>`;
}

19.5 Worked Example: Protocol Stack Cost for a Smart Office Floor

Scenario: A property management company is deploying environmental sensors across one floor (2,000 m²) of a commercial office building in London. The floor has 40 desks, 4 meeting rooms, and 2 open-plan zones.

Requirements:

60 sensors: temperature, humidity, CO₂, occupancy (PIR)
Report every 5 minutes to a cloud dashboard
5-year battery target on CR2032 coin cells (225 mAh)
Budget: under GBP 8,000 total

Protocol Stack Comparison:

Layer	Option A: Wi-Fi + HTTP	Option B: 802.15.4 + 6LoWPAN + CoAP	Option C: BLE + MQTT-SN
Physical/MAC	802.11n (Wi-Fi)	IEEE 802.15.4 (Zigbee PHY)	Bluetooth 5.0 LE
Network	TCP/IP	6LoWPAN + IPv6	BLE mesh (no IP)
Application	HTTP REST	CoAP (4-byte header)	MQTT-SN
TX power per msg	200 mW x 120 ms = 24 mJ	10 mW x 15 ms = 0.15 mJ	12 mW x 3 ms = 0.036 mJ
Msg overhead	300+ bytes (HTTP header)	12 bytes (CoAP + 6LoWPAN)	20 bytes (MQTT-SN)
Battery life	~3 months	~4.8 years	~6.2 years
Gateway needed?	No (direct Wi-Fi)	Yes – border router	Yes – BLE-to-IP gateway
Per-sensor cost	GBP 18 (ESP32)	GBP 8 (CC2530)	GBP 6 (nRF52832)
Gateway cost	GBP 0	GBP 120 x 2 = GBP 240	GBP 85 x 3 = GBP 255

Total 5-Year Cost (including battery replacements):

Cost Component	Wi-Fi + HTTP	802.15.4 + CoAP	BLE + MQTT-SN
60 sensors	GBP 1,080	GBP 480	GBP 360
Gateways	GBP 0	GBP 240	GBP 255
Batteries (5 yr)	60 x 16 replacements x GBP 1.50 = GBP 1,440	60 x 0 replacements = GBP 0	60 x 0 replacements = GBP 0
Maintenance labour	16 visits x GBP 200 = GBP 3,200	0 visits = GBP 0	0 visits = GBP 0
Total	GBP 5,720	GBP 720	GBP 615

Decision: Option B (IEEE 802.15.4 + 6LoWPAN + CoAP) is selected despite not being cheapest, because:

IPv6 end-to-end: Every sensor gets a routable IPv6 address – no proprietary gateway translation
Standards-based: 6LoWPAN (RFC 6282) and CoAP (RFC 7252) are IETF standards with multi-vendor support
Zero battery replacements: 4.8-year battery life meets the 5-year target (BLE exceeds it but lacks IP addressability)
160x less energy per message than Wi-Fi, thanks to 6LoWPAN compressing 40-byte IPv6 headers to 2-7 bytes

Key Insight: The cheapest hardware (BLE) is not always the best choice. The protocol stack determines long-term interoperability, and IEEE/IETF standards (802.15.4 + 6LoWPAN + CoAP) provide the strongest guarantee against vendor lock-in.

Match IEEE/IETF Standards to Their Functions

Order: Protocol Stack for Constrained IoT Sensor

Place these protocol layers in the correct order from bottom (physical) to top (application).

Key Concepts

IEEE 802.11 (Wi-Fi): The IEEE standard family for wireless LAN communication, with IoT-relevant variants including 802.11ah (Wi-Fi HaLow, sub-GHz, 1 km range) and 802.11ax (Wi-Fi 6, improved IoT density support)
IEEE 802.15.4: The foundational low-rate WPAN standard defining physical and MAC layers for Zigbee, Thread, WirelessHART, and ISA100 — specifying 250 kbps at 2.4 GHz with CSMA-CA channel access
6LoWPAN (RFC 4944): The IETF adaptation layer enabling IPv6 packets to be carried over 802.15.4 networks through header compression, fragmentation, and mesh addressing — enabling IoT devices to be first-class IP citizens
CoAP (RFC 7252): The Constrained Application Protocol — a lightweight RESTful protocol for constrained IoT devices using UDP transport with optional reliability, observe mode for push subscriptions, and DTLS security
DTLS (RFC 6347): Datagram Transport Layer Security — TLS adapted for UDP-based IoT protocols (CoAP, DTLS-SRTP) providing authentication and encryption for constrained devices that cannot maintain TCP connections
RPL (RFC 6550): The IETF Routing Protocol for Low-Power and Lossy Networks using a Destination-Oriented Directed Acyclic Graph (DODAG) topology for mesh routing in IEEE 802.15.4 networks
CBOR (RFC 7049): Concise Binary Object Representation — a binary data format 50–80% smaller than JSON, standardized by IETF for IoT data encoding where bandwidth and memory are constrained

Common Pitfalls

1. Confusing IEEE 802.15.4 with ZigBee

IEEE 802.15.4 defines only the physical and MAC layers. Zigbee, Thread, and WirelessHART are separate specifications built on top of 802.15.4 — a 802.15.4-compliant radio chip requires additional protocol stack software to run Zigbee or Thread.

2. Using CoAP Without Considering Reliability Requirements

CoAP over UDP is unreliable by default. For IoT commands requiring acknowledgment (e.g., “turn off valve”), use CoAP confirmable messages (CON) which provide application-layer acknowledgment. For fire-and-forget telemetry, non-confirmable (NON) messages are appropriate.

3. Not Using 6LoWPAN Compression for IPv6 IoT

Sending full 40-byte IPv6 headers over 802.15.4 networks with 127-byte maximum frame size wastes 31% of capacity just on headers. 6LoWPAN header compression reduces IPv6 headers to 2–3 bytes. Always enable 6LoWPAN compression in IEEE 802.15.4/IPv6 IoT stacks.

4. Treating IETF RFCs as Optional Suggestions

Implementing partial RFC compliance (e.g., only supporting CoAP GET, ignoring PUT/POST/DELETE) and expecting interoperability with other CoAP implementations. RFC compliance is binary — partial implementations break interoperability with conformant devices.

Label the Diagram

💻 Code Challenge

19.6 Summary

19.6.1 Key Takeaways

IEEE 802.15.4 provides the physical and MAC layer foundation for low-power IoT protocols including Zigbee, Thread, and WirelessHART
IEEE P2413 defines an architectural framework enabling cross-domain IoT interoperability
CoAP brings REST semantics to constrained devices with 4-byte headers and UDP transport
MQTT provides reliable publish-subscribe messaging with three QoS levels for different reliability requirements
6LoWPAN enables IPv6 over IEEE 802.15.4 through aggressive header compression

19.7 Knowledge Check

Quiz: IEEE and IETF IoT Standards

19.8 What’s Next

If you want to…	Read this
Learn about industry consortiums and alliances	Industry Consortiums for IoT
Apply a selection framework for your project	Standard Selection and Certification
Understand CoAP and MQTT protocol integration	Application Protocol Integration
Study IoT standards frameworks overview	IoT Standards and Frameworks
Explore routing protocols for IoT meshes	RPL and Mesh Routing