LoRaWAN® Introduction

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.

Cisco’s IXM Gateway Datasheet - LoRaWAN® Deployments

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

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 decides 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 the 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:

Application Server Data - LoRaWAN®

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.

Related Devices

Take control of your data

Management

Securely configure, manage, and monitor Digital Matter devices remotely.

Learn more

Integration

Easy integration with comprehensive documentation and a flexible and open payload format.

Learn more

Security

LoRaWAN® networks use AES-128 Encryption so your data is protected.

Learn more

Related Case Studies

Increasing Safety and Visibility with LoRaWAN® and Meshed IoT

Established in 2015, Meshed IoT is providing innovative IoT solutions using the LoRaWAN® network to cities and industries throughout Australia.

View Case Study
Related Case Studies

Asset Tracking & Sensor Monitoring with Restotracker

Learn how Restotracker uses the Remora2 and Bluetooth® Low Energy to remotely track and monitor high value assets and critical sensor data.

View Case Study
Related Case Studies

Asset Tracking in Zimbabwe with EzyTrack

Founded in 2009 in Harare, Zimbabwe, Ezytrack understands the unique solutions local residents and businesses require to protect their assets.

View Case Study
Related Case Studies

Litter Tracking Solutions with RMIT

RMIT University in collaboration with Melbourne Water are on a mission: to educate their community about the environmental and financial implications of littering.

View Case Study
Related Case Studies

Train Tracking & Speed Monitoring with the Gisborne City Vintage Railway

The Gisborne City Vintage Railway Society installed an Oyster2 to a carriage on the WA165, to publish real-time locations whilst out on excursions.

View Case Study
Related Case Studies

Where’s Julius?

To support WIRES, B Braun’s newest recruit Julius the Koala is visiting Vet Clinics and Institutions across the country to spread love and awareness for Australian Wildlife.

View Case Study
Related Case Studies

Pioneering IoT in Malaysia with Xperanti IoT

Digital Matter has partnered with Xperanti IoT, supplying over 11,000 Oyster Sigfox battery-powered GPS tracking devices for affordable asset tracking in Malaysia on the LPWAN Sigfox Network.

View Case Study
Related Case Studies

Concrete Mixer Tip Detection and Utilization with VolkerFitzpatrick

VolkerFitzpatrick required a robust battery-powered GPS tracking device that is capable of collecting date, GPS location, and tip detection data.

View Case Study
Related Case Studies

Digicore and Iridium Satellite Fallback has Snowy Hydro Covered

Digicore, a Melbourne-based telematics company specializes in IVMS solutions in the mining, transport, and government sectors.

View Case Study
Related Case Studies

Rhino 911 – GPS Tracking for Poaching Prevention

Rhino 911 is using Digital Matter's Oyster2 GPS device and Telematics Guru to help prevent poaching and habitat destruction in South Africa.

View Case Study
Related Case Studies

Bicycle Fleet Tracking with Bikes Make Life Better

Learn how Bikes Make Life Better is using the Oyster2 battery-powered GPS to track and monitor over 2,500 bicycles.

View Case Study
Related Case Studies

Improving Farm Safety and Management with LoRaWAN and Farmdeck

Outcomex is improving productivity and safety across rural Australia with LoRaWAN®, Digital Matter devices, and their own in-house application, Farmdeck.

View Case Study

How can we help you?