No Gateway Required: Mesh Telemetry Versus LoRaWAN's Centralised Model

Part one and part two of this series covered how Reticulum and MeshCore actually move a sensor reading: LXMF’s delivery methods and Propagation Nodes on one side, a purpose-built sensor role and CayenneLPP encoding on the other. Both are genuinely decentralised, no shared infrastructure required beyond the nodes themselves. This closing part asks the question that decides whether that matters for a given deployment: what does the alternative, LoRaWAN, actually require to do the same job?

What LoRaWAN Requires, End to End

LoRaWAN’s topology has come up repeatedly across this site’s LPWAN coverage: a star-of-stars, where end devices talk to one or more gateways, which forward everything to a central LoRaWAN Network Server, or LNS (ChirpStack and The Things Network’s own backend are the two most common implementations). That single sentence hides three separate things a deployment has to actually stand up before a single reading reaches a dashboard.

A gateway. This site's mioty benchmark piece already lays out current gateway and end-node pricing in detail, indoor units from under $200, outdoor units running several hundred dollars, so it isn’t worth repeating the table here. What matters for this comparison is simpler: a gateway is a discrete piece of infrastructure someone has to buy, mount, and maintain, before the network exists at all.

Registration on an LNS. End devices don’t just start talking. They need to be provisioned, keys exchanged, join procedures completed (OTAA, over-the-air activation, being the common case), against either a self-hosted ChirpStack instance or a hosted service like The Things Network. This is a real, if modest, amount of setup and ongoing account management that neither Reticulum nor MeshCore requires at all, there is no server to register with, because there is no server.

A live internet connection at the gateway. This is the part that matters most and gets least attention. A standard LoRaWAN gateway is only useful if it can reach the network server, which for the overwhelming majority of deployments means it needs its own internet backhaul: fibre, a cellular modem, or Wi-Fi back to something that has one. A gateway with no backhaul is a radio that hears everything and can tell no one. For a property already on the NBN this is a non-issue. For the actual edge cases this whole site keeps returning to, a shed at the far end of a paddock, a fire tower, a monitoring point with no fixed connectivity, it’s the whole problem.

Reticulum and MeshCore need none of the three. A sensor node and a collector, in range of each other or connected through intermediate mesh hops, move a reading with no gateway, no registration step, and no dependency on either end having internet access at all. The entire chain from sensor to phone can run somewhere with no internet connection whatsoever, permanently, not as a degraded fallback mode.

The Fair Counterpoint

It would be a strawman to leave LoRaWAN’s backhaul dependency unqualified, because the LoRaWAN ecosystem has already built its own answer to exactly this problem. ChirpStack’s Gateway Mesh, developed with RAKwireless, lets a relay gateway operate with no internet backhaul of its own, solar-powered if needed, forwarding uplink and downlink traffic over LoRa to a single border gateway that does have a connection. It’s a real, working multi-hop extension to the star-of-stars model, and it narrows the gap this article is describing considerably for deployments willing to adopt it.

It doesn’t close the gap entirely. A Gateway Mesh network still needs at least one gateway with genuine internet backhaul, somewhere, and it still routes through ChirpStack’s LNS at the border, the dependency moves, it doesn’t disappear. But it’s a legitimate, shipping mitigation, and pretending otherwise would misrepresent where LoRaWAN actually stands today.

Where LoRaWAN Excels by Design

This site has already made the case for this, and it doesn’t need re-deriving: for high-density, industry-standard sensor deployments, LoRaWAN remains the more efficient and more standardised choice. Put it concretely: nobody sane runs a dense water or electricity metering project, tens of thousands of endpoints across a suburb, reporting on a fixed schedule into a utility billing system, over a mesh. That’s precisely the job LoRaWAN’s star-of-stars topology and multi-vendor standardisation were built for: a known, fixed, high device count, sitting on infrastructure that already has reliable power and backhaul because it’s in a suburb, not a paddock. A LoRaWAN meter from any vendor speaks to any compliant network server, a level of interoperability neither Reticulum nor MeshCore offers; by design, both are tailored to specific peer-to-peer implementations. Choosing LoRaWAN for utility-scale deployments is the sensible engineering call, and mesh telemetry is not trying to replace it there.

Where the Gateway Becomes the Problem

The reverse case is just as clear-cut. A remote tourism trail, a working farm past the edge of reliable mobile coverage, or an emergency deployment somewhere the phone network has already gone down, share a trait dense metering doesn’t have: nobody can guarantee a gateway with permanent internet backhaul at the point coverage is actually needed, and standing one up specifically for the deployment is expensive relative to how few sensors are involved. A LoRaWAN gateway with cellular backhaul, at the pricing already covered on this site, costs real money before a single sensor goes in the ground, and it becomes a single point of failure sitting exactly where the connectivity problem already was.

