Consider a temperature sensor deployed in a remote agricultural field. It runs on two AA batteries, transmits data every 15 minutes, and needs to operate for 10 years without maintenance. This isn't a hypothetical—it's a real deployment requirement that millions of IoT devices must meet.

The math is unforgiving: two AA batteries contain roughly 2,500 mAh of energy. Over 10 years, that's about 28.5 microamps average current draw. A standard Wi-Fi module consumes 100-300 milliamps when transmitting—10,000 times more than the entire power budget.

This energy constraint shapes everything about low-power IoT protocols. Every bit transmitted, every millisecond of radio activity, every CPU cycle matters. The protocols we'll explore in this page represent decades of research into squeezing maximum functionality from minimal energy budgets.

Before diving into protocols, we must understand where energy goes in a typical IoT device. This knowledge is essential for evaluating protocol efficiency.

Power consumption by component:

A typical IoT device contains:

• Microcontroller (MCU): 1-50 mW active, 0.1-100 μW sleep
• Radio transceiver: 10-300 mW transmit, 10-50 mW receive, 0.1-10 μW sleep
• Sensors: 0.1-50 mW depending on type
• Power regulation: 1-10% overhead

The critical insight: Radio communication dominates power consumption in most IoT devices. A single transmission can consume more energy than hours of microcontroller operation in sleep mode.

Energy budget calculation:

With a 2,500 mAh battery and 37 μAh daily consumption:

• Theoretical lifetime: 2,500,000 μAh ÷ 37 μAh/day = 67,568 days (185 years)

Of course, self-discharge, temperature effects, and real-world inefficiencies reduce this, but the point stands: with proper duty cycling, decade-long battery life is achievable.

The duty cycle concept:

Duty cycle = (Active time) / (Total time) × 100%

Most low-power IoT devices operate with duty cycles below 0.1%. The radio might be active for 10 milliseconds per minute—a 0.017% duty cycle. Protocols must enable meaningful communication within these brief windows.

The MAC (Medium Access Control) layer is critical for low-power operation because it determines when devices transmit, receive, and sleep. Several strategies have evolved:

1. Duty-Cycled MAC Protocols

Devices synchronize to wake up simultaneously for brief periods, then return to sleep. Examples:

• S-MAC (Sensor MAC): Introduces coordinated sleeping schedules. Neighboring nodes synchronize schedules. Active periods are fixed, sleep periods adaptable.

• T-MAC (Timeout MAC): Improves on S-MAC by dynamically ending active periods when no traffic, reducing idle listening.

• B-MAC (Berkeley MAC): Uses low-power listening (LPL). Transmitters send a long preamble; receivers wake briefly to detect preambles, then sleep if none detected.

2. Contention-Based vs. Scheduled Access

Contention-based (CSMA/CA):

• Devices listen before transmitting, back off on collision
• Simple, no central coordination needed
• Energy wasted on idle listening and collisions
• Used by: 802.15.4 unslotted mode, BLE advertising

Scheduled (TDMA-like):

• Time divided into slots assigned to devices
• Eliminates collisions and idle listening
• Requires synchronization (energy cost for clock maintenance)
• Used by: 802.15.4 slotted mode, LoRaWAN Class B

3. IEEE 802.15.4 MAC Modes

The foundation protocol for many IoT stacks offers two modes:

Non-beacon mode (unslotted):

• Always-on coordinators, sleeping end devices
• End devices wake, transmit, and sleep
• Simple but asymmetric (coordinators always powered)

Beacon-enabled mode (slotted):

• Coordinator broadcasts periodic beacons
• Superframe structure: active period + inactive (sleep) period
• Active period contains Contention Access Period (CAP) and Guaranteed Time Slots (GTS)
• Enables precisely scheduled communication

Running IP on constrained devices requires significant adaptation. The IETF developed 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) and RPL (Routing Protocol for Low-Power and Lossy Networks) to enable IP connectivity while respecting energy constraints.

6LoWPAN Header Compression

IPv6 headers are 40 bytes minimum—larger than the entire payload of an 802.15.4 frame (127 bytes maximum). 6LoWPAN uses stateful header compression:

Compression techniques:

• Context-based address compression: Link-local prefixes compressed to context IDs
• Elision of fields: Version, traffic class, flow label often omitted
• Inline vs. derived: Fields derived from lower layers (L2 addresses) not repeated

Results:

