Public and Community LoRaWAN Gateways

A LoRaWAN gateway is a bridge between low-power LoRaWAN devices and an internet-connected network server. Public and community gateways let many people share that radio coverage, whether the gateway is operated by a volunteer, a university, a municipality, a company, or a Helium Hotspot owner.

The most important point for Meshtastic users is simple: a LoRaWAN gateway cannot carry or repeat Meshtastic messages. LoRaWAN and Meshtastic both use LoRa radio modulation, and they may operate in the same regional frequency bands, but they use different protocols. Sharing the LoRa physical layer does not make their networks interoperable.

What is a LoRaWAN gateway?

A LoRaWAN end device might be a water meter, soil sensor, asset tracker, weather station, parking sensor, or alarm. It sends a small LoRaWAN radio packet. Every compatible gateway in range may receive that packet and forward a copy over Ethernet, Wi-Fi, or cellular data to a LoRaWAN network server.

The network server authenticates and manages devices, removes duplicate copies received by multiple gateways, applies LoRaWAN network rules, schedules downlinks, and passes application data toward the appropriate application service. A gateway therefore behaves more like a multi-channel radio front end connected to the internet than like an intelligent chat node.

This architecture is commonly described as star-of-stars:

An end device transmits directly to any gateway it can reach.
One or several gateways forward the received packet through the internet.
The network server processes the packet and routes its application data.
If a downlink is required, the server selects a suitable gateway to transmit it.

Gateways do not normally forward radio packets to one another. An end device also does not relay another end device’s traffic. The internet-connected backend, not a radio mesh, joins the coverage areas together. The LoRa Alliance’s LoRaWAN overview provides the standards-level introduction.

LoRaWAN gateway versus Meshtastic node

Feature	LoRaWAN gateway	Meshtastic node
Main job	Forward LoRaWAN packets between radio devices and an internet-connected network server	Send, receive, and sometimes rebroadcast Meshtastic packets over radio
Network shape	Star-of-stars	Multi-hop, managed-flood mesh
Internet required	Normally required for useful gateway operation	No; optional MQTT can bridge traffic over the internet
Relays traffic by radio	No gateway-to-gateway radio relaying	Eligible nodes can rebroadcast Meshtastic packets
Typical radio hardware	Multi-channel LoRa concentrator such as an SX1301-, SX1302-, or SX1303-based design	Single-channel LoRa transceiver such as an SX1262 or SX1276
Can carry the other system’s packets?	No	No

A LoRaWAN gateway can listen to several LoRa channels and spreading factors at once. That makes it very different from the inexpensive LoRa transceiver used in a normal Meshtastic board. Conversely, a Meshtastic node understands Meshtastic routing, node identities, channels, and packet headers; a LoRaWAN gateway does not turn those packets into Meshtastic mesh traffic.

Public and community gateway networks

The Things Network

The Things Network (TTN) is a well-known global community LoRaWAN network built around gateways contributed by individuals and organizations. A compatible LoRaWAN device can use community coverage after its application and device credentials have been registered with the appropriate The Things Stack environment. Seeing a TTN gateway nearby does not mean that arbitrary radio packets are accepted or that application access is automatic.

Community resources are shared. Operators and device owners should follow current network policies, limit unnecessary transmissions and downlinks, and obey the radio regulations for their country. Regional frequency plans differ: EU863-870, US902-928, AU915-928, AS923 variants, IN865 and other plans are not interchangeable. Check the current LoRaWAN frequency-plan documentation before buying or configuring hardware.

Helium IoT

Helium has changed substantially since its early “People’s Network” period, so old tutorials and maps can be misleading. As of 2026, the Helium IoT network remains a LoRaWAN network, while Helium also operates a separate mobile/Wi-Fi ecosystem.

