Helium Network Comparative Discussion

TTN Network and Services
115

A bit off-topic…

Yep, this is known as the “lying Serving Network Server (sNS)”. Today, the Serving Network Server (sNS) cannot prove that a frame forwarded by a Forwarding Network Server (fNS) has been successfully accepted or not. It could be randomly generated, it could be an actual device whose session is gone, it could be a retransmission, it could be received by other forwarding networks so sNS may not pay out to all fNS, etc etc.

To address this, there’s a solution that is currently being discussed in the LoRa Alliance Technical Committee. It has been proposed by other members and is now back on the table. The idea is twofold:

  1. Forwarding in two steps: an offer and the actual data transfer. The offer will contain public metadata: DevAddr, FCnt, a new hash and the MIC, but not the actual FRMPayload. This allows sNS to do device matching (with MIC check) and other decisions to buy the frame, and then go back to fNS to get the actual payload. This requires that the MIC is no longer based on the FRMPayload, so there’s a second change needed:
  2. The MIC should be calculated as cmac(k, hash(phy_payload))[0:3] instead of cmac(k, phy_payload)[0:3]. This means that if sNS only knows the hash, it can do the MIC check for device matching. This is a change in LoRaWAN that is only going to be possible with LoRaWAN 1.2.0. I can’t comment more on this publicly at the moment.

Back on-topic. Now with the expected collapse of the economic model of running Helium hotspots and the lack of actual use of Helium as a network server, it may be time to evaluate what we can learn from this and what we can apply to The Things Network.

Background story:

As some of you know, in 2017 we prototyped a value exchange with our own coin (Wavelet) on top of Ethereum with builtin support in our V2 stack. We showed it to some key community members and decided to kill it because people indicated that they didn’t put up gateways to make money, and that value contribution in TTN is not only putting up gateways but also answering forum posts, organizing meetups, writing articles, etc. So what we did was limited to gateway owners getting paid in Wavelets directly but anonymously by application owners who made use of their gateways. The V2 stack was the authority by submitting to/from transactions to a blockchain.

What can we learn? A few or my hypothesis:

  1. There’s no sustainable economic model behind setting up individual gateways for someone else. It may work for some nationwide operators (Orange, Swisscom) and it may not work for others (Proximus, Bouygues Telecom, Sigfox). Even for those operators for whom it does seem to work, it’s probably not standalone LoRaWAN that makes it worth it, but rather being a one stop shop for connectivity and packaged deals.
  2. Implementing LoRaWAN the way it is meant to be and making sure your LNS is feature complete, is still key to success. Like we struggled from 2015 to 2019 with our V1 and V2 stacks, Helium is now struggling with limited LoRaWAN support, prioritizing precious developer resources on blockchain mining rather than supporting LoRaWAN completely (1.0.4, class B and C, multicast) and in a stable way
  3. Making shiny marketing material and using random blockchain terms that nobody really understands works works really well. In any case, the coverage map is pretty nice, as well as the realtime stats
  4. Proof of coverage can be pretty useful for knowing where gateways are and whether they are online, even if there’s no or very little LoRaWAN traffic around. We can pretty easily implement this by transmitting uplink frames from gateways that are received by other gateways. We don’t need cryptograhpic challenges and verifications.

What else can we learn? What can we apply?

But I guess you did expect this before buying the money from thin air box, right? I’m honestly curious here. You knew enough about economics and LoRaWAN that you can’t buy a box for 500 and make 500 profit per month, right?

9 Likes