Configuring LoraWan Gateway

Question

I'm trying to build a LoRaWan Network using a sensor programmable with Arduino and a Dragino Lora Shield.

I have found many solutions for creating a gateway, including an Raspberry Pi connected with another Dragino Lora Shield or with iC880A, and the data I receive will be sent do a server in the cloud. I am very confused about programming the gateway.

• Do I need to tell it to connect to the node and to the server? Or does it receive the data automatically?
• And do I program the server to connect to the gateway or directly to the nodes?

Answer 1

In a typical LoRaWAN network, gateways are dumb devices, as explained by the LoRa Alliance:

LoRaWAN network architecture is typically laid out in a star-of-stars topology in which gateways is a transparent bridge relaying messages between end-devices and a central network server in the backend.

So, a gateway only needs to be configured to connect to some network server, such as the open The Things Network. That's all.

Gateways are often referred to as "packet forwarders". As such, gateways do just that: they forward all received LoRaWAN packets to some network server (regardless which node sent it), and they transmit whatever commanded by the network server. Hence, nodes (end-devices) do not connect to some gateway; instead they just transmit and hope one or more gateways receive their transmission and forward that to the network server that knows the node. (Gateways cannot read the encrypted data they're forwarding.)

To connect nodes to the network, they are "activated" using either of two options:

• Over-The-Air Activation (OTAA)

  First, using some web site or API, each new node is registered in the network server using its unique device EUI (DevEUI). It then gets a public application id (AppEUI) and a secret application key (AppKey). These three values are programmed into the node.

  Next, when ready to send for the first time, the values are used by the node to create and transmit a LoRaWAN Join Request. If such request is received by one or more gateways, it is forwarded to the network server which, if approved, will tell one gateway to transmit a Join Accept. If received by the node, then this gives the node a public device address (DevAddr), a secret network session key (NwkSKey) and a secret application session key (AppSKey).

  The values determined from the Join Accept are used whenever the node needs to transmit some actual data (along with a security counter that starts at zero whenever joining). The activation is valid as long as the node keeps it in memory (and the security counters have not been exhausted), typically for many months or even years. Whenever lost, a node can send a new Join Request and get new secrets.

• Activation By Personalization (ABP)

  Here, when registering using some web site or API, the node is given a device address (DevAddr), secret network session key (NwkSKey) and secret application session key (AppSKey) right away, which are programmed into the node and never change. The node does not need to first send a Join Request before it can start sending any data, but care needs to be taken that the security counters are not lost. Also, the keys are specific for a given network; APB makes it hard (if not impossible) to move nodes to a different network provider.

Answer 2

The answer by Arjan is good. Technical. I wanted to provide a different flavor answer to help those who are new and struggling to put the picture together in regards to gateways and how packets move back and forth.

Analogy...

You > Letter > Mailbox > Mailman > Post Office Dist > Recipient

|----------------- TX -------------------|

Node > Packet > Transmission > Gateway > Network Server > Application

|----------------- RX -------------------|

Node < Packet < Transmission < Gateway < Network Server < Application

Letter/Packet has an address. The mailman/gateway picks up the letter from your mailbox or whatever mailbox you dropped your letter in. It gets handled all the way to the recipient. If the address is wrong, it wont arrive and you should get notified of that. The recipient can send a letter back to you through the same system.

Whether you're going to utilize the The Things Network or try to build your own private server using something like LoRaServer you will need a gateway within reach of your node/mote/end-device to forward messages back and forth. Think of the different keys in the node's code as the addresses on the letter in the analogy.

You can determine if there's already a TTN gateway in your area on their map page and if there is one in reach of your node, your messages should reach your TTN (assuming you have registered and applied the keys to your node). If there's not a gateway within reach, you can build your own. There's many options to do that.

In regards to configuring the gateway, depending on which library you choose, you typically just need to configure some parameters either in the source code or in a global_conf.json or local_conf.json file.

Here's an example from tinkering with a RFM9X (based on SX1276) and a RPI3 B+ using single_chan_pkt_fwd which btw will not provide responses... keep in mind this is just for tinkering/testing. Both the forwarder and below global_conf.json examples are not plug-n-play and should not be relied on for proper LoRaWan networking. A compliant gateway has 3 radios and can process multiple channels and send/receive at the same time. This example is just receive from node on single channel and is not very reliable but does present configuration. Each of the values depends on the hardware you're using and where you're located... or where the gateway is located such as US, EU, etc... also worth noting that such global_conf.json is not a one size fits all. Different libraries typically have more config options for multiple radios, channels, etc... just FYI.

{
  "SX127x_conf": // depending on your hardware/radio this could be something like sx1301..., sx127x...., etc.. 
  {
    "freq": 903000000, // depending on whether US (900 range), EU (800 range) or other...
    "spread_factor": 7, // look this up
    "pin_nss": 10, // wiringpi value = physical pin #24
    "pin_dio0": 5, // wiringpi value = physical pin #18
    "pin_rst": 21 // wiringpi value = physical pin #29
  },
  "gateway_conf":
  {
    "ref_latitude": 0.0, 
    "ref_longitude": 0.0,
    "ref_altitude": 2,

    "name": "WHATEVER NAME",
    "email": "[email protected]",
    "desc": "WHATEVER DESC",

    "servers":
    [
      {
        "address": "localhost", // this one is private so localhost, but TTN lookup address
        "port": 1700, // this one is private so localhost, but TTN lookup port
        "enabled": true
      } // you could add more... say you have a private one and TTN 
    ]
  }
}

Let's say you're building a node with Arduino device and code. And you use something like LMIC-Arduino library and example sketch. You first have to determine based on the device hardware how to configure the pinmap for the device to even work. Then if you're going to use TTN, you follow any of the many guides to register and get the needed keys that you put into the sketch code. You also have to make sure that you're transmitting on the appropriate frequency and such... to line up with the gateway in your area.