Is LoRaWAN suitable for your new product?

Increasingly many devices are now being deployed using LoRa technology. While there are many more authoritative sources explaining the physical layer in great technical detail and very good information on the standard MAC (media access control) protocol it uses, there is less detailed information regarding the whole ecosystem. By this I mean network architecture (as standardized by the LoRa Alliance) starting from the device up to the end user. Probably the main reason being that to the end user and device developers the transportation layer up to the application layer is transparent with all operators presenting some very standard endpoints to users.

The transportation layer is mainly the responsibility of network operators, and you can find many sources describing particular implementation (listed at the end of this article) and read the standard architecture documentation, but the question remains: what does it all mean for the device/application developers and users? In this article we try to answer some questions from developers, product owners and application designers so that they can decide if LoRaWAN is the correct technology for their products.

Terminology

OTAA: Stands for Over-the-Air Activation which is the process that the end device uses to register into the network.

ABP: Stands for Activation by Personalization which is an alternative way to register any device to the network. Unlike OTAA where the network information is agreed between the end device and the server automatically, here the network information must be entered manually into the device.

AppEUI (JoinEUI in newer specification): is a global ID in IEEE EUI64 address space that uniquely identifies the Join Server that is able to assist in the processing of the Join procedure and the session keys derivation.

DevEUI: is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device.

AppKey (NwkKey in newer specification): is a AES-128 root key specific to the end-device that is assigned to the end-device during fabrication.

DevAddr: consists of 32 bits and identifies the end-device within the current network. The DevAddr is allocated by the Network Server of the end-device

Derived keys: Keys generated during the node activation, there are six of them in the latest standard, but we will only concern ourselves with two of them NwkSKey, AppSKey.

NwkSKey: used to calculate and verify the MIC (message integrity code) and to encrypt and decrypt the payload field of a MAC-only data messages.

AppSKey: used to encrypt and decrypt the payload field

For sake of simplicity at all times we will assume that all parties are using the 1.0 LoraWAN standard. This is the version that is currently deployed and supported by all operators and the differences with the 1.1 that are of interest to us are few and will be discussed as they arise.

Common scenario

This is the main use case that is contemplated by the standard and which is implemented by the operators. This scenario makes some rules which are important to our discussion and will list below:

1. The device manufacturer is not expected nor it expects the end user to reconfigure the device before deployment. It should just work.
2. It is the device manufacturer/service provider responsibility to deploy the necessary backend servers (Application server) to deliver the data to the end users so that to the end user the LoRa Network is transparent.

In some cases a deviation from this scenario is needed and we will point to them and how can be implemented when it arises.

General Network Architecture

In the diagram above, the Network Operator usually owns both the gateways and the LoRaWAN network. The service provider integrates with the component labeled Application Server to recover the data from the devices, processes them and then delivers the processed information to the end user (not pictured in the diagram) usually via an API or a web portal displaying the data.

The Join procedure

This diagram illustrates the data exchanged by your device when it joins the network. The data can be divided in three groups, the data that the node must know in order to join the network, the data it receives from the Network and the data the network has to know in order to attend a join request:

End device data:

• DevEUI
• AppEUI
• AppKey
• Initial radio configuration: This includes frequencies, timings, etc which are different for each LoRa region due to regulations of the ISM band

End device inbound data:

• AppNonce: random number for key derivation
• DevAddr
• Network radio configuration: This includes frequencies, timings, etc which are different for each LoRa region due to regulations of the ISM band and might vary from operator to operator

Network data:

• DevEUI-AppEUI mapping: The operator must be able to verify that the device requesting the Join is actually registered to the Application backend identified by the provided AppEUI. This usually implies that each backed has to have an inventory of all devices (DevEUIs and encryption keys) it wishes to process.
• AppKey

From the above we can identify a few issues to take into account when designing and deploying LoRa devices and backend services.

Regional fragmentation

