“Connect to Wi-Fi” works fine for a handful of units on mains power. It stops working as an architecture the moment you’re deploying dozens or hundreds of battery-powered units across a building, a city, or a transit network. At that point, radio choice and protocol choice both become real engineering decisions with a direct, measurable impact on battery life.
This piece expands on the connectivity layer covered in our system architecture guide — the short version there is that the right choice splits along two lines: how dense the deployment is, and whether it’s indoor or outdoor. Here’s the reasoning behind that split, and the protocol layer on top of it.
Two Deployment Patterns, Two Radio Strategies
Indoor, High-Density: Local Gateway Architecture
Retail floors, office buildings, warehouses — anywhere with dozens of units packed into a confined, often RF-crowded space — generally favor a self-built gateway architecture, where units talk to a local gateway over a short-range, low-power radio rather than each maintaining its own wide-area connection.
- Sub-1GHz radio (typically in the 868MHz or 915MHz ISM bands, depending on region) generally provides better indoor propagation characteristics than 2.4GHz, at lower power draw than Wi-Fi. It’s a strong fit where range needs to cover a building floor without every unit fighting for spectrum in an already-crowded 2.4GHz environment.
- BLE Mesh extends Bluetooth Low Energy into a self-healing mesh topology, well suited to dense deployments where units can relay through each other rather than all needing direct line-of-sight to a single gateway.
- Zigbee offers similar mesh capability with a mature, well-established protocol stack — a reasonable choice where you’re integrating into an existing building-automation or IoT ecosystem that already standardizes on it.
The common thread across all three: the expensive part of a wireless connection — maintaining a wide-area or internet-facing link — gets pushed onto the gateway, not carried by every individual unit. That’s most of where the power savings actually comes from, more than any specific radio’s raw efficiency.
Outdoor, Distributed: Wide-Area IoT Radio
Transit stops, city-wide signage, anything spread across a wide geographic area without a shared local gateway, points toward a fundamentally different strategy — each unit needs its own wide-area connection, so that connection needs to be built for infrequent, small-payload, battery-powered use from the ground up.
- LTE-M runs on existing cellular infrastructure with lower power and cost than standard LTE, while still offering reasonable throughput and latency — a good fit when payloads are a bit larger or timing is a bit more sensitive than NB-IoT comfortably handles.
- NB-IoT trades throughput for even lower power and better penetration (including underground or deep-building scenarios), suited to very small, infrequent payloads where LTE-M’s extra capability isn’t needed.
- LoRaWAN trades data rate for genuinely long range — kilometers, not meters — on unlicensed spectrum, meaning no recurring carrier SIM or data plan cost. The trade-off is that it requires its own gateway infrastructure to be deployed and maintained, which is a real one-time cost, but one that can make sense at scale for an operator (a transit agency covering its own city, for instance) already planning to own that infrastructure.
LTE-M and NB-IoT lean on infrastructure someone else already built and maintains, in exchange for an ongoing carrier cost per device. LoRaWAN shifts that cost from recurring to one-time, in exchange for owning the gateway network yourself. Which trade-off makes sense depends heavily on deployment scale and whether you’re already operating in an area with existing LoRaWAN gateway coverage.
Why MQTT or CoAP, Not a REST API
Radio choice determines how a signal gets to a device. Protocol choice determines how much that signal actually costs once it arrives — and this is where a lot of otherwise well-designed e-paper deployments quietly lose battery life.
A full HTTP REST API carries real, avoidable overhead for this use case: a TCP handshake, HTTP headers, and typically a full TCP/IP stack per request. For a device updating a handful of times a day, that overhead might not matter much. For anything updating more frequently, or running on a genuinely constrained radio link (NB-IoT, LoRaWAN), that per-request overhead compounds directly into radio-on time — which is where most of a battery-powered unit’s power budget actually goes.
- MQTT maintains a persistent, lightweight publish/subscribe connection, with a fixed header as small as two bytes for some message types, and configurable quality-of-service levels for tuning reliability against overhead. It’s a strong fit for deployments with reasonably persistent connectivity — Wi-Fi, cellular — where holding a connection open is more efficient than repeatedly re-establishing one.
- CoAP is UDP-based, RESTful in style but with a compact binary header (as little as four bytes), and explicitly designed for constrained devices that don’t want to hold a connection open at all. It pairs naturally with intermittent, duty-cycled links like LoRaWAN or NB-IoT, where a device wakes, sends a small payload, and goes back to sleep rather than maintaining any ongoing connection.
Running a full REST stack over a battery-constrained radio link isn’t usually a deliberate choice — it’s what happens when a connectivity layer gets designed by extending whatever backend API already exists, rather than by asking what the radio link and power budget can actually afford.
Choosing a Stack
| Deployment Pattern | Radio | Protocol | Why |
|---|---|---|---|
| Indoor, high-density, gateway feasible | Sub-1GHz, BLE Mesh, or Zigbee | MQTT (gateway to cloud), lightweight local protocol (device to gateway) | Pushes wide-area connection cost onto the gateway, not each unit |
| Outdoor, distributed, moderate payload/timing needs | LTE-M | MQTT or CoAP | Reasonable throughput on existing cellular infrastructure |
| Outdoor, distributed, minimal payload, deep penetration needed | NB-IoT | CoAP | Lowest power, smallest payloads, no persistent connection required |
| Outdoor, wide-area, no existing cellular dependency wanted | LoRaWAN | CoAP | Longest range, no recurring carrier cost, requires owning gateway infrastructure |
This connects directly back to the power layer and total cost of ownership — radio and protocol choice isn’t just a technical decision, it flows straight into battery life, maintenance cadence, and whether a recurring carrier cost or a one-time gateway investment fits your deployment better. Outdoor, wide-area deployments in particular — see our transit signage solutions — are where this decision matters most.
FAQ
Is Wi-Fi ever the right choice for a large e-paper deployment?
It can be, for smaller or mains-powered deployments, or where existing Wi-Fi infrastructure already covers the site with good signal quality. It becomes a weaker choice specifically as battery-powered unit count and density increase, since Wi-Fi’s power draw is higher than the alternatives covered here.
Do I need to build my own gateway for indoor deployments?
Generally yes, for Sub-1GHz, BLE Mesh, or Zigbee architectures — these protocols are built around a local gateway model rather than direct internet connectivity per unit, so gateway infrastructure is part of the deployment, not optional.
Is LoRaWAN better than cellular IoT (LTE-M/NB-IoT) for outdoor deployments?
Neither is universally better — LoRaWAN avoids recurring carrier costs but requires you to deploy and maintain gateway infrastructure; LTE-M and NB-IoT use existing cellular infrastructure at the cost of an ongoing per-device data plan. The right choice depends on deployment scale and whether you’re already operating LoRaWAN gateway coverage in the area.
Can MQTT and CoAP be used together in the same deployment?
Yes, and it’s common in mixed deployments — for example, CoAP between battery-constrained edge devices and a gateway, with MQTT carrying traffic from the gateway up to the cloud, since the gateway itself doesn’t have the same power constraints as the edge units.