LoRaWAN gateways on Helium are called IoT Hotspots. Individuals and businesses can operate them. A Hotspot forwards received packets to the Helium Packet Router, which uses configured routes to deliver packets to a LoRaWAN network server. Qualifying operators can receive HNT rewards for coverage and data transfer under the network’s current rules. This commercial incentive makes Helium different from a purely volunteer gateway network, although many installations are still community-run in practice.

ChirpStack community deployments

ChirpStack is open-source LoRaWAN network-server software. A club, university, city, business, maker group, or individual can use it to operate a private or community network. There is no single worldwide “ChirpStack community network”: each deployment has its own owner, policies, accounts, integrations, and gateway directory.

A ChirpStack gateway commonly runs a Semtech packet forwarder, LoRa Basics Station, ChirpStack Concentratord, or an MQTT forwarding component. The official gateway connection guide explains how received LoRaWAN frames reach the server. Whether the public may use a particular deployment depends entirely on its operator.

How to find public gateways near you

TTN Mapper displays measured coverage contributed by people using GPS-equipped LoRaWAN test devices. It is more useful than drawing an arbitrary radius around a gateway because it records places where packets were actually received.

However, the map must be interpreted carefully. According to the TTN Mapper FAQ, a gateway needs a known location and at least one uploaded measurement before it appears. A missing marker or coverage trail therefore does not prove that no gateway or usable signal exists. Old measurements also do not guarantee that a gateway is still online.

For Helium, use the current Helium Explorer to inspect onboarded Hotspots, and the IoT-focused Helium Coverage map for measured LoRaWAN coverage. Do not confuse these with maps for Helium Mobile. A registered Hotspot location is evidence of installed infrastructure, not a promise of usable RF coverage at every point in its surrounding map cell.

For a local ChirpStack network, ask its operator or community for its map and registration procedure. CoverageMap.net can also display measured coverage for several IoT networks, including TTN, Helium, and participating private or ChirpStack deployments.

What is inside a LoRaWAN gateway?

A full gateway usually contains:

A multi-channel LoRa concentrator based on a chip family such as Semtech SX1301, SX1302, or SX1303
Radio front-end components, filters, amplifiers, and one or more correctly tuned antennas
A host computer or embedded processor that runs a packet forwarder
Internet backhaul through Ethernet, Wi-Fi, or cellular service
A power supply, and sometimes Power over Ethernet, battery backup, or solar power
For outdoor installations, a weather-resistant enclosure, grounding, lightning protection, and suitable cable entries

Older SX1301 gateways remain in service, but SX1302- and SX1303-based concentrators are newer, more power-efficient generations. The concentrator can receive multiple LoRa signals across several channels and data rates. A cheap single-channel LoRa board is not an adequate substitute for a standards-compliant community gateway: it may miss most traffic and can create misleading expectations about coverage.

The gateway’s packet forwarder sends received metadata and encrypted LoRaWAN frames to the backend. It may also receive tightly scheduled downlink instructions. ChirpStack’s Gateway Bridge documentation illustrates how common packet-forwarder protocols are converted for server-side use.

Typical gateway range

No trustworthy map can assign one fixed radius to every gateway. Range depends on antenna height and gain, terrain, buildings, foliage, local interference, frequency plan, end-device antenna, transmit power, spreading factor, bandwidth, and the installation quality at both ends.

Environment	Useful planning expectation	Main limitation
Dense urban area	Often approximately 1–3 km; sometimes less indoors or between large buildings	Concrete, metal, indoor placement, interference, and blocked paths
Open suburban or lightly built area	Several kilometres may be practical with a good elevated gateway	Roof lines, trees, terrain, and end-device antenna quality
Rural, elevated, good line of sight	Approximately 10–15 km is plausible, with longer links possible under favourable conditions	Terrain profile, Fresnel-zone obstruction, and endpoint height

These are broad planning ranges, not service guarantees. A roof-mounted gateway may hear a farm sensor 12 km away yet fail to hear an indoor meter 500 metres away. Measured maps and an on-site test with the intended device are more useful than a manufacturer’s maximum-distance claim.

