Building a LoRA WAN gateway (and supplying data for the things network)

Since I’ve done that again and it’s really really simple … I’ll add a quick note about that here ..

What is LoRAWan?

The Long Range Wide Area Network is a low power wireless network protocol. It uses a chirp spread spectrum modulation system called “LoRA” that has been patented by Semtech Corporation. It can be used freely without charge - and there are networks like “The Things Network” that provide wide area backbone for LoRA applications. It allows data rates between 292 bps and 50 kbps (depending on requirements and signal quality - i.e. spread factor) - higher datarates offer smaller range and lead to higher power consumption. Because LoRA operated in license free spectrum (SRD band - 863MHz - 870MHz in Europe) there are limits that one is allowed to not exceed. These limits include a maximum of at max. 30 seconds uplink per day - one should keep the message size (sent by a single device) below 12 bytes per message, downlink on TTN is limited to 10 messages per day per device and uplink should be spaced at a minimum of 5 minutes. This leads to the required 1% duty cycle. Of course lower message rates are always better (there is - for example - no need for a temperature or moisture sensor to send packets more often then every half an hour).

The system has been optimized for embedded applications - LoRA devices normally require idle current of about 100 nA to 10 mA which allows battery operated devices to operate up to 15 years continuously. Ranges that are reachable go up to 700 km (see this example communicating with an helium baloon for example) under ideal conditions - the high link budget of up to 154 dB allow reception even under bad conditions like in basements or rows of houses. Because of the high link budget antenna quality is not of a high priority in most cases.

The “WAN” part of LoRA is realized by providing a network of gateways which receive data packets of all nodes in their vicinity (up to 700 km distance) and transmitting them to a distributed message broker that’s provided by an service provider - like for example the community driven “The Things Network”. Alternative providers of course do exist but to my knowledge none of them provides compareable coverage to the TTN. Applications register devices that are bound to them with the message broker system and receive all copies of messages that match their device identifiers via a messaging protocol like MQTT. Getting a copy of each received message from each gateway allows easier implementation of message routing for the TTN as well as implementation of features like multilateration (i.e. locating the device by timing - which is especially possible because of larger spacing of the gateways). Multilateration is additionally enhanced by gateways performing time tagging via GPS based time synchronization (not common view though).

Device classes

Embedded devices are categorized into three different classes:

• Class A devices are always in sleep mode except when they want to transmit data. Server side applications are only capable of sheduling downlink packets after uplink action occured. Downlink packets are queued on the backbone network until reception of messages on any gateway attached to the network. The downlink packet is transmitted in the first or second receive (1s and 2s) window after the device transmitted it’s uplink packet - the network may use either the first or the second but not both downlink windows. Downlink packets are sent on the same gateways that have received the device packets.
• Class B devices synchronize their internal clocks to a periodically transmitted beacon. This beacon is sent by all gateways simultanously (this is done by utilizing GPS as a time synchronization mechanism). The beacon is normally transmitted every 128 seconds. Receive windows are sheduled relative to the beacons which enables downlink to these devices even when they’re not actively transmitting data - on the other hand it requires the network to know which gateways should transmit which frames without “seeing” the devices transmitting. Because of this class B devices are currently not supported by the community operated “the things network” (but can be used on private networks)
• Class C devices extend the receive window to infinity - which means they are always capable of receiving whenever they are not transmitting. This requires - compared to class A and class B - substantial amounts of power and is normally not suited for embedded applications. Again the network has to be capable of determining which gateways should transmit the downlink message - again class C devices are currently not supported by the community operated “the things network” (but can be used on private networks)

Frequency bands

LoRA operates in unlicensed ISM (Industrial, scientific and medical) radio bands. Depending on the geographic reagion various frequency bands are used. Because of regulations for license free ISM bands most channels have a maximum duty cycle of 1% or even 0.1%.

• US: 902-928 MHz (dedicated uplink and downlink bands, 8 subbands)
• Australia: 915-928 MHz (dedicated uplink and downlink, 8 subbands)
• China: 779-787 MHz and 470-510 MHz (96 uplink channels, 48 downlink channels; In some areas some frequencies are dedicated to China Electric Power which means they are not allowed to be used)
• Europe: 863-870 MHz (8 Subbands, specific dutycycle for each!)