• Best case: 40-byte IPv6 + 8-byte UDP → 2-4 bytes
• Typical: 6-15 bytes overhead
• Worst case (full headers): 48+ bytes

RPL: Routing for Low-Power and Lossy Networks

Traditional routing protocols (OSPF, RIP) assume reliable links and always-on routers. RPL is designed for networks where:

• Links are lossy (packet loss common)
• Nodes are energy-constrained (can't maintain neighbor tables)
• Traffic patterns are predictable (sensor → gateway dominant)

DODAG (Destination-Oriented Directed Acyclic Graph):

RPL builds tree-like topologies called DODAGs rooted at border routers (gateways). Each node maintains:

• Rank: Distance metric from root (lower = closer)
• Parent set: Preferred next-hop nodes toward root
• DODAG Information: Version, instance, objective function

Objective Functions:

RPL selects routes based on configurable metrics:

• OF0 (Objective Function Zero): Minimize hop count
• MRHOF (Minimum Rank with Hysteresis): Minimize ETX (Expected Transmission Count), accounting for link reliability
• Energy-aware OFs: Consider remaining battery, transmission cost

Trickle Algorithm:

RPL uses Trickle for control message suppression:

• When network is stable, control traffic exponentially decreases
• When changes occur, transmission rate increases
• Dramatically reduces energy consumption in steady state

HTTP is the backbone of web communication but is too heavy for constrained devices. CoAP (Constrained Application Protocol, RFC 7252) provides REST-like semantics optimized for IoT:

Design principles:

• Binary format (vs. HTTP's text)
• Compact 4-byte base header
• UDP-based (vs. TCP) with optional reliability
• Built-in resource observation
• Mapping to HTTP for proxy integration

CoAP Message Format:

Message Types:

1. Confirmable (CON): Requires acknowledgment; retransmitted if no ACK
2. Non-confirmable (NON): Fire-and-forget; no reliability
3. Acknowledgment (ACK): Confirms CON receipt
4. Reset (RST): Indicates processing error

Request Methods (analogous to HTTP):

• GET: Retrieve resource
• POST: Create resource or trigger action
• PUT: Update resource
• DELETE: Remove resource

Response Codes (analogous to HTTP status):

• 2.xx: Success (2.01 Created, 2.04 Changed, 2.05 Content)
• 4.xx: Client error (4.04 Not Found, 4.05 Method Not Allowed)
• 5.xx: Server error (5.00 Internal Server Error)

The Observe Option: Push Notifications for IoT

Polling wastes energy—devices must repeatedly query for updates. CoAP's Observe option enables server-push semantics:

1. Client sends GET with Observe option (value 0 = register)
2. Server responds with current value AND registers the observer
3. When resource changes, server sends notifications with Observe sequence numbers
4. Client sends GET with Observe=1 to deregister

This model is perfect for sensor monitoring—a temperature sensor can notify only when values change, rather than responding to constant polling.

Block-wise Transfer:

UDP has no built-in fragmentation for application data. CoAP's Block option enables large payload transfer:

• Payloads divided into blocks (typically 16-1024 bytes)
• Block1 for request payloads, Block2 for responses
• Each block individually acknowledged
• Random access possible (request specific block)

While CoAP follows the request-response paradigm familiar from HTTP, many IoT applications are better served by publish-subscribe messaging. MQTT (Message Queuing Telemetry Transport) has become the dominant protocol for this use case.

MQTT Architecture:

MQTT uses a broker-based publish-subscribe model:

• Publishers: Devices that send messages to topics
• Subscribers: Devices that receive messages from topics
• Broker: Central server that routes messages between publishers and subscribers
• Topics: Hierarchical strings (e.g., building/floor1/room101/temperature)

This decoupling offers significant advantages:

• Publishers and subscribers don't need to know about each other
• Temporal decoupling: messages queued if subscriber offline
• Scalability: broker handles N:M routing efficiently

MQTT QoS Levels:

MQTT defines three quality-of-service levels for message delivery:

QoS 0: At most once (Fire and forget)

• Message sent once, no acknowledgment
• May be lost if network fails
• Lowest overhead, suitable for frequent sensor readings where loss is acceptable

QoS 1: At least once (Acknowledged delivery)

• Publisher sends, broker acknowledges (PUBACK)
• Retransmit if no ACK received
• May cause duplicates (subscriber must handle)
• Good balance for most IoT applications

QoS 2: Exactly once (Assured delivery)

• Four-way handshake: PUBLISH → PUBREC → PUBREL → PUBCOMP
• Guarantees no loss and no duplication
• Highest overhead, used for critical messages (payments, commands)

Keep-Alive and Last Will:

MQTT provides connection health mechanisms:

• Keep-alive: Client sends PINGREQ if no other traffic; broker responds PINGRESP. Detects silent disconnections.
• Last Will and Testament (LWT): Client registers a message to be published by broker if connection drops unexpectedly. Enables presence detection.

MQTT-SN: MQTT for Sensor Networks

Standard MQTT runs over TCP, which is too heavy for the most constrained devices. MQTT-SN adapts MQTT for UDP-based sensor networks:

Key differences from MQTT:

• UDP transport: Eliminates TCP overhead
• Short topic IDs: 2-byte IDs replace full topic strings after registration
• Gateway architecture: MQTT-SN clients connect to gateways that bridge to MQTT brokers
• Sleeping clients: Built-in support for duty-cycled devices with buffered messages
• Forwarder support: Enables MQTT-SN over non-IP networks (Zigbee, etc.)

Managing millions of constrained devices requires standardized protocols for configuration, firmware updates, and monitoring. LwM2M (Lightweight Machine-to-Machine), developed by OMA SpecWorks, provides this infrastructure.

LwM2M Architecture:

LwM2M runs on top of CoAP and defines:

• LwM2M Server: Management platform for device fleets
• LwM2M Client: Software running on each IoT device
• Bootstrap Server: Initial provisioning and server credential distribution

Object and Resource Model:

LwM2M organizes device capabilities into a hierarchical structure:

/{Object ID}/{Object Instance}/{Resource ID}

The OMA maintains a registry of standard objects:

• Object 0: LwM2M Security (bootstrap/server credentials)
• Object 1: LwM2M Server (registration, binding, notifications)
• Object 3: Device (manufacturer, model, serial, firmware version)
• Object 4: Connectivity Monitoring (signal strength, IP addresses)
• Object 5: Firmware Update (package URI, update state, result)
• Object 6: Location (latitude, longitude, altitude)

Vendors define custom objects for device-specific capabilities.

LwM2M Operations:

1. Bootstrap: Device connects to bootstrap server for initial credentials
2. Registration: Device registers with LwM2M server, listing supported objects
3. Device management: Server reads/writes device resources
4. Information reporting: Device sends observations and notifications
5. Firmware update: Server triggers OTA update via firmware object

Queue Mode for Low-Power Devices:

LwM2M 1.1 introduced Queue Mode for duty-cycled devices:

• Device registers with "Q" binding mode
• Server queues commands while device sleeps
• On wake, device sends update; server delivers queued commands
• Enables management of devices sleeping 99%+ of the time

Security:

LwM2M security modes:

• Pre-Shared Key (PSK): Simple, suitable for constrained devices
• Raw Public Key (RPK): No certificate overhead, public key pinning
• Certificate (X.509): Full PKI integration for enterprise deployments

For truly perpetual operation, some IoT devices harvest energy from the environment rather than relying solely on batteries. This introduces new protocol considerations.

Energy Harvesting Sources:

• Solar: 10-100 mW/cm² (outdoor), 10-100 μW/cm² (indoor)
• Kinetic (vibration): 1-10 mW from industrial equipment
• Thermal (TEG): 20-40 μW/cm² per °C differential
• RF harvesting: 1-100 μW from ambient WiFi, cellular

The challenge: harvested energy is intermittent and unpredictable. A cloud passing over a solar cell can drop power 90% instantly.

Energy-Aware Protocol Adaptations:

Dynamic duty cycling:

• Sample energy storage (supercapacitor voltage)
• Increase transmission frequency when energy abundant
• Reduce to survival mode when energy scarce

Energy-neutral operation:

• Match average power consumption to average harvested power
• Buffer energy in supercapacitors for burst transmission
• Predict future energy availability (weather, patterns)

Adaptive quality degradation:

• Reduce sensor sampling rate when low energy
• Use lower-power (lower-fidelity) sensors
• Aggregate more data before transmission

We've explored the protocols and mechanisms enabling decade-long battery life in IoT devices. Let's consolidate the key takeaways:

What's next:

Now that we understand low-power protocol foundations, we'll examine one of the most important LPWAN technologies in detail: LoRaWAN. The next page explores how LoRa's chirp spread spectrum modulation and LoRaWAN's MAC layer enable kilometer-range communication from battery-powered sensors.