Why Meshtastic cannot use a LoRaWAN gateway

LoRa describes the radio modulation—the method used to put symbols onto the air. LoRaWAN and Meshtastic define different systems above that layer.

They differ in several essential ways:

Network architecture: LoRaWAN end devices talk to gateways and network servers; Meshtastic nodes can rebroadcast packets over radio.
Packet format: LoRaWAN frames contain LoRaWAN headers, addresses, counters, integrity data, and encrypted payloads. Meshtastic uses its own packet header and protobuf-based payload scheme.
Radio identification: networks use synchronization and modem parameters to recognize expected traffic. The Meshtastic mesh algorithm documentation currently specifies the Meshtastic LoRa sync word as 0x2B.
Channel and timing rules: LoRaWAN uses region-specific channel plans, receive windows, activation, adaptive data rate, and server-coordinated downlinks. Meshtastic uses its own frequency-slot, preset, hop, rebroadcast, and channel-key behavior.
Identity and security: the two systems use different addressing, keys, encryption procedures, and packet validation.

A gateway concentrator may detect radio energy or even capture a raw transmission under specially configured diagnostic conditions, but the LoRaWAN network server will not accept it as a LoRaWAN device packet. It will not translate, route, or rebroadcast the Meshtastic message. Likewise, a Meshtastic node will not join a LoRaWAN network merely because it uses a radio chip capable of the same regional frequencies.

Some gateway-class Linux hardware can run additional software, and some boards can be reflashed for an entirely different purpose. That is hardware reuse, not protocol interoperability. A separate custom bridge would need radios and software for both systems and an application-level translation policy; an ordinary TTN, Helium, or ChirpStack gateway does not provide that function.

Running your own community gateway

A basic indoor gateway can cost roughly US$100–200, while a robust multi-channel outdoor unit, antenna system, enclosure, mounting hardware, surge protection, and cellular backhaul can bring the total to US$300–500 or more. Prices vary substantially by region, supplier, environmental rating, and certification. Continuing costs include electricity, internet or SIM service, hosting where applicable, replacement parts, and occasional site access.

Before installing one:

Choose the network and confirm access. Decide whether it will join TTN, Helium IoT, an organization’s ChirpStack instance, or your own server.
Buy the correct regional model. US915 hardware is not a substitute for EU868, AU915, AS923, IN865, or other regional variants. Follow local power, antenna, dwell-time, and duty-cycle rules.
Choose a useful site. Height and a clear RF view usually matter more than purchasing the most expensive gateway.
Provide dependable backhaul and power. Monitor connectivity and consider backup power for an important community site.
Secure the system. Change default credentials, update firmware, restrict management access, and use authenticated, encrypted backhaul where supported.
Publish honest information. Report the approximate location and current status accurately without exposing a private residence more precisely than necessary.
Maintain it. A gateway that is registered on a map but permanently offline misleads device owners and network planners.

Community gateway etiquette and responsibility

A community gateway is shared infrastructure, not unlimited free bandwidth. Keep application traffic small, avoid excessive confirmed messages and downlinks, follow the host network’s fair-use rules, and coordinate high-volume deployments with the operator. Downlinks are particularly constrained because a gateway cannot receive while it is transmitting and local spectrum is shared with other users.

Do not assume that finding a gateway grants access to its owner’s private network, server, data, or building. Ask before depending on a volunteer-operated installation for a commercial, safety-critical, or long-term project. Offer useful feedback when you conduct coverage testing, and tell the operator about persistent outages or obvious location errors politely.

Finally, LoRaWAN is designed for small, delay-tolerant IoT messages. A public gateway does not turn it into broadband, guaranteed telemetry, or emergency-grade infrastructure. Critical deployments need tested coverage, redundancy, monitoring, documented ownership, and an appropriate fallback.