IoT Network Protocols Explained: MQTT, CoAP, LoRaWAN, BLE and More

Updated on Oct 13, 2026

11 min read

IoT protocols let sensors, gateways, and services exchange measurements and commands, but the phrase covers technologies at several different layers. Bluetooth Low Energy (BLE) and LoRaWAN connect devices over radio; MQTT and CoAP define how applications exchange messages. They solve different problems and are often combined in one system.

This guide explains the layers, trade-offs, and security boundaries behind common IoT network protocols. Use it to map a device’s power, coverage, latency, and data needs to a practical design, then try the local MQTT example in the deployment guide below.

What Are IoT Network Protocols?

An IoT protocol is an agreed set of rules for communication between connected devices and software. The rules may describe how bits travel over a radio, how devices receive network addresses, how messages are delivered, or how an application represents a measurement.

There is no single protocol that connects every IoT device. A battery sensor might send a short BLE advertisement to a phone; the phone can forward its reading to a cloud service with HTTPS. An industrial sensor might use an IP network and publish to an MQTT broker. The chosen stack is a set of compatible layers, not one all-in-one standard.

Why Protocol Choice Matters

IoT devices often have stricter limits than laptops and servers. A battery-powered sensor may wake briefly, send a small reading, and sleep again. A remote meter may have weak cellular coverage, while a building controller may need a local response even when the internet is down. Choosing a protocol without those constraints in mind can waste energy, increase recurring connectivity costs, or make the system unreliable.

Protocol choices also affect system boundaries. A radio may only reach a gateway, an application protocol may depend on a cloud broker, and device-management software may handle enrollment and firmware updates separately. Teams need to plan for security, failure recovery, interoperability, and operations across the entire path.

How IoT Communication Works

A typical device-to-service path crosses several layers:

sensor or actuator
  -> local link or radio (BLE, Wi-Fi, 802.15.4, LoRaWAN, or cellular)
  -> IP network and transport, where available (IPv6, TCP, or UDP)
  -> application messaging (MQTT, CoAP, or HTTPS)
  -> gateway, broker, or cloud service
  -> storage, alerting, and device-management applications

Not every system uses every layer in the same way. LoRaWAN networks, for example, use gateways to relay radio packets to a network server; the end device does not necessarily speak IP to that gateway. BLE devices often communicate with a phone or local gateway before any cloud connection exists. By contrast, Wi-Fi and Thread can carry IP traffic, allowing an application protocol to run over the local network.

Gateways can translate protocols, buffer messages during an outage, filter noisy readings, and enforce a boundary between a local device network and cloud services. Translation must preserve meaning as well as bytes: a gateway that maps a sensor’s units, identity, timestamps, or command semantics incorrectly can create data that is syntactically valid but operationally wrong.

For cloud messaging, an MQTT client publishes to a topic on a broker, and interested subscribers receive the message. CoAP instead exposes resources using a compact request/response model; its Observe extension (RFC 7641) lets a client subscribe to resource changes. In both designs, transport delivery is only one part of the system: applications still need to decide how to handle stale readings, duplicate events, offline devices, and failed commands.

Components and Protocol Variants

Connectivity and link choices

These options establish a nearby or wide-area connection. They are not direct substitutes for application protocols such as MQTT.

Connectivity option	Typical role	Strengths	Important constraints
BLE	Short-range device-to-phone or device-to-gateway links	Widely supported on phones; suitable for intermittent, low-volume exchanges	Range and throughput depend on hardware and surroundings; a gateway is often needed for cloud access
IEEE 802.15.4 with Thread	Low-power local mesh networking	IPv6-based networking can support direct IP communication across a local mesh	Requires compatible devices and border-router infrastructure
LoRaWAN	Wide-area, low-data-rate sensor connectivity	Useful for small, infrequent readings where long range and battery life matter	Payload, airtime, downlink, regional radio, and coverage limits affect design
NB-IoT or LTE-M	Cellular wide-area connectivity	Operator-managed coverage and mobility options	Coverage, module power use, subscription cost, and operator support vary
Wi-Fi or Ethernet	Local IP connectivity	Familiar infrastructure and broad application-protocol support	Wi-Fi can draw more power; wired connections are not always practical for distributed sensors

LoRaWAN uses a star-of-stars network in which gateways relay radio traffic between end devices and a network server. Its overview from the LoRa Alliance is a useful starting point; regional rules and network coverage still need to be checked for a real deployment. For BLE, consult the Bluetooth Core Specification and the device’s supported profiles. BLE commonly uses the Generic Attribute Profile (GATT), where services group characteristics that a client can read, write, or subscribe to.

Application messaging choices

Protocol	Communication model	Often fits	Trade-offs
MQTT	Broker-based publish/subscribe	Telemetry and decoupled messaging across many devices or services	Requires a reachable broker and topic-level authorization; TCP connections and sessions have operational costs
CoAP	Compact REST-style requests and responses; Observe for change notifications	Constrained devices and local control where compact exchanges matter	UDP deployments need appropriate loss and congestion handling; security and network traversal require deliberate design
HTTP/HTTPS	Direct request/response APIs	Cloud integration, device management endpoints, and systems with existing web tooling	Headers and connection behavior can be expensive for very constrained or frequently sleeping devices
AMQP	Brokered messaging with routing and delivery features	Enterprise integration and backend messaging	Often adds more infrastructure or implementation complexity than a small sensor needs
DDS	Data-centric publish/subscribe with configurable quality of service	Real-time and distributed systems with matching requirements	Requires compatible middleware and a design suited to its discovery and data model

