“Which protocol should we use?” is almost always two questions wearing one coat. One is which radio carries the bits — BLE, Thread, Wi-Fi, LoRaWAN, cellular. The other is which messaging protocol carries the meaning — MQTT, CoAP, OPC-UA. They sit at different layers, they are chosen for different reasons, and most confusion about IoT connectivity comes from treating them as one decision.
The stack above is the whole argument in one picture. Everything below the dividing line is about moving bits through the physical world: how far, how fast, on how little power, through how many walls. Everything on the top row is about moving meaning between software: a sensor reading, a command, a model of a machine. A link layer and a messaging protocol answer different questions, and a design gets simpler the moment you stop choosing them together.
The connecting idea is IP. Once a device can carry IPv6 or IPv4 — over Wi-Fi, Ethernet, Thread or cellular — the messaging layer stops caring what the radio is. MQTT does not know whether it is running over fibre or LTE-M. That is why the top row spans the IP-bearing columns: the messaging protocol is portable in a way the radio never is. The columns that are not IP end-to-end — BLE, Zigbee, LoRaWAN — are exactly the ones that need a gateway to join that world.
No single radio wins. Each occupies a different corner of the range–throughput–power trade, and the right one falls out of the physical problem.
Bluetooth LE is the short-range, low-power default for anything near a phone — wearables, beacons, commissioning, and, since 5.1, direction finding for indoor location. It is not IP on its own, so it reaches the internet through a gateway or a phone. The 802.15.4 family is the low-power mesh world: Zigbee (mature, application-specific profiles), Thread (the same radio carrying IPv6 via 6LoWPAN, which is what makes it route like a real network), and Wi-SUN (sub-GHz mesh for utility and smart-city scale). Matter sits on top of Thread, Wi-Fi or Ethernet as a common application layer, using BLE only to commission a device onto the network.
Wi-Fi buys throughput and native IP at the cost of power, which is why it suits mains-powered and bandwidth-hungry devices. Ethernet — increasingly with TSN for bounded latency — is the wired backbone where determinism matters. At the long-range end, LoRaWAN trades data rate for kilometres and years on a battery, with its own non-IP network layer; cellular LPWAN — NB-IoT and LTE-M, and 5G above them — buys licensed-spectrum reach and native IP without owning any infrastructure. The glue that keeps the low-power mesh world addressable is 6LoWPAN, the adaptation layer that squeezes IPv6 onto 802.15.4; it is the quiet reason Thread and Matter can be treated as networks rather than islands.
One short-range radio in the stack is not there to move data at all. Ultra-wideband (UWB) spreads a very wide bandwidth of low-power impulses across 3.1–10.6 GHz, and that width is what lets two devices measure the time of flight between them and so their distance — to roughly ten centimetres, far beyond the coarse signal-strength proximity BLE can offer. Standardised as IEEE 802.15.4z and certified by the FiRa Consortium (and built into recent phones through Apple’s U1/U2 and Android’s UWB stack), it answers the question “where, exactly?” rather than “what is the reading?”. The use cases follow from precision and the fact that time-of-flight is hard to spoof: secure access — phone- or fob-as-key for vehicles and doors, where UWB defeats the relay attacks that catch passive BLE/RF keys; real-time location (RTLS) — tracking tools, stock, vehicles and people to the aisle and the bay in factories, warehouses and hospitals; hands-free and indoor positioning where GPS cannot reach; and device-to-device spatial awareness for directional file sharing, pointing and AR. In practice UWB rarely travels alone — BLE discovers and wakes the link, then UWB does the precise ranging — so it usually sits beside one of the data-carrying radios rather than replacing it.
Once a radio can measure something about the link — how strong it is, how long it took, what direction it came from — it can place a device in space. The methods form a ladder from rough to sharp, and they are worth separating because they fail and cost very differently.
The crudest is RSSI: infer distance from signal strength. It is free — every radio reports it — and noisy enough that it only honestly supports “near / far” or “which room,” which is all most BLE proximity needs. Time of flight is the sharp one. Radio covers about thirty centimetres a nanosecond, so if you can measure the travel time you have the distance; two-way ranging (TWR) measures the round trip so the two devices need no shared clock. This is where UWB’s wide bandwidth earns its place — sharp timing edges give ten-centimetre distances. Combine three or more such distances and you have trilateration: three circles meeting at a point, the left-hand panel above.
Angle of arrival (AoA) measures direction instead of distance. A locator carrying a multi-element antenna array reads the tiny phase differences as a signal sweeps across its antennas and works out the bearing the signal came from; angle of departure (AoD) is the mirror image, with the array on the transmitter so the device computes its own bearing. Bluetooth made this mainstream in 5.1 direction finding — the Constant Tone Extension the array samples — and UWB does it too. What makes AoA attractive for locating things is anchor economy: a single multi-antenna locator already yields a direction, so two of them — or one plus a known distance — fix a position, where distance-only methods need three or more anchors. That is why AoA fits indoor positioning and wayfinding, directional asset and people tracking (a bearing to the tag, not just its presence), and ‘point-to-find’ item location. Two bearings crossing at the target — angles, not distances — is triangulation, the middle panel above. The word is constantly swapped with trilateration, and the distinction is simply that trilateration measures distances while triangulation measures angles. Its costs are the antenna array, calibration, and accuracy that degrades with distance and multipath — so in large, dense sites TDoA or UWB ranging tend to win on precision while AoA wins on how little infrastructure it needs.
At infrastructure scale there is TDoA (time difference of arrival), the right-hand panel. Instead of the tag ranging against each anchor, a fixed grid of time-synchronised anchors simply listens; the tag transmits once, the anchors compare when the blip reached each of them, and every pair of arrival-time differences defines a hyperbola whose intersection is the tag. Because the tag only transmits, TDoA scales to thousands of cheap tags, which is why it underpins large real-time location systems. A newer entry, BLE channel sounding, uses phase across many frequencies to bring metre-class ranging to plain Bluetooth. Outdoors, of course, GNSS answers all of this — these methods are the indoor and short-range answers where satellites cannot reach.
Above IP, the question changes from can these two things reach each other to how should they talk. The protocols differ mostly in their interaction model and their weight.
MQTT is the workhorse: a publish/subscribe protocol through a central broker, over a persistent TCP connection, small enough for most devices and ubiquitous in cloud IoT. MQTT-SN is its sensor-network variant over UDP, for devices too constrained or too sleepy to hold a TCP session open. CoAP takes the opposite shape — a RESTful request/response model with an observe extension, over UDP with DTLS — and is built for the smallest devices; it underpins LwM2M device management. AMQP is the heavier, enterprise-grade option, with reliable queuing and transactional guarantees, where messages must not be lost. DDS is data-centric rather than broker-centric: peer-to-peer publish/subscribe with rich quality-of-service, which is why it runs real-time and robotics systems, including ROS 2. And OPC-UA is the industrial world’s answer — it carries not just values but an information model describing what they are, with Modbus still underneath it in most real factories.
MQTT vs CoAP is the question that comes up most, and the answer is a shape, not a winner. MQTT is brokered publish/subscribe over a persistent TCP connection: it shines when a broker aggregates many devices, fans one message out to many subscribers, and holds retained state — and when there is mains power, or a gateway, to keep that connection alive. CoAP is the opposite shape: RESTful request/response (with an observe option for push) over UDP, with no broker and no held connection, addressing resources on the device directly. The rule of thumb: broker, fan-out and always-on point to MQTT; a tiny battery node answering requests points to CoAP. A great many real systems use both — CoAP at the constrained edge node, MQTT from the gateway up to the cloud.
MQTT vs MQTT-SN is the same model at a smaller size: MQTT-SN runs the pub/sub idea over UDP for devices too constrained or too sleepy to hold TCP open, reaching a real MQTT broker through a gateway. MQTT vs AMQP is weight and guarantees: both are brokered, but MQTT is lightweight telemetry that tolerates the occasional loss, while AMQP adds transactional delivery, queues and routing for messages that must not be dropped — enterprise and financial-grade reliability, at a higher footprint. MQTT vs DDS is tiers, not rivals: MQTT moves device data up to a platform through a broker; DDS is a brokerless, peer-to-peer data bus with fine-grained quality-of-service for real-time local control, which is why robotics and vehicles reach for it. The two often live in the same product at different layers. CoAP vs HTTP is simply HTTP’s request/response idea shrunk to UDP for devices that cannot afford a full TCP/TLS stack — and LwM2M device management is built on top of CoAP. And OPC-UA vs MQTT is the industrial pairing that is least either/or: OPC-UA carries an information model of what the data means, while MQTT (increasingly via Sparkplug) is the efficient transport that moves it — OPC-UA for semantics and interop, MQTT for reach and scale, frequently together.
One — how far, and on what power? That answers the radio before anything else. Coin-cell and metres: BLE or 802.15.4. Mains and bandwidth: Wi-Fi or Ethernet. Kilometres and years: LoRaWAN or cellular LPWAN. And if the requirement is not throughput at all but precise location or secure ranging — centimetre positioning, phone-as-key — that is UWB’s question, answered alongside one of the others rather than instead of it. Get this wrong and no messaging choice rescues it.
Two — IP end-to-end, or a gateway? If the radio carries IP (Thread, Wi-Fi, Ethernet, cellular) the device can speak messaging directly. If it does not (BLE, Zigbee, LoRaWAN), a gateway is part of the architecture, not an afterthought — and the gateway, not the sensor, becomes where integration really happens.
Three — cloud telemetry, or local real time? Data flowing up to a platform wants MQTT (or CoAP for the smallest nodes). Tight local control loops — a robot, a vehicle, a motion system — want DDS, whose quality-of-service and peer-to-peer model exist for exactly that. They are not competitors; they often appear in the same system at different tiers.
Four — is it industrial? Then interoperability and an information model usually matter more than raw efficiency, which points to OPC-UA over the field protocols already installed, with MQTT carrying the modelled data onward. Brownfield reality — Modbus that predates all of this — is bridged, not replaced.
The recurring mistakes are predictable. Running plain MQTT on a battery sensor and then wondering why the battery dies — the persistent TCP connection is the cost, and MQTT-SN or CoAP is the fix. Treating security as a later layer — DTLS for CoAP and TLS for MQTT are not optional on anything that leaves the building, and retrofitting them is painful. Designing as though the device talks to the cloud when the radio is non-IP, then discovering the gateway halfway through. And in industrial work, underestimating how much of the effort is bridging brownfield — the Modbus-to-OPC-UA-to-MQTT path is most of the real project. None of these is a protocol flaw; each is a layer chosen without the one below it in view.
No. Matter is an application layer — a common data model and interoperability layer — that runs over Thread, Wi-Fi or Ethernet, and uses Bluetooth LE only for commissioning. It standardises how devices describe and talk to each other, not the radio underneath. Thread still carries the packets; Matter decides what they mean.
Usually CoAP, or MQTT-SN — both run over UDP and avoid holding a connection open. Plain MQTT keeps a TCP session alive, and that persistent connection plus its keep-alives costs energy a coin-cell cannot spare. CoAP's request/response-plus-observe model fits a device that wakes, reports and sleeps. MQTT earns its place once there is mains power or a gateway that holds the broker connection on the sensor's behalf.
Only when the device network is not IP end-to-end. BLE, Zigbee and LoRaWAN are non-IP or have their own network layer, so a gateway bridges them to an IP messaging protocol like MQTT. Thread, Wi-Fi, Ethernet and cellular carry IPv6/IPv4 all the way, so a device can speak MQTT or CoAP to the cloud directly — though a gateway is still often wanted for buffering, local control and security.
Most factories are brownfield: Modbus devices that predate IoT, bridged upward. OPC-UA is the interoperability layer that carries not just values but an information model of what they mean, which is why it has become the backbone of industrial interop; MQTT (often with Sparkplug) is increasingly the transport that moves OPC-UA-modelled data to the cloud. A realistic industrial design bridges Modbus into OPC-UA and publishes over MQTT.
It depends on how precise you need to be. BLE estimates proximity from signal strength — good enough for ‘which room’ or ‘nearby,’ but noisy and spoofable. UWB measures time of flight directly and reaches roughly ten-centimetre accuracy, which is what makes it the choice for secure access (phone- or fob-as-key, where it defeats relay attacks) and real-time location of assets and people. The two are complementary: BLE is cheap, ubiquitous and wakes the link; UWB adds precise, trustworthy distance on top. If you only need presence or coarse zones, BLE alone is usually enough; if you need accurate position or anti-relay security, that is UWB.
When you want a direction and as little infrastructure as possible. Distance methods — time-of-flight ranging and TDoA — need three or more ranging or time-synchronised anchors to pin a point. An angle-of-arrival locator with a multi-antenna array gives a bearing on its own, so two locators (or one plus a distance) can place a tag, and a single one can simply point the way to it. That makes AoA attractive for indoor wayfinding, directional asset tracking and item-finding, and it is what Bluetooth 5.1 direction finding brought into reach. The trade-off is the antenna array and calibration, plus accuracy that falls off with distance and multipath — so where precision matters most, at scale, UWB ranging or TDoA usually win, while AoA wins on infrastructure simplicity.
Picking the radio and the messaging layer together, with the gateway and the security in view from the start, is where a connected product is won or lost. Tell us the device, the range and the constraint.