The Things Network Comes of Age

The feature rich, secure and scalable crowdsourced data network for IoT

It’s hard to believe that less than a year has passed since I first took a closer look at LoRaWAN and The Things Network, writing about what at the time was considered very much a prototype network — albeit one that had already achieved incredible things, with LoRaWAN coverage deployed across the entire city of Amsterdam in a matter of weeks and this in turn igniting the imagination of an immensely enthusiastic, fast growing community, keen to replicate the effort across the globe.

Since then the network core or “backend” has gone through a number of iterations and what started out with fairly minimal functionality — but served to get the job done and prove its worth in an eminently pragmatic manner — has evolved into a feature rich platform that undoubtedly has proprietary solution vendors and network operators paying very close attention to it.

In this post we take a look at The Things Network production back-end and the features that this provides, while considering how they might prove useful in applications.

A rapid evolution

The v0 network architecture

The Production environment launched in December of last year and tagged v2, this replaces the v1 Staging environment. At the present time the two exist in parallel and pretty much in harmony, thanks to careful forward planning that has clearly paid off. However, it is recommended to switch applications across from the legacy v1 environment and migrating them is relatively painless.

Wait a minute, we’ve jumped forward a bit here! A year ago the network was powered by the Croft v0 architecture, which offered a very simple solution sans any real authentication, with a simple RESTful web API and public MQTT broker. However, rather than attempt to chart all the changes across these three revisions, we’ll focus mostly on what is now available in the latest and greatest.

Network capabilities

ADR Algorithm, source: thethingsnetwork.org

Before we get to configuration it’s worth noting that while the v0 network only supported simpler Activation by Personalisation (ABP), the much more scalable Over-The-Air-Activation (OTAA) has been supported for some time now. Similarly, while v0 supported uplink only, downlink is now supported and messages can be enqueued from the Console, in addition to via the API.

Confirmed uplink is now available for those applications where a device needs to be certain that the data it sent has been received. As is support for Adaptive Data Rate (ADR), whereby the network calculates how much margin there is to increase data rate or lower power — two things which both help to optimise use of airtime and overall network performance.

Also noteworthy is that the network implements frame counter checks to help prevent against replay attacks. Although not generally advisable, this feature can be disabled for testing and debugging etc.

Hello Console

The Console is where most — but not all and more on this later — configuration is carried out. Upon logging in to this you are presented with two options: Applications and Gateways. Let’s start by looking at the latter, as this is the first hop from the LoRaWAN device.

From this page you can select a gateway to manage or register a new one.

Whereas previously the only option was to use the packet forwarder protocol which is essentially a reference implementation from Semtech, you can now also select to use the gateway connector. The big difference here being that the latter adds authentication, which means that you don’t have to worry about a rogue or misconfigured gateway causing routing issues and possibly even denial-of-service. At the present time it appears that only the Things Gateway hardware supports this protocol, but it’s reasonable to assume that support will be added to other gateways in due course.

Other nice gateway management features include the ability to remotely configure the location of those without GPS, rather than doing this via text file configuration on the gateway itself. Along with the ability to delegate configuration access to collaborators.

Applications

The Applications part of the Console is where by far the most configuration is carried out. Here you can create and manage applications, before configuring devices ready for use with them.

You can also check device status and see how many uplink and downlink frames have been sent.

And get access to device payload data plus a wealth of incredibly useful metadata from gateways.

Once again, collaborators can be configured, thereby avoiding the need for sharing account access.

Payload Functions is a powerful new feature that allows you to embed just enough smarts in the network, to process device payloads and take care of:

• Decoding
• Conversion
• Validation
• Encoding

Making integration even easier, while allowing payloads to be validated before being sent on to applications and dropping them if they don’t make the mark. A rather neat feature that could quite easily remove the need for an intermediary application situated between The Things Network and an existing third party application with MQTT support.

Integrations

Integrations allow capabilities to be further extended via additional features that are hosted either with The Things Network or on third party infrastructure.

HTTP Integration allows you to send uplink data to an endpoint and receive downlink data over HTTP. So this might be an existing web API, for example, or perhaps a custom endpoint configured in a third party application that supports integration with HTTP, but not MQTT.

The Storage Integration provides seven days worth of historical data which can be accessed via a RESTful API. A feature that will no doubt prove popular with many front-end web developers and others with a need for data storage and straightforward retrieval.

There is also an integration for the popular IFTT service and, announced just this week at Mobile World Congress, Cayenne, a drag-and-drop IoT project builder.

Plarform integration, source: thethingsnetwork.org

Plenty of documentation is available for those interested in developing new integrations.

CLI

Command-line interface architecture, source: thethingsnetwork.org

As slick and intuitive as the web console is, many still feel more comfortable when presented by a flashing cursor and what could be more fitting for a free and open data network than to be able to drive it via the command-line! Perfect for dispatching with the utmost efficiency — and the aid of scripting languages... — all those jobs which might otherwise take an awful lot of clicking.

Summing up

What The Things Network managed to achieve in its earliest days was nothing short of remarkable and what it has since achieved over the course of the last year or so is even more impressive. It has grown from being a very compelling prototype, to a formidable and feature rich platform. Along the way having clearly captured the imagination of many and continuing to grow at a rapid pace.

Any early concerns around lack of authentication have been deftly addressed and while many other new features have been added, not one of them feels gratuitous and there simply for the sake of adding bells and whistles.

With collaboration woven throughout the platform, and plentiful opportunities for extension and integration, this really does feel like the foundations of a crowdsourced data network.

— Andrew Back