MQTT is specified by OASIS. Its QoS levels describe protocol delivery: QoS 0 is at most once, QoS 1 is at least once and can produce duplicates, and QoS 2 coordinates exactly-once delivery between MQTT participants. None of these guarantees that a downstream application has committed a business operation exactly once. Consumers should make important processing idempotent.

CoAP is defined in RFC 7252. It is commonly associated with UDP, but RFC 8323 also defines ways to carry CoAP over TCP and TLS. Confirmable UDP messages provide retransmission and acknowledgment behavior, but an application still needs sensible timeouts and congestion behavior. OSCORE (RFC 8613) provides object security for CoAP messages, including scenarios where intermediaries forward traffic.

Device management is another concern, not just a way to move application data. Lightweight M2M (LwM2M), for example, defines fleet-management functions such as registering devices, reading resources, and managing firmware updates. A deployment can use one technology for local connectivity, another for telemetry, and a management protocol or service for the device lifecycle.

Real-World Use Cases

Room sensor reporting temperature: BLE can connect a low-power sensor to a phone or hub; MQTT or HTTPS can then carry normalized readings to a backend. If the sensor has reliable local IP connectivity, it may publish directly.
Remote soil or water monitoring: LoRaWAN or cellular IoT can carry small, infrequent readings over a wide area. Plan for coverage surveys, battery behavior, regional radio limits, downlink needs, and what the device should do when it cannot send.
Smart lighting or building control: A local mesh such as Thread can keep device control within the site. A gateway can relay selected state and events to cloud services without making local control depend on internet availability.
Factory telemetry and robotics: Sensors and controllers may use industrial networks or data-centric middleware locally, while a gateway routes selected events to MQTT or HTTPS services. ROS 2 systems commonly use DDS-based communication, described in this ROS 2 introduction.

These examples are starting points, not fixed recipes. Measure the actual radio environment, device sleep schedule, message size, security requirements, and cost model before selecting hardware or a provider.

Practical Considerations

Choose the stack from requirements

Start by writing down the application’s limits and failure behavior:

Power and duty cycle: How often can the device wake and communicate? Include scanning, retries, keep-alives, and reconnection cost.
Coverage and mobility: Is the device indoors, moving, or beyond local network reach? Verify real coverage rather than relying on nominal range.
Payload and frequency: Estimate message size, reporting interval, bursts, and downlink traffic. Tiny, infrequent payloads favor different choices from continuous media.
Latency and autonomy: Decide which actions must work locally during an internet or cloud outage.
Delivery and data handling: Define which readings may be dropped, which commands need acknowledgments, and how duplicates or stale data are recognized.
Lifecycle and cost: Include gateways, subscriptions, broker capacity, update mechanisms, and the effort needed to support deployed devices.

An IoT protocol selection guide offers a complementary decision matrix. For gateways and local/cloud boundaries, see the IoT gateway architecture guide and the broader IoT architecture overview.

Try MQTT locally

On a Debian or Ubuntu test machine, install Mosquitto and its command-line clients:

sudo apt update
sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto

In one terminal, subscribe to a local test topic:

mosquitto_sub -h 127.0.0.1 -t 'lab/temperature' -q 1 -v

In another terminal, publish a sample reading:

mosquitto_pub -h 127.0.0.1 -t 'lab/temperature' -q 1 -m '{"celsius":22.5}'

This demonstrates local MQTT messaging, not a production configuration. Before exposing a broker beyond the host, configure TLS, unique client identities, authentication, and least-privilege topic access; disable anonymous access and plan credential rotation. A home lab for IoT testing is a safer place to explore gateways and device behavior. If you containerize a broker, review container networking fundamentals and the Docker beginner’s guide.

Design for security and operations

Treat every device, gateway, broker, and cloud endpoint as part of the security boundary. Use a unique identity per device, encrypt traffic in transit, authorize only required resources or topics, protect keys during provisioning, and revoke credentials when equipment is retired or compromised. For resource-constrained links, select a security mechanism supported by the complete device and gateway path; encryption alone does not provide safe authorization or secure firmware updates.

Also decide how the system behaves when a device disappears. Buffer only what can be stored safely, set expiry for data that becomes stale, monitor reconnects and queue growth, and test how gateways recover after power or network loss. Protecting the devices and their network requires the wider controls in this IoT security guide. Large telemetry deployments also need a storage and retention plan, such as the one discussed in this Ceph storage cluster guide; enterprise sites should account for WAN design, including considerations covered by this SD-WAN guide.

Common Misconceptions

“MQTT, BLE, and LoRaWAN are alternatives at the same layer.” BLE and LoRaWAN provide connectivity; MQTT is an application messaging protocol. A gateway or IP-capable device can combine them.
“QoS 2 means a database change happens exactly once.” It describes MQTT message delivery between protocol participants. Application retries, crashes, and side effects still require deduplication or idempotent processing.
“UDP makes CoAP unreliable.” CoAP can use confirmable messages and retransmission over UDP, and it has transport bindings beyond UDP. Reliability still depends on the full network and application design.
“A long-range radio automatically solves connectivity.” Range does not guarantee coverage, low latency, high throughput, or a workable downlink. Local obstructions, antenna placement, regional rules, and network availability matter.
“Encryption is the whole security plan.” Secure transport does not replace device identity, authorization, safe provisioning, update validation, or operational monitoring.
“Every sensor should connect directly to the cloud.” A local gateway can reduce exposure, translate non-IP links, enforce policy, and keep essential control working during an internet outage.