Why to build a gateway

There are many cases why one would want to build his own gateway:

• Operate an own network (not a good idea in most cases - even if one only wants to use LoRA devices locally only it’s nice to send at least all unknown messages upstream to the TTN)
• Extend the TTN to other areas that are currently not covered
• Enhance coverage of the TTN in on own’s are (more gateway lead to higher available datarates for devices, reduce the probability that an area is only covered by rouge devices, increase resolution for multilateration, etc.)
• TTN is community driven. One wants to use the communities network so it’s nice to extend the communities network.

Whats required

Gateways could in theory be built with a single radio - but in practice thats not enough because LoRA allows operation on a multitude of subchannels and a normal radio is tuned to a single frequency band. One required a so called concentrator to listen for device messages. These concentrators are also capable of transmitting downlink messages as well as transmitting a periodic beacon. Note that not all of these modes are possible license free (beacon transmission requires a licensed gateway for example).

The concentrator board used in most home-built DIY gateways is the iMST ic880a. There exist two version - an USB and an SPI version. This article focuses on the SPI version. In Europe one would use the 868 MHz board which is readily available. One should also purchase a matching pigtail and antenna if one doesn’t have any special antennas that will be used (for example for outdoor gateways, sectional antennas, etc.).

Control of the gateway can be done with any small embedded computer - the Raspberry Pi (in this example the B+ model) is a perfect fit for that application. If possible one shouldn’t use wireless or bluetooth on these devices though to reduce radio interference. If it’s not possible the gateway should designed in a way to isolate the contentrator board as well as provide some shiedling between the LoRA antenna and for example 3G/LTE Antennas if possible.

Of course the gateway requies an power supply (normally for example a 230V to 5V PSU - if one doesn’t use 3G/LTE or WLAN/Bluetooth services and an RaspberryPi a typical 2.5 to 3A supply is more than sufficient).

Note that the gateway contains RF electronics so shiedling of the case is mandatory. In the best case use an aluminium or steel enclosure (also easy to get weatherproof) and ground the case. In case of outdoor usage follow typical rules for providing lightning protection. If you don’t know how to do that - please ask somebody who does (it won’t be covered here because it’s a little bit more complicated than connecting just a few wires). As long as your device stays inside the protection radius of other lightning protection infrastructure one can just operate the gateway.

Where to get the parts

Note: If you use the supplied Amazon links the author is profiting from qualified sales

• Concentrator board: This is available from IMST
• Raspberry Pi 3 B+: Can be purchased from Amazon
• 32 GB SD Card (smaller is also sufficient): Also available from Amazon. If you want an SD card large enough for all future experiments you can of course also take a cheap 64 GB or a cheap 128 GB one
• GPS module (any module with serial NMEA output and PPS pin is sufficient): Available via Amazon
• u.FL SMA pigtail: Available via Amazon
• 88 MHz antenna with SMA connector: Available via Amazon
• 5V power supply: Available via Amazon
• Plastic cable bend protection / feed through: Available via Amazon
• External GPS antenna with magnetic foot: Available via Amazon

Data usage?

Because the gateways connection to the backbone uses your internet connection one gets often ask how much bandwidth a gateway would cost. Even if the gateway receives a packet every 10 seconds one would only require about 5 MByte / day or approximately 100 MByte per month.

Building the gateway

Building the gateway is pretty easy. Just connect the gateways 5V and GND connection on pins 21 and 22 on the ic880a with raspberry pi pins 2 and 6 as well as the SPI pins and the reset pin according to the following table:

One can use jumper cables for that though a PCB is a better solution - they are available for some amount of money. Note that the UFL to SMA connector on the lower left in the photograph is used for the GPS antenna - it won’t be mentioned here. Also note that network and power are missing correct cable sleeves (they’ve just been attached for testing) and most important grounding. Grounding should always be attached to the case!

Put both boards in an enclosure, connect them to the 5V PSU. Never attach power when no antenna or dummy load is attached to the ic880a - that may damage your concentrator board!

Software

First - if you want to go the easy route - install raspbian stretch. Configure networking the way you like (for example enable ssh on the device by creating a “ssh” file on the boot partition of the sd card and assign a static IP adress via DHCP on your network). Perform some initial upgrading of the apt-get database and packages:

