Helium network is a crowdsourced network using a blockchain. There are multiple transactions related to the Helium devices communication. Usually, we talk about the message transmission transaction corresponding to a flat cost of 1DC ($0,00001). That said there are some questions:

• what is a message definition ?
• what are the other blockchain transaction impacting the communication cost ?

In the post we are going to review the answer to these questions and I’ll propose a spreadsheet to modelize these cost with some example to see the different kind of real message cost you should take into account in your business model.

What is an Helium message transaction ?

A message is defined by a 24 bytes communication. It means you pay two messages for 25 bytes and also one for 1 bytes. This is the basic definition of message. But LoRaWAN is not as simple as this. There are different type of messages:

• Uplink
• Uplink repeat
• Downlink
• ACK
  

All these kind of messages are counting. So the number of messages your device will send depends on the settings in terms of repeat & ack mostly. Imagine a device sending a message on every 15 minutes (96 / day) with ack and retry equal to 2 (1 message + 2 possible retry). Unfortunately you have a lot of messages received by backend, acked but where the ack has not been received by the device. So this one is retrying if the uplink was received. Assuming we have about 25% loss on 1st frame, then 25% lost on 1st retry. Here are the math:

• Uplink messages : 96
• Ack messages : 96
• 1st retry : 24
• Ack retry : 24
• 2nd retry : 6
• Ack retry : 6

As a consequence, you device, even if transmitting 96 messages in a user point of view will consume per day a total of 252 messages
The Ack/Retry mechanism is really consuming, this makes sense as the downlink communication must have a larger cost in such network. So when designing or setup a device it is important to manage this.
As an exemple, tracking solutions, able to send a message on every 30 seconds in a condition when the ack ability is lower due to the movement could have a really high consumption. A fixed outdoor device will have a lower level of failed ack/retry ansd will be less consuming.

In any cases, the messages not received by the network are not billable, but in the retry mechanism, if you get the ack, you know you have been received but if you don’t receive it, you don’t know anything about the communication status.

There is also a question of duplicates. Duplicate messages are when multiple gateways receives a same message and propose it to the router (network server). The number of duplicates you accept to buy is configured in the Helium console as part of the label settings. The default is 1. If you accept more duplicates (as an example if you want to get a device location or a device coverage redundancy) you have to pay for each, 1DC per 24b as usual.

On the other hands, the downlink messages, as the ack response does not have a cost in DC. You only pay for the uplinks.

What are the other blockchain transaction ?

This is the most important point to understand to get the real cost of the Helium communications: the blockchain has different transaction involved in the communications. Basically all the transactions are not really device related (a device itself does not have DC and not burning DC). The transaction are Router related. We can name Router as Network Server with a more classical LPWAN name.

The routeur is the entity receiving the communications from the gateways, responding to the ack and downlink request. Managing the device life cycle and the network Join procedure. The router have its own transaction on the chain, related to run time and related to devices registration.

State channel

The router is using a special blockchain, with a short life duration, to track the communication transactions, the objective is to have a fast executing chain, tracking the source and destinations of messages to distribute the payments for communications. Two state channels are created in parallel to make sure always 1 is available during the renewal phase. At the end of the state_channel, the payment are distributed.

A state channel is also initialized with an amount of DC. This amount is blocked and basically, this is a waranty for the hotspot to be paied at end of the state channel for the communication they have relayed. The state channel stack this amount of DC for the life duration of the state channel. The state channel will also close when it run out of DC. Not consumed DC will be released at end of the state_channel.

The state channel creation have a fixed cost – 35000 DC and block at least the amount of DC needed to support the communication during this life time.

When using a short duration state_channel, you will quickly pay the hotspot for the communications and reduce the amount of DC stacked in it but the state channel creation rate will cost a lot. So basically lower is the number of device you support and larger must be the state channel duration.

This duration is in block, you can go up to 10.000 corresponding to a week. That said I currenlty have a doubt you can go over 5000.

