Migrate any LoRaWAN gateway to helium network as a Data-Only hotspot

Migrating existing LoRaWAN network to Helium or joining Helium for new deployment is accessing to the world largest LoRaWAN network and enable your devices to be deployed in the large covered zone. By doing this you extends the community network and as a counter part getting benefit on future data transfer and immediately get an access to the low cost ecosystem (data transfer, network server, high redundancy network…)

In a previous post I explained how to configure a RAK Wisgate as a Helium Data-Only hotspot. In a such situation your LoRaWAN gateway becomes a hotspot relaying the Helium traffic and getting some little rewards for the data transfer. The more important is to extend the coverage. This way of doing is good but I’ve got some issues on the field: The data transfer from the hotspot to the blockchain (even if just the state channels) is high and the software, currently in alpha, is not totally stable. When deploying a gateway is isolated area to provide new coverage, honestly, these two issues are blocking points.

The second important consideration is the existing gateways, already deployed on the field: they are currently used for private networks. They have been deployed some years ago and are not in the compatibility list of Helium hardware. Even if they are, deploying a new software on them, remotely can be a problem.

For these different reasons, I’ve been investigating a different approach by creating centrally hosted hotspots connected to different LoRaWAN gateways through the legacy Semtech protocol. This is what we are going to detail on this blog-post.

Architecture

Centralized Gateway-Rs architecture to migrate existing LoRAWAN network to Helium

On the schema above, you can see different elements:

  • GATEWAYS : are the LoRaWAN gateways you want to deploy or you want to migrate into Helium network.
  • GATEWAYS-RS : are the piece of software you need to run for each of the LoRaWAN gateways to make them using Helium network.
  • P2P NETWORK : The gateway-rs software is relaying the LoRAWAN traffic to the LoRa Network Servers (also called ROUTER) over a P2P network and short duration blockchain called state-channel. The State Channel contains the transaction between the Gateways and the Network servers. Gateway-RS manages this link transparently for you.
  • NETWORK SERVERS : This are the Helium LoRaWAN Network servers, also called router. The particularity of Helium is to be able to manage different router in a decentralized perspective. This layer is existing, you just need to add your devices and integration definition to route the devices data to your application server. Your device credentials can be preserved when migrating to Helium.
  • APPLICATION SERVER: Is the final layer where the data from devices are transformed into an added value service. This layer may already exists for you application and you just need to update your integration layer to receive data from Helium routers. Many standard integration exists (Https, MQTT, Azure IoT Hub…)

Configure a back-end server for running gateway-rs software

You can use a simple backend server to run multiple gateway-rs software. You need one for each of the LoRaWAN gateways you want to join Helium network. For this, the simpler way I found was to create a Docker containers running the gateway-rs software.

As this software has been designed to run on a LoRaWAN gateway it is really low resource consuming. Each of the docker container will consume about 2% vCore and 3MB memory. this means you can run a lot of different LoRaWAN gateways on a single server.

Gateway RS container CPU consumption profile

For each of the different LoRaWAN gateway, we are going to use a different UDP port to route the traffic to the right container. So the configuration on the gateway will just be a different port setting for each of them.

On this server, you just need to generate and deploy the Docker container from Helium Gateway RS Docker github project. The project page contains the needed documentation.

If you do not want to manage this, you can also got to a managed solution with Helium-Iot.eu

Have an Helium Wallet

To migrate your gateways to the Helium network, you have a one shot on boarding fee, this one is composed by two parts:

  • On boarding – register the hotspot on the helium network, it costs $10
  • Positioning – register the hotspot location, it costs $5

In case you change the hotspot position you just need to pay a new positioning transaction.

As a counter part, the hotspot earn token for relaying the data ( $1 per 100.000 helium messages).

To execute these transactions, you need to have an helium wallet accessible with a CLI. You can take a look on my first blog post about helium for this. This wallets need to have a sufficient amount of HNT on it to execute the transactions.

Deploy / Migrate a gateway

Register the gateway

You simply need to run the project script to create a new Gateway-RS container. The parameter will define the following input:

./run.sh \ 
    -c ../rs/myGwId \ # Directory where the GW data will be stored
    -p 5000 \   # UDP Port to be used for this gateway (uniq)
    -z EU868 \  # Gateway zone
    -o 13ZhVBrEJLAaHKQ2XXXXXX \ # owner helium wallet ID
    --update false  # disable auto-update for gw-rs

For each of the gateway you are going to migrate / deploy, your will have a separated directory with all the gateway information. This is about 100Kb storage for each of them. The directory contains different files:

default.toml          # default config file, do not touch 
gateway_key.bin       # gateway Key ## SAVE THIS PRECIOUSLY 
install_update   
port                  # UDP Port number to be used
settings.toml         # Gateway specific settings (set by script)
sharp-tangelo-alpaca  # Helium name of this gateway

When you run the run.sh script for the first time, it will print on screen a transaction ID to register the hotspot on the chain with the helium wallet. Then you will need to execute the positioning transaction. These steps and the associated command line are described in the gateway rs docker container github project.

Once done your gateway rs is running and listening on the UDP port for your LoRaWAN gateway traffic.

The next time you want to restart the docker container, you just need to use the follwoing command:

./run.sh -c ../rs/myGwId

With the directory path, the script will automatically find the configuration.

Configure your LoRaWAN gateway

Once the Gateway-RS software is running, you simply need to change your LoRaWan gateway packet forwarder to reach it.

For this you need to setup a Semtech UDP forwarder to the attributed port and the server IP/DNS address.

There is nothing more to do. Once done, the device communications are relayed to the Helium routers and they can acquire traffic belonging to them.

2 thoughts on “Migrate any LoRaWAN gateway to helium network as a Data-Only hotspot

  1. Hello, I have all this setup to some degree, just not asserted or added to chain. I’m a little confused about packet forwarded IP /DNS info. In order to mine where must this point? What accounts or service do I need? TTN and another often come up but I don’t get the helium link. DIY hardware

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.