Due to rule 1 of the common scenario, the end devices shipped to the users must already be configured with the initial radio configuration lest we run afoul of local regulations. This means the manufacturer must control different versions for each region where it wishes to sell, with all the logistic complications it implies. In some cases this drawback is masked by the need to also make different hardware versions due to differences in band usage (923MHz, 868MHz, 433MHz) but not always.

A simple solution taken by many manufacturers is to relax the rule 1 allow the user to set the region where the device is being deployed. This of course means you run the risk of the user setting the wrong configuration, which leads to the device not working and the breach of local regulations. You should be aware where the responsibility lies in such cases by seeking legal advice.

Ownership is not transferable

Under the common scenario this is the result of rule 1 and 2 and also need a little explanation. Most LoRa devices are actually not owned by the end user in the sense that you actually cannot use it without a third party, most of the time you are buying a service (think LoRa GPS trackers).

This is because, as an end user, for your device to work you need a service provider, usually the manufacturer, that is running the Application server so that you can get your data. If your service provider disappears your device is paperweight. So if your service provider goes under or you just want to be serviced by other (not taking into account proprietary technology that might be used), you can’t. You would have to have the user change the device configuration manually (AppEUI and possibly the AppKey), contacting the previous provider to deregister that device from its Application server and finally registering it in the new.

So it can be done by basically bootstrapping the device again, but it is an use case not contemplated by the standard which cannot be done easily and remotely. This can be important in some use cases where the information is sensitive or very critical or the data has to be treated in specific ways due to regulations, the user might want to work with specific providers in specific locations or run it in-house.

Unsecured AppKey

Expanding the use case above, suppose a government agency that wants to monitor its fleet of official vehicles using a LoRa GPS tracker. Even if it manages to transfer the ownership of the devices to a trusted provider, it does not necessarily trust the provider with the information of the location of each of its vehicles even if the provider is another government department. And it will surely not trust the network operator with that information.

Nevertheless, under the current standard it has little other options. As you can see in the Join diagram, the network server (run by the Network Operator) must know the AppKey to be able to communicate with the node during the Join procedure. Obviously the service provider running the Application server must also know the key meaning that both the Network operator and the service provider can decipher the end user data at any point. For security sensitive applications this is a showstopper, since the LoRaWAN protocol does not guarantee confidentiality itself, if you want that you need to implement confidentiality on top.

However, in the new 1.1 LoRaWAN specification this is alleviated partially by separating the AppKey into two root keys. A key that is used for protocol related exchanges named NwkKey and another that is used only to encrypt user data named AppKey. The idea is that the operator only ever uses the NwkKey and thus cannot decipher the user data.

Roaming

The final issue and probably the most relevant to any product is the issue of roaming. With this I mean using the infrastructure of a 3rd party operator to communicate with your devices. This scenario is very common when you already have your backend service setup with operator A, but when expanding into a new country where operator A has no presence you are forced to use operator B, but you do not want to incur the development cost of integrating with a new operator.

Ideally when your node sends a join request to the operator B network, after failing to find the requested AppEUI it should contact other operators to reroute the requests to your application server, and from then it should all just work. In the real world, however, this requires the operators to integrate a common directory of application servers into their systems and work together to agree on it and how to distribute the costs. For now to my knowledge there is only a trial in this direction: https://www.orange-business.com/en/press/international-lorawan-roaming-trial-success

For LoRa to continue its expansion in the IoT sector, this is probably the biggest hurdle. And that’s why working with an experienced partner such as Worldsensing to understand all of the challenges and opportunities is so important.

If you found this post interesting, we are always hiring and interested in meeting all types of engineers, regardless of your skills or what tools you use day-to-day. Your intelligence, creativity, energy and enthusiasm are much more important to us than your experience with our stack.

Check out our careers page in here — https://worldsensing.wpengine.com/engineering/

Links

LoRaWAN implementation

https://www.thethingsnetwork.org/docs/network/architecture.html

https://www.loraserver.io/overview/architecture/

LoRa Alliance documentation:

https://lora-alliance.org/resource-hub/lorawantm-specification-v11

https://lora-alliance.org/resource-hub/lorawantm-back-end-interfaces-v10