Helium Network Comparative Discussion

TTN Network and Services
109

So, without reading or attempting to understand the details, if I understand the gist of this in oder to solve a problem of their own making they are now attempting to develop and push a change to the LoRaWAN spec to be adopted by the L-A that will then potentially impact all LoRaWAN networks further complicating what was a relatively simple and straight forward system :man_shrugging: I fully understand there may be a need to change/update system/software for my Helium kit as part of that specific network and its ‘fork’ but to force further change on my/my clients TTN, Chirpstack, Loriot, TTI, Digimodo, Actility, Senet, Orange, KPN, Fastnet, Bouygue T, Orbi……private networks, etc etc or whatever systems is a bit rich and feels selfish/self serving…… just saying! Part of me almost hopes they see some push back….I know standards and specifications evolve through need and through developing solutions to identified problems or security issues, but….

111

"

Upcoming

The team’s focus in the coming weeks (usual disclaimers apply):
…

Taken from Console Updates- v2.2.10 | Helium Engineering Blog

So, the L-A doesn’t seem to agree with their idea :slight_smile:

112

Sorry, I may be stupid but what is the relevance of your message after this statement? If I would chose not to read anything on a topic, the consequence would be that I would be silent.

113

They do. I build one myself and after a year of data transfer, I still cannot purchase a pizza out of my earnings. :rofl:

2 Likes
114

I think @Jeff-UK was trying to say - “Here’s my summary of a complex topic without me going right down the rabbit hole” - both of us have recently acquired a “money from thin air” box and are wading through the reality of it all - which is very much an alternative universe skewed away from actually using LoRaWAN for real with many inexplicable communiques that appear to be fire fighting their way towards some actual utility.

At present I don’t even know how to shut down my gateway so I can move it in the office to a more appropriate location. The “rules” prohibit us being able to SSH in to it, which transpires that you can’t then setup any form of management of the gateway of your own. And as the console has recently been restricted to a maximum of 10 devices because they don’t want volume users (who pay to transfer data) to place a burden on their central servers.

It is very surreal and sadly at present they seem to be winning the marketing war.

2 Likes
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
116

Sort of, I wasn’t expecting some miraculous alternative to TTS but it’s very hard to look from the outside and see the reality.

Absolutely, the thinking behind the economics run thus:

  • When purchased (a RAK GoldSpot) about two months ago the ROI just leaving it turned on was ~24 months, which was a bonus. ROI has sagged a lot of late, maybe if I move it to the dining room where it will then be in a different hex which will get more bonus points (I think) and if I run around with a device doing some mapping (I think). Or put it on a decent antenna to get some range for proof of coverage (I think) - bearing in mind that the roof already looks like GCHQ so I’d rather not.
  • Once I got one, it turns out I can register a new user account and get some credits for creating my new device and then transfer them across the office from a random device to the gateway. But I’ve actually got better things to do at present.
  • The real value to me is in the authoritative knowledge and being able to clearly demonstrate use of the network - it will take just one enquiry where the prospect is interested in the Helium network to pay for itself - either (sadly) by running with it with a view to moving to TTI or just getting them on to TTI/TTN from the start.

Use of LoRaWAN is my niche, I do LoRa P2P, WiFi & 2.4GHz as well plus a bit of GSM, BLE & Iridium - so from my perspective, knowing the reality of the different offerings is rather important.

117

I believe we’ll see some 100K used Helium miners (and a lot of accessories), competitively priced (way less than $100), on eBay relatively soon. It may be a time to prepare something like reflashing guidelines :slight_smile:

8 Likes
118

To be honest, I also used to have one. One of my customers asked me to do some research on Helium and its LoRaWAN server capabilities.

119

Their gateways don’t have GPS, and that’s “by design”. So, sorry, no chances for Class B. Interesting that one of the largest water meters manufacturers in the US seems to be pretty interested in this feature (so it seems Helium didn’t put enough effort into market research).

120

Some of Helium’s early adopters made comparable figures. But this couldn’t last long enough, obviously.

1 Like
121

I believe you meant MHDR + MAC payload, not PHY payload.

122

A pyrrhic victory in a single (though long enough) battle isn’t the same as a won war.

123

Yes indeed

124

Do you think TTN could implement a truly decentralized network focused on Proof-of-Work and uninflated TDOA based Proof-of-Coverage without becoming a shitcoin the way Helium seems to be?

125

We did explore this idea and had a working POC. Please see this post for reasons why this doesn’t work; Helium Network Comparative Discussion - #115 by johan

1 Like
126

However having an economic model where you may get a share of the value people attribute and willing to pay for a service does not go against having no expectation to make any money from it, or does it?

Shouldn’t a free economy mechanism help grow the network where people pay if they want to and pay as much as they are willing to?

I would think the strength of TTN is the culture of delivering value first and solving the technical problems leading to it. And a distributed network may well be just another technical problem without any necessary compromises.

Would the solution proposed then allow for having another attempt?

127

There doesn’t seem to be an effectual demand for The Network. If one really needs to connect 10-1000 nodes at his site, it costs almost nothing to buy a couple of gateways, rent a couple of VPSes, and set up your own private network. Chirpstack is that what really prevents TTN and others growth, not Helium.

128

I don’t think Chirpstack prevents TTN & others growth - whilst Chirpstack is a pretty solid offering, you have to manage the infrastructure yourself, which for high reliability configurations is a non-trivial task. Which means you either have a contractor on call or staff member to pay to look after it all - which then needs someone to step in when they are on holiday or ill or leave.

Whereas with the commercial offerings you delegate all of that to specialists who can offer a much more robust configuration with their expertise and you only have to pay for a share of the hardware & staffing.

I’m not aware of a lack of growth in the LoRaWAN market place, just the huge red-herring distraction that Helium brings to the party which does make some commercial discussions more complicated than they need to be.

2 Likes
129

I think I see the point you are making but shouldn’t there be a middle ground between people setting up a private network vs having to buy into a shitcoin ecosystem to be able to access greater return on investment?

For example, I would like to extend the network on several islands across South East Asia to start an IoT based service. How could I make the gateways available to other use cases and have the ability to be compensated as demand grows?