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? 
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). [announcement] LoRa Gateway Bridge v3.0.0 - test release - Announcements - ChirpStack Community Forum
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.
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:
https://www.chirpstack.io/docs/chirpstack-gateway-bridge/install/multitech.html
Iâm running Gateway Bridge on the Conduit AP gateway very successfully, and currently have the v4 MQTT Forwarder in testing.