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?
  • 2
    Welcome to the site. Can you add a few information about which models of devices you're using and add some more details about your use case? This will help us to give you better answers.
    – Helmar
    Commented Feb 22, 2017 at 12:55
  • Hi and thanks ! I am a beginner in Iot networks so I created a node using an arduino uno, a temperature sensor and a Dragino Lora Shield, i am trying to send the date to a server so i tried creating a LoraWan Gateway using a raspberry pi, I made some research on how to transform it into a LoraWan Gateway and i found out that i can using either another Dragino Lora Shield or with an iC880A module, and i found the source code to do it, but i am still confused about how to connect the gateway to the node, and how to send the data from the node to the gateway to the server ?? thanks in advance !! Commented Feb 22, 2017 at 13:22

2 Answers 2


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.

  • 1
    Some special gateways include a LoRaWAN network server and can act as standalone networks. But most must be connected to an external Network Server. I have removed my answer which wasn't clear enough on that point.
    – Sylvain
    Commented Jun 12, 2017 at 18:16

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.


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
    "ref_latitude": 0.0, 
    "ref_longitude": 0.0,
    "ref_altitude": 2,

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

        "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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.