Actility’s IoT geolocation helps to protect workers and assets

There’s excellent news coming from the LoRa Alliance: the core LoRaWAN specifications enabling passive roaming are coming out of the oven! As a co-chair of the LoRa Alliance Technical Committee, it’s my pleasure to present you our latest treats on roaming, security, Class B, and standalone Join Server.

The Technical Committee has been working on these specs for over a year now… We knew that they were highly anticipated by the whole LoRaWAN ecosystem. As a matter of fact, Actility customers have been able to preview the passive roaming feature since last summer.

Handover roaming

First delivery from the LoRa Alliance is a new version of the LoRaWAN spec LoRaWAN 1.1 offering:

• Support for handover roaming, which allows transferring control of the end-device from one LoRaWAN network to another. Earlier versions of this specification can already be used for passive roaming, which is transparent to the end-device.
• Enhancements on bidirectional end-devices with scheduled receive slots (so-called Class B, an enabler of energy-efficient actuators) which is now officially supported. Remember, in the earlier spec it was marked as “experimental.”
• Enhancements for additional security hardening.

In order to support heterogeneous deployments and not force a globally-coordinated upgrade, both LoRaWAN 1.1 end-devices and networks will support backward compatibility to interoperate with their LoRaWAN 1.0.x legacy peers.

Separation of backend servers

The second delivery is the brand new LoRaWAN Backend Interfaces 1.0 Specification allowing to:

• Split the core network into interoperable servers: Network Server (NS), Join Server (JS) and Application Server (AS)
• Roaming for both LoRaWAN 1.0.x (passive roaming only) and LoRaWAN 1.1 networks (both passive and handover roaming)
• A standalone server that stores end-device credentials (including root keys) as JS. It can be separated and administered by an entity independent from the networks that the end-device may be using. This allows networks to offload the authentication procedure to a dedicated system, which can also be operated by a third party. This third-party JS also enables an end-device to be manufactured without having to be personalized for the networks it may eventually be connecting to.

Regional Parameters

And final delivery in the package is the LoRaWAN 1.1 Regional Parameters rev. A, which describes a region-specific radio parameter for LoRaWAN 1.1 end-devices — a companion document for the LoRaWAN 1.1 spec.

In the spirit of fostering open standards, these spec delicacies are shared with you to build and deploy amazing products and services… Enjoy! Bon Appetit!