In regional Australia, operating under the ACMA Low Interference Potential Devices (LIPD) Class Licence for the 915–928 MHz band, private peer-to-peer LoRa mesh networks require no carrier relationships, no recurring backhaul subscriptions, and no external SIM cards. For a handful of soil moisture sensors on a remote block, a tank level sensor on a walking track, or a chain of nodes relaying a status update out of a fire ground, that absence of fixed gateway infrastructure and ongoing backhaul cost is decisive. This is where Reticulum and MeshCore’s gateway-free model stops being an architectural curiosity and becomes the compelling reason to choose one of them: not because mesh is inherently superior across the board, but because its architectural assumptions match what an off-grid deployment can actually sustain.

The Sensor’s Own Power Budget: Push, Pull, and the Cost of Listening

Everything above is about infrastructure the deployment has to stand up around the sensor. There’s a second, quieter power question: what does each model cost the sensor itself, in current draw, not just in gateways and backhaul.

Part two described MeshCore’s sensor role as spending almost all its time asleep, barely touching the battery, because it never transmits unprompted. That’s true on the transmit side, and it’s a real, quiet-RF-footprint advantage. It isn’t the whole story, because a pull model only works if something can reach the sensor to ask the question in the first place, and reachability carries a cost that a pure push model doesn’t.

The numbers make the mechanism concrete. Semtech’s SX1262, the LoRa radio underneath the large majority of MeshCore, Meshtastic, and RNode hardware alike, is specified at around 4.2 to 4.6 mA of current while actively receiving, against roughly 1.6 µA in sleep, a gap of nearly three orders of magnitude. A sensor node that has to stay answerable to an incoming querySensors() request cannot just sit at 1.6 µA and hope the query finds it: the radio has to be listening, in some form, at the moment the request arrives, or the pull fails silently.

MeshCore’s own community power-tuning guidance resolves this with a light sleep mode: the microcontroller sleeps, but the radio wakes on a timer to listen for a short window, keeping the node reachable at a fraction of continuous-RX cost, commonly documented at somewhere around 2 to 5 mA average on nRF52-class hardware, against 1 to 100 µA in true deep sleep. Deep sleep is available too, but it makes the node unreachable until its own wake timer fires, which defeats the point of a pull model outright: nothing can query a sensor that isn’t listening. That leaves a genuine, explicit trade-off a MeshCore sensor operator has to set deliberately: shorten the listen interval and the node answers within seconds, at the cost of average current draw; lengthen it and the battery lasts longer, while a query in flight might sit unanswered for most of a minute.

Compare that to Reticulum’s opportunistic delivery from part one, or to LoRaWAN’s own Class A end-device behaviour. Both are structurally push, and both let the sensor sidestep the listening problem almost entirely. A Reticulum sensor doing opportunistic delivery wakes on its own schedule, sends one packet, and drops straight back to microamp-level sleep; it never needs to hold its radio in receive at all, because the listening burden shifts to the collector, which is far more likely to be mains-powered. LoRaWAN’s Class A end devices work the same way by design: two short receive windows immediately after each uplink (in Australia’s AU915 band, one second and two seconds after the device’s own transmission), and nothing in between, which is precisely why Class A is documented as LoRaWAN’s lowest-power device class. Both push models keep the constrained, battery-powered node in charge of when its radio briefly wakes, and push the always-listening burden onto whichever end of the link is actually built to carry it.

That Class A comparison is worth flagging as a choice, not a given. It’s the class assumed by default whenever someone says “LoRaWAN is low-power,” and it’s the right assumption for most sensor telemetry, a reading going one way, on the device’s own schedule. But LoRaWAN has its own answer to the reachability problem this whole section is about, and it looks a lot like MeshCore’s: Class C keeps the receive window open continuously, except while actually transmitting, so the network server can reach the device with a downlink at any moment rather than waiting for the next uplink’s brief window. That’s genuinely useful for a device that needs to take a command in near real time, an actuator, a valve, a street light, but it costs accordingly: Class C devices draw somewhere around 6 to 15 mA continuously in receive, commonly put at 50 to 100 times a Class A device’s average draw, which is exactly why Class C hardware is effectively always mains-powered rather than running on a battery. A Class C end device and a MeshCore sensor in light sleep are solving the identical problem, staying reachable for a request that could arrive at any time, by paying the identical kind of cost: holding the radio open far more of the time than a strict push model ever needs to. “Low power” isn’t a property of LoRaWAN as a whole any more than “barely touching the battery” is a property of MeshCore as a whole; both are true of one configuration and false of the other.

