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.
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 acknowledgement 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.
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.
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.
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.
Example Application Server Data
On The Things Network, the data being POSTed to the server looks something like this:
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.
