RAK7249 Built-In Server integration to be used with other gateways

I am trying to integrate an external gateway that pushes UDP packets to a third party lora gateway bridge. Is there any configuration within the RAK7249 that allows it to receive such packets?

Alternatively is there some documentaion/explanation as to how the RAK7249 Lora Server Stack works? I am assuming that the Lora Gateway Bridge is already embedded in to the gateway and then the gateway forwards the data through an internal MQTT bridge to the Built-In Lora server. Is this correct?

Dear Sebb,

Only one of the three protocols can be used.

Thank you Nicholas for your quick response but I think I worded my question wrong. I’ll write it down in dot points and then maybe I can communicate it better with more information as to what I am asking.

  • I currently have two Lora gateways one is a RAK7249 and the other let’s call it gateway X.
  • I currently have a working system with the RAK7249. Where the packet forwarder of the RAK7249 talks to the Build-in LoRa server as per your screenshot and it works fine.
  • I would like to extend the Lora coverage due to some black spot areas where the gateways will be located (lots of hills). Therefore I am testing gateway X to determine whether it can support that.
  • The reasons why I am testing Gateway X instead of two RAK7249 is smaller, lighter and of course a basic level gateway which does not have as many features as to what the RAK7249 has, which is enough for what it is required to do.
  • Gateway X forwards UDP packets using the semtech UDP protocol to a third party server much like the chirpstack system. I assume in a similar method as to what you showed me on the screenshot of the Semtech UDP Protocol.

My questions broken down in further points are:

  1. Can those UDP packets be forwarded from another gateway to the Build-in Lora Server of the RAK7249 or is that something just not possible?

  2. If not: Does that mean I would have to integrate both RAK7249 and gateway X to a system like the chirpstack network server so I can manage both gateways?

  3. If yes: How would that be possible?

Dear Sebb,

I see what you mean. You want to make networking happen!
Please refer this web:https://doc.rakwireless.com/rak7249-macro-outdoor-gateway/rak7249-build-in-lora-server-multi-rak-gateway-mesh-rak811

Best regards!

While you can do this, typically in practice once you have multiple gateways it makes sense to run the lorawan network server component (which in this case is an older version of the project now known as Chirpstack) in the cloud rather than on the gateway.

One reason is that it’s typically easier to get Internet connectivity from a gateway to the cloud, than it is from gateway to gateway. Another issue is reliability - your node session data sits in the cloud and hopefully offline backups), not on a field deployed box which could be damaged or stolen.

An additional potential concern is that the other gateway currently forwarding to chirpstack via a bridge may be ending up with a newer version of the chirpstack MQTT bridge protocol than the server built into the 7249 may support. But you can try it, and if you really want to you can find a version of the gateway bridge component which speaks the older protocol.

@Nicholas Yes networking! (not my biggest strength) but I will try and give it a go using the guide however the brief reading I’ve done on that guide and from my understanding the lora network server works such that.

My point being is that I highly doubt gateway X has a Lora bridge configuration on the actual gateway because on the config.json file it expects to be given a server address with port 1700 which is the most “common” Lora gateway bridge port. Which then makes the external MQTT broker arrangement hard to make it work. Gateway X runs openwrt so I will try and install a mosquitto package and give it a go to see what happens, thank you for your suggestion and information.

@cstratton Thank you for your response as well and I think you have put forward some very valid points that makes taking care of the Lora server stack somewhere else other than the gateway as a preferred arrangement. Being reducing the risk of single point of failure host it somewhere else and interoperability of communication protocol versions as you mentioned. However I just have some queries in regards to part of your statement

In this scenario the gateways will be on the same network so gateway to gateway communication is not too much of an issue but I think I understand what you are saying, a “physical layer” of communication between gateways is not the easiest thing to achieve. That being said, you kept mentioning cloud installations but due to a limited internet connectivity of this deployment it might be difficult, hence why I was trying to leverage what was already there. Do you think a self hosted Lora network stack on a local server would be sufficient in this case?

This is actually fairly meaningless, as that’s the standard port for all of talking UDP to a network server, talking UDP to an external UDP-to-MQTT bridge, and talking UDP to an internal one.

Not at all. You’re likely to have more luck with an external bridge than trying to get one to run on your mystery box (Dragino?) and anyway, the bridge is entirely independent of the broker.

Your insistence on referring to Gayeway X rather than just telling us what it is, is going to hamper our ability to advise you?

I can’t imagine why you need to keep it’s identity secret.

And if it’s all on the same lan, why not run Chirpstack on a small device?

@cstratton Completely agree with you that the UDP port number is trivial therefore meaningless. Hence the quote marks on most “common” port. But it is however part of the gateway packet forwarder server settings which led me to assume that is how it works. And yes completely agree as well that it could very much be just a port where the data gets sent to and from there it gets distributed based on the network architecture. Which is kind of like how the RAK7249 seems to work when using the build in server. It binds the internal UDP communication port to a MQTT bridge that then talks to the built in server or at least that’s how I seem to understand it.

“gateway_conf”: {
“server_address”: “x.x.x.x.”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“keepalive_interval”: 10,
“stat_interval”: 30,
“push_timeout_ms”: 100,
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: false,
“gps_tty_path”: “/dev/ttyS1”,
}

Yes also agree, I may need more luck with getting the product developers to reply to any of my queries. But completely in line with your statement, and based on your previous advice I’ve already started working on the external solution.

@nmcc

I somewhat understand where you are coming from and I appreciate your help and knowledge. All I was trying to do was the whole let’s keep it professional and let’s not name and shame in the event of the other gateway was the issue. Having said that, their product documentation is not the best and I would say for an “off the shelf” product, it is designed such that you are expected to know a bit more than average about Lora (I am trying to get there slowly) or at least when you compare it to the RAK7249. I’ll give you a hint the name doesn’t vary much from what I’ve been referring to it, instead of gateway change it to something that you use to start a fire.

With @cstratton previous advice and stated in my last reply, that is what I am currently working on. I just wasn’t sure that was the right course of action.