LoRaWAN Introduction

blue background

LoRaWAN Introduction and primer

LoRaWAN deployments are made up of 4 components:
  1. LoRaWAN devices / sensors
  2. LoRaWAN gateways
  3. One or more layers of network servers, depending on the network
  4. An application server, where the data eventually ends up
This diagram from Cisco’s IXM Gateway Datasheet illustrates the concepts quite well.

1) The LoRaWAN Device / Sensor

LoRaWAN Class A devices use a simple ‘client talks first’ protocol.
At startup, the device sends a network join request, and receives a response from a nearby gateway.
After that, the device periodically sends a message, and waits for a response.
When set up for maximum range, the transmission uses in the order of 130 mA, for 1 or 2 seconds.
Reception takes place 1 second after transmission, using in the order of 15 mA for a similar time, or just milliseconds if there is no response.
All messages are encrypted with a device specific pre-shared key, and identified by the device serial number.
In Australia, the transmissions are in the unlicensed 915-928 MHz band, and are subject to interference from other users.

You need to make sure that your devices aren’t transmitting too often, or they will interfere with each other. On the order of 1 message per second per gateway is about the upper limit on an 8-channel gateway.

So if you have 300 units, that’s one message every 5 minutes.
If you buy a fancy gateway with more channels, you can send proportionally more often.
You can configure the units to transmit faster in order to increase capacity. A 4x increase in speed will give a 4x increase in capacity, at the cost of a 50% reduction in range.
In the EU and many other countries, the law imposes a 1% duty cycle restriction, preventing transmission more than once every 2 minutes, and making acknowledgment by the gateway impractical.
  • You buy the device, register it with your network server using the printed label, and turn it on
  • You may have to configure its network channels using a USB cable
  • Further configuration is done over the air
  • Any future firmware updates must be done with a USB cable
This is what we do! We design and manufacture LoRaWAN devices and sensors. Click here for our range.

2) The Gateway

The gateway receives messages in a 10 to 20 km radius, and forwards them to the network.
Gateways start at about $300 for a commodity 8 channel gateway with ethernet backhaul.
The gateway is a dumb packet forwarding device. It doesn’t understand the contents of the packets, or decide what to send back. The network server does these things.
Almost all gateways support the Semtech Packet Forwarder protocol, which is usually operated on UDP port 1700.
It isn’t encrypted, and the gateways aren’t authenticated.
But all mobile device data is encrypted with pre-shared keys.
So locking down the IP addresses and port numbers between the gateway and the network server should provide sufficient security.
Networks servers will often support their own proprietary packet forwarding protocol as well.
You buy the gateway, put it on a mast, connect it to the backhaul, and configure it to point to your network server.

3) The Network Server

The network server is responsible for receiving multiple copies of the transmitted packets, decrypting and deduplicating them, and then forwarding the payloads to whatever application server the end user requires.
When you provision a device onto the network, you register its serial number and pre-shared encryption key with the network server.
In future versions of LoRaWAN, you will be able to use a second encryption key to prevent the network server from understanding the data it sends to the application server, but this is not practical in LoRaWAN 1.0. So the network server must be trusted by the end user.
You can either host your own network server (commercial or open source), or use a public network server such as The Things Network.

4) The Application Server

This is final destination of the data. Most networks will push data to your application server in their own proprietary JSON format, as either an HTTP POST, or an MQTT topic.
You can write your own application server and store the data in your own database, or you can use an existing server with a web frontend such as Telematics Guru.

5) Example Application Server Data

On The Things Network, the data being POSTed to the server looks something like this:
    "app_id": "my-app-id",                 // Same as in the topic
    "dev_id": "my-dev-id",                 // Same as in the topic
    "hardware_serial": "0102030405060708", // In case of LoRaWAN: the DevEUI
    "port": 1,                             // LoRaWAN FPort
    "counter": 2,                          // LoRaWAN frame counter
    "is_retry": false,                     // Is set to true if this message is a retry
    "confirmed": false,                    // Is set to true if this message was a confirmed message
    "payload_raw": "AQIDBA==",             // Base64 encoded payload: [0x01, 0x02, 0x03, 0x04]
    "metadata": {
      "time": "1970-01-01T00:00:00Z",   // Time when the server received the message
      "frequency": 868.1,               // Frequency at which the message was sent
      "modulation": "LORA",             // Modulation that was used - LORA or FSK
      "data_rate": "SF7BW125",          // Data rate that was used - if LORA modulation
      "bit_rate": 50000,                // Bit rate that was used - if FSK modulation
      "coding_rate": "4/5",             // Coding rate that was used
      "gateways": [
          "gtw_id": "ttn-herengracht-ams", // EUI of the gateway
          "timestamp": 12345,              // Timestamp when the gateway received the message
          "time": "1970-01-01T00:00:00Z",  // Time when the gateway received the message
          "channel": 0,                    // Channel where the gateway received the message
          "rssi": -25,                     // Signal strength of the received message
          "snr": 5,                        // Signal to noise ratio of the received message
          "rf_chain": 0,                   // RF chain where the gateway received the message
          "latitude": 52.1234,             // Latitude of the gateway reported in its status updates
          "longitude": 6.1234,             // Longitude of the gateway
          "altitude": 6                    // Altitude of the gateway
        //...more if received by more gateways...
      "latitude": 52.2345,                 // Latitude of the device
      "longitude": 6.2345,                 // Longitude of the device
      "altitude": 2                        // Altitude of the device
    "downlink_url": "https://integrations.thethingsnetwork.org/.../my-process-id?key=ttn-account-v2.secret"

The important data is extracted from the payload_raw field, interpreted by your server, stored in your database, and then displayed on your website or App.

Check out our range of LoRaWAN devices.