How do commercial LoRaWAN products handle device provisioning and access?

[artichoke]

Hi,
I’m developing a small-scale LoRaWAN/IoT system and i am trying to understand how device provisioning, ownership transfer, dashboard access, etc. is done in commercial products.

From what I see, a lot of vendors (Decentlab, Milesight, etc.) ship devices that “just work” once the customer scans a QR code or enters a serial number in a web portal.

So my questions are:

Do manufacturers usually pre-register all DevEUIs and AppKeys under their own LNS account (e.g. TTN, Actility, ChirpStack, etc.) before shipping?

When a customer “claims” a device, does that assign ownership in the vendor’s backend while the LNS remains under the vendor’s control? Or are the customers sometimes meant to register devices themselves (entering JoinEUI/AppKey into their own TTN application)?

If you want customers to use their own LoRaWAN network (private ChirpStack, The Things Stack instance, etc.) but still interact with your web app or cloud service, is that possible? Is there some system for transferring a node from one LNS to another?

In commercial deployments, do vendors usually operate a single centralised platform at all? (one LNS and/or web UI that’s multi-tenant for all customers)? Or do they deploy a separate stack for each customer (own database, dashboard, etc).

What about if you were using Grafana for visualization? Would you have one Grafana instance with multi-tenant capabilities or do they deploy a dedicated Grafana instance for each customer?

Nikolai

[descartes (Nick McCloud)]

Probably best if you buy one from the main stream vendors and use their onboarding process to see what definitely actually really happens.

If you thought the hardware & the firmware were hard and going to be the larger part of the overall product, you’ve only done about half - the other half is all the stuff you’ve described above, particularly the last two paragraphs.

[artichoke]

Yep, I realised how much of a huge undertaking something like this could be. But still, I am curious how other vendors do it. I might try a commercial sensor as you said, if i can find a cheap one.

For my project, the firmware for my devices is working quite well. And I have already built a very simple program that subscribes to the end devices via MQTT and ingests their data into a time-series database, but maybe this is enough. Instead of multi-tenancy, the user just deploys the whole stack on their own infrastructure.

[Harald_Naumann]

The onboarding of LoRaWAN devices, unlike that of NB-IoT devices with SIM cards provided by network operators, is not standardised. It can be defined individually depending on the organisation’s network infrastructure. Operators of private LoRaWAN servers can choose between several onboarding methods according to their security and management requirements.

The following methods are available for onboarding devices in a private LoRaWAN network:

• OTAA (Over-The-Air Activation): The device sends a join request to the network server and receives session keys in response. This method generates new session keys for each activation, which increases security.

• ABP (Activation by Personalisation): The activation uses pre-programmed, static keys without a join procedure. It is less flexible and secure than OTAA but easier to implement.

• Manual registration: Devices are manually registered in the network server by entering keys, DeviceEUI, JoinEUI, and other parameters. This method is required when no standardised QR codes for automatic detection are available.

• QR-code-based provisioning: Some vendors facilitate onboarding by providing QR codes containing all necessary device data, which can be scanned to register the device.

• Use of device repositories: Network servers such as The Things Stack offer databases of device types and profiles that can be selected and adapted when adding a device.

• Generation of custom keys: In private networks, AppKeys and NwkKeys can be generated independently and programmed into both the device and the network server, allowing maximum flexibility.

• Integration via APIs and automated tools: For large-scale networks, automated onboarding tools or APIs can be used to add and manage devices efficiently.

These methods can be combined depending on the specific use case. The choice of onboarding method should be based on security requirements, user-friendliness, and the existing infrastructure.

In addition, when setting up a private LoRaWAN network, gateway onboarding is equally important to ensure that gateways are correctly integrated into the network server and reliably receive and forward data.

This flexible and customisable onboarding process sets LoRaWAN apart from the uniform, SIM-card-based NB-IoT solution. It provides greater autonomy, flexibility, and individuality in device management.

I hope it helps to make a decision.

Harald, author of the LPWAN Cookbook. Table of contexts:

LPWAN Cookbook - Antennity - Integrated IoT antennas

[descartes (Nick McCloud)]

@Harald_Naumann

The following methods are available for onboarding devices in a private LoRaWAN network:

• OTAA (Over-The-Air Activation): The device sends a join request to the network server and receives session keys in response. This method generates new session keys for each activation, which increases security.
• ABP (Activation by Personalisation): The activation uses pre-programmed, static keys without a join procedure. It is less flexible and secure than OTAA but easier to implement.

Harald, as discussed previously, however impressive your AI ‘make it more human’ system is, AI generated content isn’t acceptable here because of the exact example above.

You can’t on-board a device via OTAA or ABP - those are joining/connection methods that require the device to be on-boarded BEFORE either can happen.

A device repository is a useful element but can only provide generic settings. It can not on-board a specific device.

Generation of custom keys can be part of the on-boarding process, but again, it is no on-boarding - it is an extra to the process.

For TTN deployment, you missed an obvious one - import from a CSV file.

@Harald_Naumann

This flexible and customisable onboarding process sets LoRaWAN apart from the uniform, SIM-card-based NB-IoT solution. It provides greater autonomy, flexibility, and individuality in device management.

This is just AI added filler.

@Harald_Naumann

I hope it helps to make a decision.

How can it, there are no pros or cons, just a list of potential solutions, some of which aren’t solutions.