As the idea is to have 2 state channel running in parallel, the best is to renew one of each on the middle life of the other. For this reason the first state channel have a duration twice the defined state channel duration. (ok … basically this only work on the first iteration and have for consequence to limit the max duration to 5000 block when using half of the duration would make this working correctly… I assume a bug, declared, wait & see).

The state channel will be dead if running out of DCs in it. In this case a new one will be created. It’s important to understand that the dead state channel will not be removed until the end of the block duration. As a consequence, if your state channel does not lock enough DCs at the creation and for the duration of it, you can have to open more state channel (so it costs more) and you can reach the maximum state channel number. In this case, the communications stops ! so make sure your state channel always lock much more DCs that you usually consumes (this can be an attack against a router).

Device registration

Every time you have a new device in the console, it needs to be declared on the chain with a transaction updating an XOR filter. This makes the hotspot able to route the device communication to the right router.

This transaction can be executed for one or multiple devices. It cost nothing when no new devices have been declared but it cost 40.000 DC each time you call it. This amount depends on the additional size in the XOR filter. If you insert many devices at a time, it can be 2x 3x … 40.000 DC. I currently don’t exactly understand the math to explain how many devices generated the cost extension.

If you call it on any new device registration, it will cost like 40.000 messages send per device, something like a year of communication. This is why, usually, this transaction is executed on regular basis. The routeur execute it on every 10 minutes by defaut. If you have many devices added in your console, it is about 140 transaction a day, $1500 / month, not something you should ignore in the businss model.

Using a longer period means asking the consumer to way for the given duration before getting the devices activated. All of this is not an issue or expensive problem but it means things to consider and organize. Decision and balanced choice to make, currently to manage this, you can disable the auto execution and run it manually with a cron.

OUI and DevAdr investment

As I’ve described in my previous post on Helium router deployment, the creation of a routeur (associated to an OUI) and the attribution of Device Adresses to support the fleet of devices has an initial cost. This cost also need to be considered in the overall message cost price.

Hosting cost

A router is running on a server, my router use a 300GB+ hard-drive with equivalent backup capability and 16GB of memory, there is no big IO or CPU constraints. This is a minimal configuration to be adjusted for scalability. This running cost will be a large part of the costs at the end of the year. You also need to consider your maintenance cost. Router configuration is about half a day work for experienced people and about half a day per month for normal maintenance.

Model

I’ve made a model to estimate the real cost of a message depending on these parameters, you can access it following this link.

You can change the cell in blue to put you own parameter and get the result on the red cells. Anyone can change the parameters so don’t take attention to the initial values you find. At the bottom the real number of DC consumed each time your device send a message and the yearly cost of the subscription.

This model is a simplification of the overall, it can be tuned and I do not recommend to fix a communication price directly based on the result of this spreadsheet, mainly if you do not master every details behind each cell. But it can help you to understand the impact of the different parameters, volume, reactivity you want, device setting on the final price.

This model, does not integrate growth and as a consequence gives an idea of the cost per DC or per device like if all the devices where enable on the first day and all communication going one. But in the reality, at the begining, the fixed cost are paid by a small number of devices. You need to be careful on this.

Application example

Assuming a large zone router targeting in the next 3 years up to 500.000 devices deployed with an average communication of 100 messages per devices, with 10% ack & retry and 1% downlink. Server & maintenance cost about $2000 / month

Monthly running cost - $5500
DC burn per messages - 1,5DC
1 year device average cost - $0,64

Assuming a medium router targeting in the next 3 years about 20.000 devices deployed with an average communication of 100 message per devices, with 10% ack & retry and 1% downlink. Server & maintenance cost about $1000 / month

Monthly running cost - $1589
DC burn per messages - 3,4DC
1 year device average cost - $1,50

Assuming a small private fleet of 1000 devices, 5 year amortization, having 24 messages per day, no retry, no downlink. Server & maintenance cost about $200 / month

Monthly running cost - $789
DC burn per messages - 95,4DC
1 year device average cost - $9,75