Open Source LoRaWAN Multiplexer and Protocol Converter
The Problem With Private LoRaWAN Infrastructure
A vast number of LoRaWAN deployments rely on small, private network servers. Once these are in place, migrating devices away from them is both risky and complex: devices need to be re-provisioned, downtime is hard to avoid, and the operational cost is high enough that migrations rarely happen at all.
The multiplexer isn't a replacement for roaming. It's a different approach: let a single gateway serve multiple network servers simultaneously. Clients who want to maintain their own private LNS can benefit from a local operator's coverage alongside their own stations without giving up control of their infrastructure. Participation in large community networks like TTN or Helium becomes possible without impacting private deployments.
The multiplexer is open source and available on GitHub: https://github.com/1rabbit/lorawan-multiplexer-converter
What It Does
The multiplexer sits between your gateways and your network servers, accepting any combination of input protocols and forwarding to any combination of outputs, all simultaneously. Gateways connect using whatever protocol they support; each output receives traffic in whatever protocol it requires.
Every major LoRaWAN protocol is covered on both input and output:
- Semtech UDP (GWMP), the legacy packet forwarder used by most older gateways
- Basic Station (LNS WebSocket), the current standard for newer hardware
- ChirpStack MQTT, direct broker integration without an intermediate gateway
Any input protocol can be converted to any output. A UDP gateway can feed a Basic Station server. A Basic Station gateway can publish to an MQTT broker. Multiple gateways using different protocols can converge on a single network server.
That conversion is only half of it. A single gateway connection also fans out to several network servers at once, so a private LNS, a community network and your monitoring tools all receive traffic from the same gateway with no reconfiguration on the gateway side at all.
Which server sees what is controlled by allow and deny lists, matched on:
- Gateway EUI, to restrict which gateways can send to specific outputs
- Device address (DevAddr), to route traffic from specific devices to specific servers
- JoinEUI prefix, to control which join requests reach which network servers
Deny rules take precedence over allow rules, giving explicit control over what reaches each destination. This matters in multi-tenant deployments where different customers' devices need to route to different network servers, and it is also what makes a staged migration safe, since you can move devices between servers a wave at a time by changing a rule.
Separately from routing, a passive monitoring output receives a copy of everything the multiplexer sees, without injecting any commands back into the network. This feeds directly into the LoRaWAN Traffic Analyzer, a companion tool that visualizes gateway and device health, diagnoses frequency band congestion, and provides a live packet feed. The analyzer is already open source and available on GitHub.
Configuration files support environment variable substitution, which makes it straightforward to deploy across development, staging, and production with different credentials and endpoints without maintaining separate config files.
One capability deserves its own explanation, because no other multiplexer does it. ChirpStack's mesh relay feature lets lightweight relay devices forward end-device packets through a border gateway. The relay's identity (relay_id) is carried in the protobuf rx_info.metadata["relay_id"] field of each uplink.
ChirpStack natively understands this metadata, but other LNS platforms only see the border gateway. With relay_gateway_id_prefix, each mesh relay appears as its own gateway:
On the uplink side the multiplexer detects relay_id in MQTT-in uplinks and replaces the gateway ID with prefix + relay_id on any output configured with the prefix. On the downlink side, anything addressed to one of those virtual gateways is routed back out through the original border gateway, so the illusion holds in both directions.
The prefix is configured per output, so you can choose which outputs see virtual gateways. Outputs without a prefix pass traffic through unchanged with the border gateway ID.
Finally, an integrated metrics endpoint exposes packet counts, protocol conversion rates, and connection state in Prometheus format. Plug this into your existing Grafana dashboards or alerting infrastructure without additional instrumentation.
Technical Stack
It is written in Rust, chosen for predictable low-latency packet handling, ships as a Docker container built from source, exposes Prometheus-compatible metrics, and is MIT licensed.
Forked from chirpstack-packet-multiplexer and substantially rewritten and extended with additional protocol support, filtering capabilities, and protocol conversion.
Use Cases
The original motivation was shared gateway infrastructure. A local operator deploys gateways that simultaneously serve their own network and multiple clients' private LNS. Each client retains full control of their own network server and devices. Participating in TTN or Helium community networks alongside private infrastructure requires no separate gateway hardware.
Legacy hardware is the second case, and the cheapest win. Gateways running the original Semtech UDP packet forwarder still work. Rather than replacing gateways to support a modern Basic Station server, the multiplexer converts the protocol in place. The gateway doesn't need to be reconfigured or updated.
Multi-tenant routing follows from the filter rules. Different customers' devices route to different network servers based on DevAddr prefixes. A single shared gateway infrastructure serves multiple isolated LNS instances without each customer needing their own gateway hardware.
And redundancy is almost free once the fan-out exists. Fan out every gateway to a primary and backup network server. If the primary goes down, the backup has been receiving traffic all along and is immediately current.
What I Provide
The multiplexer is open source, MIT licensed, and available on GitHub; anyone can run it. Where I come in is deployment: configuring protocol conversion for your particular gateway mix, setting up multi-server routing for redundancy or multi-tenant use, designing filter rules that match your network topology, and wiring the metrics endpoint into Prometheus and Grafana so you can watch it run. Everything stays self-hosted and documented, with no vendor lock-in and no recurring fees.
Working on a LoRaWAN project?
If this article touches on something you're building, tell me about it. The first conversation is free, and you'll get an honest read on the right approach for your situation.
Book a Free ConsultationCurious what the finished thing looks like? Open the live demo dashboard
