Skip to main content

A Closer Look at LoRaWAN and The Things Network

title

Going the distance, LoRaWAN network architecture and TTN support.

In this post we first take a look at just how it is that LoRaWAN is able to cover far greater distances than traditional wireless systems, before exploring the network architecture, looking at some of the hardware options and finally, support via the crowdsourced IoT data network, The Things Network.

Trading data rate for range

title

LoRa spectogram, © 2016 RevSpace CC BY-SA 3.0

The secret to LoRaWAN — the thing that allows it to achieve such incredible range with remarkably modest transmit power — is Semtech's LoRa modulation. A derivative of chirp spread spectrum (CSS), this takes advantage of the fact that by spreading a signal across a broader band of spectrum, a system can be made which will work with a far worse signal-to-noise ratio (SNR).

The spreading in spread spectrum systems is generally achieved by multiplying the original data signal with a spreading code or chip sequence, that is at a much faster rate than the data signal and therefore spreads the resulting signal bandwidth beyond that of the original.

With LoRa a chirp signal is generated that continuously varies in frequency and it is this onto which the spread/chipped data signal is then modulated. Given a fixed modulation bandwidth — amount of radio spectrum occupied by the transmitted signal — the amount of spreading can then be varied, in order to trade the available data throughput for greater range and resilience to interference.

The spreading factors (SF) used are from 7 to 12 and with each increase comes a link budget gain of an additional 2.5dB, with Semtech modem ICs being specified to have a sensitivity of an impressive -134dBm at a spreading factor of 12. Furthermore, since these are orthogonal and minimally interfere at the receiver, the total radio channel capacity is the sum of that for each spreading factor.

The modulation also includes provision for error correction. Beyond the noted low power and long range capabilities, other key properties include that it is relatively simple, multipath/fading and doppler shift resistant, and suited to use with low cost, high efficiency RF power amplifiers.

For a more detailed description see the excellent LoRa Modulation Basics Application Note.

Low Power Wide Area Networking

title

LoRaWAN Classes, © 2015 LoRa™ Alliance.

LoRaWAN builds on the LoRa modulation to enable the creation of Low Power Wide Area Networks (LPWANs) that, importantly, can be established through use of license-exempt spectrum. In other words, you don't need to wait for network operators to come to you and thanks to the outstanding performance of LoRa, a lot can be achieved with the low power levels that are typically associated with such spectrum — and also very much desirable with battery powered nodes!

Aloha, Beacon and Continuous

In LoRaWAN the equipment bridging the wired and wireless domains — which might otherwise be known as a base station or access point — is a gateway. There are three classes of end node device:

  • Class A. In this most basic mode uplink transmission is based on need and a random time basis (ALOHA-type protocol). Following uplink two short receive windows are opened.
  • Class B. Here the gateway provides a regular beacon signal that devices can synchronise to in order that they may accurately schedule more receive windows.
  • Class C. These devices receive continuously and only stop listening when transmitting.

At first the behaviour described above might sound a little odd, but it makes perfect sense when you consider that LoRaWAN is optimised for low power consumption, so the last thing you want is to have the receiver in a remote, battery powered sensor node powered up all the time. Furthermore, uplink will be a much more common requirement than downlink for most IoT applications.

So with Class A a node can send data more or less at will, but the network can only send data down to it following uplink. Should the two short receive windows not be sufficient, the network can set a “frame pending” bit, requesting that the node open another window by sending another uplink.

Should you require more or more predictable downlink capacity, Class B offers this. Finally, Class C is suited to downlink heavy applications where the node is likely on mains power.

Other noteworthy features include:

  • Optional confirmed data messages that are acknowledge by the receiver.
  • Adaptive Data Rate (ADR). Here the network may manipulate the spreading factor of a node, in order to optimise network use and achieve the fastest data rates possible.
  • Mobile operation via nodes performing periodic empty uplink, to update the downlink route.

Encryption, ABP and OTAA

Encryption is carried out at the network and application layers; in order to participate in a network a valid network session key is required, and the payload is decrypted with an application session key. AES-128 keys are employed for these and enable both privacy and verification of message integrity.

With Activation by Personalisation (ABP) a 32-bit device address (7-bit network identifier plus 25-bit network address), along with the network and application session keys, are manually configured.

Over-the-Activation (OTAA) is a little more complicated and here the node is configured with a device identifier, application identifier and application key (again, AES-128). With these it is then able to execute a join procedure, whereby it's subsequently allocated an address and session keys.

