Helium documentation seems to state that it costs $100 per Device/Device Address ?

[pdvaneijk]

See here: https://docs.helium.com/use-the-network/run-a-network-server/buy-an-oui/#oui-cost

"The OUI is purchased with data credits (DC). Costs are subject to change, but currently the OUI itself costs $100 worth of DCs and each DevAddr cost an additional $100 in DC.

DevAddr are sold in sequential blocks between 8 and 65,536 and any power of two. You must purchase a slab when purchasing an OUI, therefore, the minimum cost for an OUI is $800 for eight DevAddr's and $100 for the OUI itself."

NO ONE is going to be using the Helium network if you charge $100 per Device Address. Each Device has a DevEUI, and the LNS assigns a unique DevAdr to each device. So I am hoping the above $800 allows you to purchase a block of up to 65,536 device addresses and not for 8 devices ?

[lthiery]

@pdvaneijk

Thanks for raising the question. It needs a bit more explanation in the docs, but the key point is that it is possible to load lots of devices per DevAddr.

Helium's LNS (ie: Router) has special logic where it uses the Message Integrity Check (MIC) to determine which of the N devices with the same DevAddr a packet came from. That is to say, if 100 devices have DevAddr 0x500 (owned by the OUI), then the Router will check it against all of these sessions. When the MIC passes, then we can determine which device it came from.

I'm not precisely sure how many devices can share the same DevAddr, but I believe it is "very many". The MIC calculation is relatively cheap for a modern server. On top of that, if you lengthen RX_DELAY, you can buy yourself many seconds to do this search for a MIC match. We also use geo-location for a "short list" of device sessions to the MIC against first.

[Oliv4945]

Hi @lthiery, while DevAddr is not mandatory to be unique and collisions can happen, relying on this is uncommon. Do you have any tough numbers to know how many devices can be managed by the recommended configuration from this page with an acceptable RX Delay (let's says 1 or 2 sec max allowed for MIC computations)? Also, can we buy non continuous devAddr stab? ie we see the need for more in the future and buy another one in X months?

Also in your video you recommend a 160 GB disk while it is written 120 GB in the doc, do you have any trend so we can appropriately size our servers?

Lastly I believe that this command from the docs is not accurate anymore and nonce can now be omitted, right?

 helium-wallet oui update routers --oui 4 --nonce 1 --address 11xHXS5AgLyjYRCJ4ctcWcsMRULS8jro9Pb1GPaTG1neGk1dNcf --commit

thanks

[oosui]

If we migrate 1 million devices from another Network to the Helium Network, how many consoles / routers should we have? Is the console horizentally scalable? Should we add 1 million devices in the same console database or should we seperate to several console+router sets? For 1 million devices, totally how many OUIs and DevAddrs do we have to buy? What will be the initial cost and monthly cost? Any plan to support class C && FUOTA? Thanks!

@pdvaneijk

Thanks for raising the question. It needs a bit more explanation in the docs, but the key point is that it is possible to load lots of devices per DevAddr.

Helium's LNS (ie: Router) has special logic where it uses the Message Integrity Check (MIC) to determine which of the N devices with the same DevAddr a packet came from. That is to say, if 100 devices have DevAddr 0x500 (owned by the OUI), then the Router will check it against all of these sessions. When the MIC passes, then we can determine which device it came from.

I'm not precisely sure how many devices can share the same DevAddr, but I believe it is "very many". The MIC calculation is relatively cheap for a modern server. On top of that, if you lengthen RX_DELAY, you can buy yourself many seconds to do this search for a MIC match. We also use geo-location for a "short list" of device sessions to the MIC against first.

[lthiery]

@Oliv4945

Do you have any tough numbers to know how many devices can be managed by the recommended configuration from this page with an acceptable RX Delay (let's says 1 or 2 sec max allowed for MIC computations)?

In response to this conversation, we're working on some more comprehensive benchmarks.

Also, can we buy non continuous devAddr stab? ie we see the need for more in the future and buy another one in X months?

Yes, you can just buy extra slabs as you need them down the line. The fact that they are non-contiguous is not a problem.

Also in your video you recommend a 160 GB disk while it is written 120 GB in the doc, do you have any trend so we can appropriately size our servers?

It's a hard thing to rigorously quantify as the block sizes tend to increase. The objective here, in my opinion, is to size is large enough to so you only have to worry about free'ing disk space once every month or two. On the other hand, you're paying for unused disk space if you go too big. Eventually, I believe we will have built-in features for freeing up disk space as I know it's being investigated in the Miner code-base (which shares a lot of pieces with this codebase for block syncing & ledger management).

Lastly I believe that this command from the docs is not accurate anymore and nonce can now be omitted, right?

Is that command missing from the video? I recorded in a few different cuts and I wonder if I lost that segment :-S

[lthiery]

@oosui

If we migrate 1 million devices from another Network to the Helium Network, how many consoles / routers should we have? Is the console horizentally scalable? Should we add 1 million devices in the same console database or should we seperate to several console+router sets? For 1 million devices, totally how many OUIs and DevAddrs do we have to buy? What will be the initial cost and monthly cost? Any plan to support class C && FUOTA? Thanks!

In theory, many "addresses" can be allocated to the same OUI which would help with scalability. In practice, the current Router implementation does not support this so if horizontal scalability is immediately required, I would agree with your suggestion of purchasing multiple OUIs.

However, if you are managing millions of devices and are interested in class C support and FUOTA, I would consider leveraging the roaming features that are being rolled out with HIP46.

The requirement for roaming is that you have a registered NetID with the LoRaWAN Alliance. The major benefit though is, once you do that, you get to have your own DevAddr space instead of worrying about slabs within the Helium NetID. This also makes it much easier to "bring your own LNS" where FUOTA and Class C may already be implemented.

The roaming product is actively evolving though so it's probably worth connecting with us so you understand "what it does today" vs "where we want it by June". Are you in touch with anyone from Nova or the Helium Foundation about this yet?