Difference between only packet forwarders vs packet forwarders + gateway Bridge devices

Hi, looking at the Lora Server infrastructure, I have a question. Why are there 2 kinds of devices(packet forwarder+ gateway Bridge) and (packet forwarder)?
What is the difference between this 2 types?
Are there different devices if I decide to work with one types or the other?
And the most important: the devices that only are packet forwarder are cheaper than the PF+ Bridge? :wink:

Thanks, regards

Different use cases for different devices with different capabilities. The big win for running the gateway bridge on the device itself is a.) you don’t need to run a large gateway bridge in your infrastructure - i.e. it spreads that load across all your gateways and b.) you have the option of TLS-encrypted gateway payloads.

We’ve run MultiTech Conduit APs (in AEP mode) and Tektelic KONA Micros in both UDP packet forwarder-only and gateway bridge modes, and they’ve been equally reliable. Simpler devices may only support the packet forwarder modes (Tektelic Pico, etc).

Ok. Thanks.
Ten, If I had enought resources to build a l large Lora Server (with a large Bridge service), I only would need packet forwarders devices,isn’it?

And for the security reason, don’t worry me. Because I’ll make secure the udp transport network.

I didn’t know this kind of devices (only packet forwarders). My idea was to buy a pair of rak831 pilot gateways and register them to my own Lora Server with enought resources.
But if there was or you know any “only packet forwarder” cheaper and more reliable than that, I Will be very pleasant of your info.

Thanks, regards

I don’t have extensive experience with different gateways. Here are some you might consider (2 links):


Ok ok. Thanks a lot bconway

The expensive part of a gateway is the radio hardware.

Having a computer able to speak MQTT is fairly trivial - something like an ESP8266 could do it if the firmware were written with that goal from the start.

Having one able to run both a legacy forwarder and the legacy-to-MQTT bridge is a little more complex, but for anything running Linux more a configuration challenge than a hardware cost.

Because I’ll make secure the udp transport network.

That’s likely harder than running the UDP-to-MQTT locally.

Note if you buy the low end indoor TTN gateway it’s unclear if you would be able to use it on anything other than TTN, without devising your own software stack for it.


Perfectly explained, cstratton. Now I have everything more clear. thanks for the clarification

It uses the Basic Station forwarder, which… is supported by LoRa Gateway Bridge v3 (test release). https://forum.loraserver.io/t/announcement-lora-gateway-bridge-v3-0-0-test-release/4296

The only thing that you need is to re-configure the gateway to connect to a different endpoint (your LoRa Gateway Bridge instance instead of TTN). I’m not sure what the best way is for this and if this will be supported.

In this case the gateway has a Websocket connection to the LoRa Gateway Bridge with an option to use TLS, removing the need to run the LoRa Gateway Bridge on the gateway.

Thanks a lot, brocaar. For now, as we are newbies, we’re going to start our project with the pair of rak381 gateways as pf + bridge, and the stable version of Lora server.
Then, when we accomplished connect our nodes, we will start to integrate node red, influxdb and grafana.
So, soon you,ll have news of us. :wink:
Thank you so much.

Hi @bconway , Im looking at buing the MultiTech Conduit AP and use it as my only Gateway. You said you’ve run it in AEP mode with chirpstack gateway bridge. Do you imply it only works when its in AEP mode? Maybe I’ve misunderstood, but my question are, can you utilize chirpstack gateway bridge on MultiTech Conduit AP when its my only gateway?

Wow, old thread.

Yes, MultiTech Conduit (AP) is still one of my preferred gateway platforms. Using mPower/AEP mode is highly recommended over mLinux, and that’s how the ChirpStack documentation is written:


I’m running Gateway Bridge on the Conduit AP gateway very successfully, and currently have the v4 MQTT Forwarder in testing.

1 Like