ABP is great for prototyping and suited to smaller networks. Whereas OTAA will allow for a greater degree of flexibility, e.g. in addressing, and should provide increased security and ability to scale.

Gateways

title

Detail of IMST ic880A SPI LoRaWAN concentrator board

There are various off-the-shelf LoRaWAN gateways available, with at least a number of these appearing to be based around the same core/reference design of two Semtech SX1257 transceivers plus an SX1301 baseband processor. A combination that is able to receive up to 8 packets simultaneously sent with different spreading factors on different channels.

Similarly, it would appear that the software/firmware for some of these is, perhaps unsurprisingly, based on the reference implementations from Semtech. Gateway vendors will of course differentiate their products by providing turnkey solutions, with varying overall hardware capabilities and that integrate other features which may be desirable in order to effectively scale and manage networks.

One key optional hardware feature is provision of GPS, which allows a gateway to more accurately report its position in the network and to provide high resolution timing to nodes. Furthermore, with such accurate positioning and timing available across multiple gateways, it then becomes possible to use a technique called time difference of arrival (TDOA), to determine the position of a node based on the time difference in an uplink message being received at multiple different gateways.

It should also be noted that, for those on a limited budget and/or interested in the internal workings of such things, it is fairly easy to build your own gateway using a trusty Raspberry Pi.

Node options

title

When it comes to radio solutions for nodes these fall into one of two categories:

  • Those which integrate a processor plus LoRaWAN stack and provide an interface to this.
  • Those which are a radio only and require a stack running on a connected processor.

The former tend to provide a much simpler solution and some modules now even boast LoRaWAN certification. Whereas the latter offers the possibility of running the networking stack and application on the same device, which may bring the cost down and offer certain benefits thanks to closer integration, such as enhanced power saving or smarter control of the MAC layer.

Popular turnkey modules include the LoRaWAN certified Microchip RN2483 (088-0682) . This is interfaced via a UART connection with 3V3 logic levels, and controlled via an easy to use ASCII command set.

For those going down the radio-only route, there is the reference LoRaWAN stack from Semtech, plus also the “LoRa WAN in C” stack from IBM, which has been ported to mbed, for example.

TTN support

title

At the time of writing The Things Network architecture is essentially considered to be a prototype and supports only Class A operation, with unconfirmed messages, no support for ADR — meaning fixed spreading factor/data rate use — and node configuration carried out via ABP. A channel plan has been drawn up for the 868MHz band, which includes a scheme for dual-SX1257 gateways.

Joining a gateway onto TTN is incredibly straightforward and once you have hardware, it's simply a matter of configuring a packet forwarder with a few simple parameters, such as the longitude and latitude if it doesn't have GPS, along with the networking details for the TTN server. Gateways do have a unique identifier, which may contain the hardware serial number, or in the case of a DIY Raspberry Pi-based solution, constructed from a prefix plus the Ethernet adapter MAC address.

In order for a gateway to be part of TTN it must use a common, known network session key. If the same AES-128 key is also used for the application session key, this means that the TTN server can also decode the payload and make this available in plaintext via a RESTful API or MQTT. However, a private application session key could equally be used for sensitive payload data.

In a previous post on setting up The Things Network Calderdale community, I covered in brief the current TTN architecture, which is pretty simple. In a tech update on 29th of February TTN gave an overview of the new architecture, introducing new network elements and with an aim to have this in production around the end of May, decommissioning the old platform by the end of August.

TTN is committed to open standards an open source, with full LoRaWAN v1.0 compatibility as a goal and all developed software being open sourced via GitHub. Furthermore, the aim is for this to be a fully distributed system, that is not dependant upon TTN hosting services.

Exciting times

LoRaWAN appears to provide an almost perfect combination of low cost, low power, range, resilience, simplicity and opportunity. Simple not only in the hardware required, but the fact that it achieves range with a basic star topology, completely avoiding the complexity and sometimes problematic nature of mesh networks. Providing countless opportunities in that anyone can get hands-on with LoRaWAN, building low power WANs without the need for an operator.

With the ability for battery powered wireless nodes to now cover a distance of up to 15km line of sight, LoRaWAN really does feel like a landmark technology and a key enabler for the IoT. It has clearly gathered a great deal of momentum over the last year or so and if the interest in The Things Network — just one initiative — is anything to go by, this is only set to continue to build.

Andrew Back

Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.