sudo apt-get update
sudo apt-get upgrade

Then configure ntp and ntpd:

sudo apt-get install ntpdate
sudo apt-get install ntp

Enable SPI support (one can use raspi-config for that or edit config.txt and load required overlays manually). Then add an ttn user and add this user to the sudoers group:

sudo adduser ttn
sudo adduser ttn sudo

Then change execution to ttn

sudo su ttn

As user ttn clone the github repository of the Zürich TTN community - they have written a set of shellscripts that does all the bootstrapping of the Semtech LoRA libraries and the TTNs packetforwarder for you:

git clone -b spi https://www.github.com/ttn-zh/ic880a-gateway.git ~/ic880a-gateway

They also provide a remote configuration mechanism that works by posting a pull request to your gateways configuration to their repository. One can also do manual configuration locally.

cd ~/ic880a-gateway
sudo ./install.sh spi

The installer shows the EUI (one needs that later on the TTNs webpage) and asks if it should use a remote config file. If it should not (you’d know in that case) it asks for some basic attributes:

• hostname of the device. The installer sets the hostname of your raspberry pi. If you use DNS in your network, assign this the same name as you’d assign the device in your DNS zone. If you use mDNS beware that the device will announce its presence as [hostname].local via mDNS.
• Descriptive name: Is a value that is shown to you and other members of the TTN.
• Contact mail: Required in case your gateway makes problems or whenever there are some legal questions to you.
• Latitude and longitude can be provided manual. This is especial interesting if you are not supporting GPS (or are only using GPS for time tagging). This should be as accurate as possible to help with multilateration. The same goes for height.

The system will reboot and the device will go online immediately. Remember to copy the gateway EUI (if not done earlier) and head over to https://console.thethingsnetwork.org and register your new gateway. It should appear as online immediately.

Troubleshooting

If the gateway doesn’t appear as online it’s most likely a network problem. Check if your gateway is reachable locally. If it is check if it’s capable of transmitting and receiving UDP packets with destination port 1700. This is the port used for communication with TTN. As long as you are using a stateful firewal or NAT that keeps track of the first contact downlink doesn’t require any special attention.

Running own backend and supplying messages to TTN simultaneously?

This is entirely possible. Just add a second server to your /opt/ttn-gateway/bin/local_conf.json servers list.

Adding GPS

