EDGE Gateway with ChirpStack and RAK7243

Hi guys

I would like to get your thoughts about our planned architecture for an upcoming project. A bit lengthy, but hopefully others can benefit from this discussion about creating Smart/Edge lorawan gateways

We chose the RAK7243 gateway for an agri-tech project we are deploying this year. We plan to deploy few dozen gateways in rural areas on solar power with LTE backhaul.

** edit**
Reason for this choice of GW: We require a low-power LoRaWAN GW with 4G/LTE, GPS, USB Host, and Linux to install special sensor drivers on. Affordable as well. This narrows the GW market dramatically :slight_smile:

Our gateway will only try to get cellular connectivity every 30 minutes for 5 minutes to upload accumulated data. Besides to receiving some sensor data via lorawan, it also has some other peripherals connected to it (sensors/cameras) directly which it will sample and upload to the cloud.

Our main constrains are:

  • Minimize power consumption due to solar power
  • Work offline due to unstable cellular connectivity

Things we do not care about:
Devices communicating.joining the same network via multiple gateways

Since we do not want to relay on cellular connectivity for the lorawan network to work so we decided to go with the full chirpstack install on each gateway (like the gateway-os-full image, but for now we are using the RAK version of it)

So the main things we need to figure out are:

  1. How to provision devices on the gateway remotely

option 1: remote join server

  • I cannot find still good examples on how to setup such external join servers, anyone has code example?
  • GW will still need cellular connectivity to accept new device join requests

option 2: a script on the GW that will check my own db for devices to add and will self-provision devices locally onto the app server using the api

  • once a device is provisioned onto the gw, it can join without backhaul connectivity.
  1. How to store upLink messages between each backhaul dump
  • Option 1: I am thinking the postgresql integration is the way to go here
  • Option 2: Create some local service and point http integration to it, store incoming packets as .json files
  1. How to send remote downLink messages to each end-device
  • Option 1: The gateway will subscribe to a topic and will receive intended messages to devices that are listed as provisioned to it. The GW will post the messages locally to the end-devices using MQTT topic or API

  • Option 2: ideas?

  1. Remote software / configuration updates of gateway stack
    Obviously by not using a central network server, we need the ability to make config changes to the various elements.
  • option 1: if we manage to build our custom gateway-os image, or not, we will try to use mender.io for this, either as a full image FOTA or configuration change only.

Well guys, I know that lorawan wasn’t intended at first for such use-cases (low-power, limited backhaul with potential high-latency), or for the gateways to being smart, but I think the real-world, especially with agri-tech is taking this technology there. So I hope that the alliance will also make adaptations that will make this sort of processes more streamlined, for example,

I think I learned that Basic Station has a message buffer now? I know that some GW providers do utilize a message buffer for no-connection periods.


Am I overthinking this? Can I use a buffer on the Gateway, or maybe something local Gateway bridge to accomplish this? This will solve me the keep-data when there is no cellular connectivity but it will still not solve the join-request when offline, or downlink situation right?

Cheers :sunny:

Adding to my discussion here further

regarding the gateway with gateway-bridge and a buffer. Any ideas on how this can be done? Is it something that basic station supports perhaps?

We have done quite a lot of agriculture stuff, see www.sensefarm.com for more info and our info@ adress if its interesting.

A GSM modem is not what will consume your power. If there are no transmissions they are usually around 1mA while connected to the network. We have something similar and the power is about 200 mA to the gateway board, and about 200 mA for the Raspberry. Thus having it on a lead-battery and solar panel of a size of 50x50 cm gets us through the growing season. march-september locally. ( 58 degrees north of the equator )

We are currently running a modfied version of the full gateway-os, and I just run into some issues with it ( that’s why I’m on the forum ). We have lost contact with the redis database controlling the gateway so nothing works… This is after about one month in the field on this special gateway. Another one is doing fine.

Using the same gateway os, there are problems with booting up the raspberry as well. It sometimes get stuck and can’t find a disk and just hangs before monit and supervision of the device is started, so major problems.

Otherwise good luck! Seems as an interesting project.

To answer your other questions - I see that RabbitMQ as backend was just released. Since I love RabbitMQ I would use it as queues for messages that needs to be delivered on an unreliable connection. It’s one of the most stable software packages I have seen. We have run it since 2012 on other services. Really good! But read and understand the concepts behind it ( of course ;-).