And what seems to be a blatant attempt to promote your book which appears to be a collection of case studies and the technical background to the various LPWAN systems. Nothing in the table of contents explains how to develop products & networks.

[descartes (Nick McCloud)]

@artichoke

But still, I am curious how other vendors do it. I might try a commercial sensor as you said, if i can find a cheap one.

If you can only afford one cheap one, you’re business model may need some investment. Once you go public and start to sell something, you’ll need answers & resources.

At a minimum, you could just look at the vendor docs.

And you can look at the data / dashboard providers docs or even do a free trial to figure out what’s available there and how it might be working in the background.

You should ask your potential customers what they would want.

You should learn LW more so you can figure out the answer to “Is there some system for transferring a node from one LNS to another?” yourself, given that it addresses plenty of fundamentals.

@artichoke

And I have already built a very simple program that subscribes to the end devices via MQTT and ingests their data into a time-series database, but maybe this is enough.

Ouch! Can you make it a web hook, much less load on the LNS

@artichoke

Instead of multi-tenancy, the user just deploys the whole stack on their own infrastructure.

Will your target user base be able to do this. How will you support them if they are vaguely able to but missing some technical skills. What if their infrastructure has an issue and they reach out to you for help.

If you look around, you’ll see those that are shifting small sensor boxes and those that are running big servers to do things with the data from the small sensor boxes. These are quite different activities which is why there tends to be a split.

[artichoke]

@descartes

If you can only afford one cheap one, you’re business model may need some investment. Once you go public and start to sell something, you’ll need answers & resources.

I guess my initial post implied I was planning on going ahead and making a full-scale commercial solution. Indeed I definitely do not have the money or resources to do that yet. I was more just interested in how it is done at such a scale.

@descartes

Ouch! Can you make it a web hook, much less load on the LNS

Yes, I now realise that webhooks make more sense. However, surely one open TCP connection which can handle multiple nodes isn’t that much load on the LNS? I guess if every user had an ingestor deployed, it could add up, but you would have to be in the tens of thousands of users, no?

@descartes

Will your target user base be able to do this. How will you support them if they are vaguely able to but missing some technical skills. What if their infrastructure has an issue and they reach out to you for help.

If you look around, you’ll see those that are shifting small sensor boxes and those that are running big servers to do things with the data from the small sensor boxes. These are quite different activities which is why there tends to be a split.

These are good points, I think I get what you mean. I guess I am realising there is a big difference between “I just want some sensor readings to show up in Grafana” and “I host a platform that ingests thousands of sensor readings per minute from customers around the world”.

In this case, my audience at this point in time is merely myself, and maybe a handful of other people I know personally who I would be willing to handle infrastructure for.

In the future I was thinking of maybe making this into GitHub project rather than something commercial. Something documented enough that others could pinch ideas or bits of code, or replicate parts of the system (mainly the hardware and node firmware, which is the bigger part of my project). And that sort of crowd would either have a field day setting up the intended stack, or just wire it straight into their own application like node-red.

Whats interesting is that I came across a similar project at run by a local university group that has the exact opposite problem. They have a fully fledged dashboard and software suite, but their lorawan nodes are taped together in sistema boxes!

[Harald_Naumann]

The question above covers TTN, Actility, ChirpStack, etc. The counter-question is whether the TNN Forum is willing to answer the question. My LPWAN Cookbook includes a separate chapter on this: ‘6. Comparison of Technical Parameters in LPWAN: Facts Instead of Marketing’. My list above shows the possible join procedures. Some of them are not permitted in commercial products because they do not comply with the new European security regulations.

> This is just AI added filler.

I’m afraid I have to disappoint you. This is taken indirectly from the introduction to chapter ‘6. Comparison of Technical Parameters in LPWAN: Facts Instead of Marketing’ of my LPWAN Cookbook. See https://antennity.com/lpwan-cookbook/

>You cannot on-board a device via OTAA or ABP – these are joining/connection methods that require the device to be on-boarded BEFORE either can happen.

I do not distinguish between ‘on-boarded BEFORE’ and other procedures, but rather list the options. TS-UNB (Mioty) Z-Mode can only upload, and the device must be registered manually. With modes A, B and C, joining is possible without on-boarded BEFORE. It is similar with LoRaWAN.

>How can it be, there are no pros or cons, just a list of potential solutions, some of which aren’t solutions.

Because the questioner now has to ask himself which procedures are used by his customers and which are permitted. He has to weigh up the pros and cons himself. Without further details, I cannot give a more detailed answer as an IoT consultant.

If you want to sell a LoRaWAN product for CRIRTIS in Germany, the requirements are much higher than for TTN. If he uses ChirpStack, he has complete freedom but is limited to the functionality of ChirpStack and must compare this with the requirements of his customers.

My requirement was LoRaWAN and Mioty with the same server. TTN, Actility and ChirpStack do not support Mioty. That’s why I decided on Loriot. https://loriot.io/

[descartes (Nick McCloud)]

@artichoke

I guess my initial post implied I was planning on going ahead and making a full-scale commercial solution

Indeed!

@artichoke

I guess if every user had an ingestor deployed, it could add up, but you would have to be in the tens of thousands of users, no?

The Things Network Status

How many users do you think are on TTN? And we get this all for free. So yeah, MQTT if you really can’t get your own external server, other wise Webhooks for the win.