None of this makes MeshCore’s pull model the wrong call. Permission-gated queries and a network that stays quiet on average are real advantages, unrelated to current draw. But “spends almost all its time asleep” needs a more precise claim sitting next to it: asleep in the duty-cycled, still-reachable sense, not the deep-sleep sense a push-only sensor gets for free. Sizing a battery or solar panel for a MeshCore sensor node means budgeting for periodic receive current on top of the occasional CayenneLPP reply, not just for the reply itself.

Architecture and Operating Domains

Understanding these two paradigms means recognising that they solve fundamentally different problems:

• LoRaWAN is built for scale and centralised aggregation. It assumes fixed infrastructure, predictable backhaul, multi-tenant billing, and high endpoint density.
• Reticulum and MeshCore are built for autonomy and resilience at the edge. They assume infrastructure failure, zero internet backhaul, and sovereign peer-to-peer communication.

My own work in this space focuses on evaluating where mesh telemetry delivers real autonomy for agricultural and off-grid environments, rather than treating mesh as a drop-in substitute for utility-scale LoRaWAN.

Comparison

Which One to Reach For

If a Reticulum network already exists on a property, for messaging, remote monitoring, whatever the original reason was, adding sensor telemetry costs nothing beyond an LXMF message with the right Fields set, no new infrastructure, no new protocol. If the deployment is sensor-first, purpose-built, and benefits from a standard, mesh-portable payload format and permission-gated queries, MeshCore’s sensor role is the more direct fit. If the deployment is going to scale into the hundreds or thousands of nodes, needs to interoperate with commercial platforms, or already has reliable gateway backhaul in place, LoRaWAN remains the right call, and no amount of mesh enthusiasm changes that calculation.

There’s a further separator, and it has nothing to do with range, power, or terrain: who ends up owning the data, and who’s positioned to extract value from it later. LoRaWAN’s star-of-stars topology routes every reading through a single LNS, and that’s precisely the shape a centralised, cloud-hosted platform wants, a natural chokepoint to meter, tier, and eventually monetise, even on a self-hosted, open-source ChirpStack instance with the best intentions behind it. It’s the same well-worn cycle this site has been openly critical of elsewhere: a platform serves its users first, then its business customers, then its shareholders, once enough lock-in has accumulated that leaving costs more than staying. Reticulum and MeshCore don’t have an equivalent chokepoint to squeeze. A reading moves from sensor to whoever’s actually listening, and there’s no server standing between a farmer and their own soil moisture data for anyone to put a subscription behind, meter API access to, or sunset and strand the hardware underneath. The data stays wherever its owner decides to keep it, and gets shared outward only when and if they choose to bridge it somewhere else. For a deployment that cares who owns its own data as much as it cares about coverage, that’s a standalone reason to reach for mesh, not a lesser one sitting behind the technical case.

The actual decision point isn’t which technology “wins”. It’s matching the network’s architecture to the physical realities of the site, and to who the deployment wants owning the data running through it. Where connectivity and power are guaranteed, LoRaWAN’s multi-vendor standardisation and carrier-grade backend are exceptionally capable. Where connectivity is absent, and across large tracts of rural, off-grid, and emergency-context Australia, it is, Reticulum and MeshCore provide autonomous communication that operates entirely on local terms. Choosing between them is not about finding a universal winner; it is about choosing the right tool for the terrain.

Part three of three. Previously: Sensor Data Over Reticulum: LXMF, Propagation Nodes, and the Low-Power Case and Sensor Data Over MeshCore: Pull-Based Telemetry and CayenneLPP. Related reading: MIOTY: The Automation Industry Arrives at the LPWAN Table for full LoRaWAN gateway and end-node pricing, Cooperative by Design for ChirpStack and backhaul discussed at the community-infrastructure level, and LPWAN Meshes: The Verdict, Making the Choice for the original range/security/scalability scoring this series builds on.

Sources

• ChirpStack, Gateway Mesh. Relay-gateway architecture and backhaul-free operation.
• RAKwireless, Gateway Mesh Solution: Extend Your LoRaWAN Network with Multi-Hop Technology. Hardware and deployment detail.
• The Things Network, Configuring Your Gateway. LNS registration and gateway setup process.
• ChirpStack, Documentation. Open-source LNS reference.
• Semtech, SX1262 LoRa Connect Transceiver. Receive and sleep current specifications.
• The Things Network, Device Classes. Class A receive-window timing and power behaviour.
• LocalMesh, MeshCore Power Consumption Optimization. Community-documented light sleep/deep sleep current figures for MeshCore hardware.

• Lorawan
• Reticulum
• Meshcore
• Network Infrastructure
• Chirpstack
• Lpwan