One can add an GPS device as source for location information (latitude, longitude and height) but more important as a timing source to the gateway. This can be done with any GPS device that provides serial output (NMEA sentences as well as a PPS pin (should be 5V TTL logic).

One can simply connect the serial input to their RaspberryPi (if using the GPIO header beware that the RaspberryPi’s SoC is a 3.3V device so your UART should also deliver a 3.3V signal - if it doesn’t one can take the simple route and attach the GPS via a USB serial adapter). The PPS pin (5V TTL logic) should be attached to Pin 19 on the ic880a concentrator board.

Afterwards configuration in /opt/ttn-gateway/bin/local_conf.json can be adapted. If the device is attached to /dev/ttyUSB0 one simply sets:

		"gps" : true,
		"fake_gps" : false,
		"gps_tty_path" : "/dev/ttyUSB0"

These lines should be added to the "gateway_conf" section.

Note that enabling GPS also automatically (at least for current poly_pkt_forwarder) enables the gateways beacon feature that transmits a globally synchronized beacon pulse every 128 seconds. It uses the GPS PPS pulse to synchronize this beacon transmition with all other gateways on the network. This pulse is used by class B devices to allocate timeslots for downlink messages (see device classes above).

Some regulatory information (Austria)

The frequency bands used by the LoRA-WAN Gateway are:

• 868.1-868.8 MHz
• 867.1-867.9 MHz

They are covered by the following set of regulations:

Publication in accordance with Article 1(3) of Commission Decision 2000/299/EC (Version December 2014); (Ref. Ares(2014)4077502 - 05/12/2014):

• 868.000-868.600, 1%, 25 mW erp
• 868.700-869.200, 0.1%, 25 mW erp
• 869.400-869.650, 10%, 500 mW erp

CEPT Rec. 70-03:

• 868.000-870.000, 0.1%, < 25 mW erp
• 865.000-868.000, 1% Duty cycle, < 10 mW erp (for FHSS&DSSS, Bandwidth 200 kHz-3MHz)

Remote administration via TINC

Like every other system it may be desireable to join a VPN mesh with your LoRA gateway (it may be located anywhere via any untrusted network). First install tinc as usual:

apt-get update
apt-get install tinc

Configuration on linux is done in the /etc/tinc directory. First create one for your network (you can choose an arbitraty name, “netname” will be used here as a placeholder)

mkdir -p /etc/tinc/netname

First one should create a basic configuration file for the current host. This is located in /etc/tinc/netname/tinc.conf:

Name = loragw001
Mode = switch
DecrementTTL = no
Interface = tun0
Forwarding = internal
ConnectTo = host1
ConnectTo = host2
ConnectTo = host3

The ConnectTo statements should of course match other hosts on your VPN mesh network. It’s a good idea to generate tinc-up and tinc-down scripts in /etc/tinc/netname/tinc-up and /etc/tinc/netname/tinc-down:

#!/bin/sh
ifconfig $INTERFACE XXX.XXX.XXX.XXX netmask YYY.YYY.YYYY.YYY

#!/bin/sh
ifconfig $INTERFACE down

Do not forget to replace XXX.XXX.XXX.XXX and YYY.YYY.YYY.YYY with the IP address of your VPN endpoint and the associated netmask

Then tinc can generate (as usual) host keys and configuration:

tincd -n netname -K

Now you can finalize your host file. You can prepend some settings in front of the public key:

Compression = 9
Port = 656
Subnet = XXX.XXX.XXX.XXX/32

If your gateway is reachable via a public address you should add that too to allow other VPN mesh nodes to connect to the gateway

Address = ZZZ.ZZZ.ZZZ.ZZZ

Now you can deploy the other hostfiles and enable the service after adding the netname to /etc/tinc/nets.boot

systemctl enable tinc
systemctl enable tinc@netname

The service will now automatically startup on boot. Now one can manually start the service:

service tinc start

In case of errors one can debug the tinc client in foreground via

tincd -D -n netname -d3 --logfile=/dev/stdout

Management via TOR stealth hidden service

Of course TOR is not capable of providing any anonymization when used for a LoRA-WAN gateway (you have to disclose the location and one can estimate the location based on received signals) - but usage of TOR for remote access might be desireable to be capable to login into the gateway even when it’s only reachable via a NATed network, a VPN mesh is not suiteable and one wants to provide mutual authentication between the service and the user in both directions already on the network layer - that’s what stealth hidden services can be used for. Of course they also provide transport security and protection of metadatacollection of the administrating party itself. If one wants to do user authentication only the traditional way (via SSH) and doesn’t mind of his service to be discoverable one can of course also use a traditional hidden service.

First install TOR:

apt-get install tor

Then edit your /etc/tor/torrc to create your stealth hidden service:

HiddenServiceDir /var/lib/tor/loraremoteadmin/
HiddenServicePort 22 127.0.0.1:22

In case of a stealth hidden service add a list of authorized clients (the client names are arbitrary)

HiddenServiceAuthorizeClient stealth loraremoteadmin1,loraremoteadmin2

Then startup TOR:

service tor start

In case your installation script has already started TOR you should restart it after adding the hidden service lines

service tor restart

After the TOR client has successfully bootstrapped itself it has also initialized the HiddenService descriptor files at /var/lib/tor/loraremoteadmin/. You can monitor startup progress in /var/log/tor/log - this may take some time (and requires a synchronized clock - hopefully you have successfully setup NTP or added an RTC to your gateway). You could find a list of all client keys of authorized clients in /var/lib/tor/loraremoteadmin/client_keys - everything you need for remote administration is contained in /var/lib/tor/loraremoteadmin/hostname. Take the line corresponding to the client you want to setup and add the line (this is an onion URI and an authentication cookie key followed by the comment that identifies the client) to the client’s torrc as an HidServAuth line:

HidServAuth <onionurl> <cookiekey> # client: loraremoteadmin1

From now on the client can communicate with the stealth hidden service via the specified onion name. No client that doesn’t know the authentication cookie can use this onion URI (therefore they are called stealth hidden services).

This article is tagged:

• DIY
• LoRA
• RaspberryPi
• Electronics