Series note: This is Part 9 of the ManThink LoRaWAN Technical Deep-Dive series. Reading the previous eight parts in order will give you the most complete context.
In any LoRaWAN deployment, the most easily overlooked piece is the "last mile" between the LoRaWAN gateway and the LoRaWAN Network Server (LNS / NS).
The radio side gets all the attention — we've spent several articles on SX1302's 16 parallel channels, TDOA time synchronization, and Class A RX windows. Meanwhile, the part that actually moves the LoRaWAN frame from the gateway to the server is often glossed over with a casual "it uses the packet forwarder." But once your deployment scales to hundreds of devices, crosses a public network, or faces security compliance requirements, this "last mile" turns into the segment that deserves the most scrutiny.
This article lays the three common LoRaWAN gateway-to-server backhaul protocols side by side:
Then we explain which one a default open-source gateway like the ManThink GD6 supports, why the "protocol menu" looks different across ThinkLink, ChirpStack, and TTN, and how to make the right engineering choice.
This is Semtech's reference implementation from the SX1301 era. It runs a daemon like poly_pkt_fwd / lora_pkt_fwd on a Linux host, pushing uplink JSON frames (rxpk) received by the SX130x chip to the LNS, and writing downlink JSON frames (dnmsg) returned by the LNS into the concentrator queue.
Its strength is simplicity — tens of KB of RAM is enough; you can port it to a non-standard platform in hours. For an intranet or private test bench, this is still the most direct solution after twenty years.
But the flaws are equally fatal:
poly_pkt_fwd is dead, can only be guessed from application-layer timestamps.Semtech's official lora_gateway repository was the de-facto standard during the SX1301 era, but with SX1302/SX1303 it has been marked NRND (Not Recommended for New Designs), and new-generation gateways generally pivot to Basic Station. ThinkLink's gwTool6 Configuration Guide also marks UDP Packet Forwarder as something "to be used in a controlled network or with additional network protection only."
Key fact: UDP Packet Forwarder is unencrypted, unauthenticated, and has no built-in link-state monitoring.
MQTT Bridge is not a standard protocol defined by the LoRa Alliance. Instead, it is a gateway-to-server transport mode that uses MQTT topics to carry LoRaWAN uplink and downlink frames. LoRaWAN messages are mapped to MQTT messages, routed by a Broker.
In ManThink's product line, MQTT Bridge primarily serves the ThinkLink platform. Section 5.2 of the gd6-configuration-guide makes this explicit: ThinkLink MQTT is only available under the ThinkLink vendor combination, and is composed of the following elements:
| Field | Description |
|---|---|
| Broker URI | ssl://... or tcp://..., pointing at the ThinkLink platform |
| Client ID | The gateway's unique identifier on the Broker |
| Username / Password | Broker credentials |
| Topic | MQTT topics for uplink, downlink, status, etc. |
| QoS | QoS 0 / 1 / 2, by message importance |
| TLS Material | One-way / two-way TLS credentials; with mutual TLS, CA, client cert, and client key must be a matching set |
Why does this exist? Because outside of LoRa, MQTT is the de-facto "device protocol gateway" — device → MQTT Broker → business system — the entire chain uses the same message bus. Lifting this pattern onto a LoRaWAN gateway means engineering teams can use a familiar Broker cluster to manage both LoRa end devices and Wi-Fi / 4G devices — the architecture becomes more uniform.
Key MQTT Bridge characteristics:
A critical note: MQTT Bridge and the "remote configuration" channel are two independent connections. gwTool6 dedicates a separate section to "remote configuration," which requires its own Broker, Client ID, Topic, and TLS credentials, and explicitly warns not to confuse the LoRaWAN channel's MQTT credentials with the remote configuration ones — a common on-site troubleshooting pitfall.
Key fact: MQTT Bridge is a transport mode, not a LoRa Alliance specification. It is driven by the ThinkLink-side platform and primarily serves engineering teams that already speak MQTT.
LoRa Basics Station was jointly introduced by Semtech and the LoRa Alliance as the official "replacement" for UDP Packet Forwarder. The "Basics" in the name refers to the fact that it specifies both the connection protocol and the reference implementation as an open-source baseline.
Its architecture is two separate WebSocket / HTTPS interfaces:
wss://<server-address>:8887. All uplink LoRaWAN frames and queued downlink frames flow through it.https://<server-address>:443. CUPS pushes to the gateway the LNS URI, trust chain, and LNS credentials — meaning which NS to connect to, what certificate to use, and which API key to authenticate with can all be remotely controlled by the server.Splitting the data channel from the management channel brings three engineering benefits:
Protocol-stack essentials:
The two authoritative references:
The GW-AN08 practical document summarizes the four core advantages perfectly: Basic Station offers a more efficient WebSocket-based communication, supports dynamic frequency updates (CUPS), has built-in encrypted transport (TLS), and provides superior network management and remote configuration capabilities compared to the traditional UDP Packet Forwarder.
Key fact: Basic Station is the LoRa-Alliance-recommended "modern" backhaul protocol, with WebSocket + TLS + dual channels (LNS for data + CUPS for management) at its core.
Putting the three protocols side by side, item by item (synthesized from Yibyte, Kerlink, and LoRa Alliance official resources):
| Aspect | Semtech UDP PF | ThinkLink MQTT Bridge | LoRa Basics Station |
|---|---|---|---|
| Transport Layer | UDP connectionless | TCP / MQTT long connection (TLS optional) | WebSocket long connection |
| Encryption | No standard (typically cleartext) | TLS / mTLS optional (depends on Broker) | TLS 1.2 / 1.3, mTLS possible |
| Platform Identity Check | None | Via Broker account / TLS | Server root cert + Token / mTLS |
| Link Monitoring | None native, relies on app heartbeat | MQTT keepalive | Native protocol heartbeat + auto-reconnect |
| Remote Configuration / Upgrade | None native | None native (CUPS-like handled by platform) | CUPS interface natively supported |
| NAT / Firewall Friendliness | Poor (requires port mapping) | Good | Good (WebSocket-based) |
| Gateway Resource Usage | Very low (tens of KB RAM enough) | Medium (depends on Broker config) | Medium (impl + TLS + WebSocket) |
| Implementation Complexity | Low | Medium (need Broker integration) | Medium-High (certs, time sync) |
| Cross-Vendor Interoperability | Best (legacy standard) | Platform-dependent | Good (LoRa Alliance spec) |
| Suitable Scenarios | Intranet testing, small scale, cost-sensitive | Platform-as-Broker, unified device message bus | Public network, large scale commercial, high-security |
Note: GD6 (gwTool6 v1.0.3) defaults to BasicStation CUPS under the TTN vendor; Semtech UDP under the ChirpStack vendor (replaced by BasicStation LNS); and ThinkLink MQTT or a delivery-determined option under the ThinkLink vendor.
The LoRaWAN NS page on GD6 (gwTool6 v1.0.3) presents the "vendor × protocol" combinations directly. This table is the first thing to memorize on the engineering side:
| Platform Vendor | Available Protocols | Default Protocol |
|---|---|---|
| ThinkLink | ThinkLink MQTT, Semtech UDP | Determined by factory delivery |
| ChirpStack | Semtech UDP, BasicStation LNS | Semtech UDP |
| TTN / The Things Stack | BasicStation CUPS, BasicStation LNS, Semtech UDP | BasicStation CUPS |
Some hidden rules in this matrix:
basicstation gateway bridge only supports basicstation-lns, not basicstation-cups. When choosing Basic Station, you can only pick LNS.Key fact: The protocol menu and default behavior differ across the three platforms in GD6 — this is the on-site trap that every integration document reiterates.
A "three-step" decision flow you can walk through:
Quick mnemonic:
Testing in intranet? UDP. Production deployment? Basic Station. Platform eats MQTT? Bridge.
If you ultimately choose Basic Station, the following five items are pits you will almost certainly encounter.
The LNS URI must start with wss:// (production); the CUPS URI must start with https://. This means:
The trust field and Token Key field in gwTool6 are stored separately. The Token Key needs to be assembled into a complete HTTP Authorization line, terminated with CRLF (\r\n) — missing one carriage return, TLS passes but 401 persists.
The two keys for CUPS and LNS have different permissions and cannot be interchanged:
Link as Gateway to a Gateway Server for traffic exchange.Once CUPS connects successfully, the LNS URI + credentials + channel plan it pushes override the values you saved locally. When switching back from CUPS to LNS, the old CUPS URI must be actively cleared — this is the root cause of the "switch to direct LNS but still goes through CUPS" trap explicitly warned about in the gwTool6 documentation.
mTLS (mutual TLS) means each gateway needs:
Proper usage: in a highly controlled industrial network or on platforms that mandate mTLS (e.g., AWS IoT Core for LoRaWAN). Most public deployments of TTN / ChirpStack use single TLS + Token only. Don't enable mTLS just "for the sake of looking more secure" — it only adds operations cost; it doesn't make the data itself more confidential.
After saving the protocol choice, gwTool6 performs a cold restart of LoRa forwarding for ~30–60 seconds. This means:
MQTT Bridge, unlike Basic Station, is not as "standardized," but if you deploy the ThinkLink platform, you can't bypass it. A few principles:
Yes, in limited scenarios:
Not recommended for:
GD6 still keeps the UDP PF option, primarily serving: integration with legacy platforms, integration with proprietary self-developed NS, integration with teaching / demo scenarios.
Key fact: UDP PF has now degenerated to an "intranet fallback protocol" — production deployment defaults to Basic Station (public network) or MQTT Bridge (ThinkLink ecosystem).
If your legacy network still uses UDP PF, the recommended migration path is:
The whole migration generally takes 1–2 weeks — provided you've already prepared "maintenance windows" and "credential management."
| Scenario | Recommended Protocol | Key Reason |
|---|---|---|
| Intranet testing / teaching | UDP Packet Forwarder | Simplest, fastest, fewest dependencies |
| TTN public network production | Basic Station (CUPS + LNS) | LoRa Alliance modern standard, remote batch management |
| ChirpStack self-built NS | Basic Station LNS | Compatible with legacy deployments, strongly recommend migrating from UDP |
| ThinkLink platform self-deployment | ThinkLink MQTT Bridge | Unifies MQTT message bus with the platform's other devices |
| Large-scale heterogeneous network (≥100 gateways) | Basic Station + CUPS | Zero-touch provisioning, remote credential rotation, scalable operations |
| Extreme resource-constrained devices | UDP PF | Lowest resource usage, can be trimmed |
| Strict audit / compliance requirements | Basic Station + mTLS or MQTT + mTLS | Mutual certificates + platform identity check |
| Multi-protocol coexistence (heterogeneous NS) | Depends on platform; GD6 can only run one driver at a time | Switch requires 30–60 second cold restart window, plan a maintenance window |
Finally, here are several "taken-for-granted" claims that reappear on engineering sites:
wss:// or ws://, and the LNS server side enforces it.Designing the gateway-to-LNS "last mile" protocol correctly determines the operability and scalability of the entire LoRaWAN network. Semtech UDP PF is "lowest cost," MQTT Bridge is "platform-fit," and Basic Station is "long-termism" — all three are reasonable answers in their respective scenarios.
The GD6 open-source gateway supports all three protocols natively, and the gwTool6 protocol menu automatically recommends a combination per platform. New projects should follow the pattern of Basic Station + LNS (production) + UDP PF (experimentation) from day one; legacy projects should migrate steadily using the pattern of "coexist → switch → wind down."
Reference Documentation
This series is compiled by the ManThink team based on gwTool6 v1.0.3 + LoRa Alliance + Semtech official resources.