HIP37: Omni-Protocol PoC

[jamiew]

Info

• Authors: @zer0tweets (FreedomFi), @jmfayal, @hashc0de
• Start Date: August 28th, 2021
• Category: Technical
• Status: In Discussion
• Original HIP PR: HIP draft: omni-protocol PoC on Helium Network #269
• Tracking Issue: HIP37: Omni-Protocol PoC #271 (this)
• Discord channel: #hip-37-omniprotocol-poc on https://discord.gg/helium

Rendered view

https://github.com/helium/HIP/blob/master/0037-omni-protocol-poc.md

Summary

This document is an follow-up to HIP 27, tackling economic incentives to implement proof-of-coverage (PoC) for cellular and Wi-Fi data and recommending a technical implementation that includes adding a new device type to the Helium network.

[PaulVMo]

Nice work team. I am in favor of this idea to incentivize new wireless networks. There are a few clarifications / additions needed in my perspective.

1. The reliance on the LongFi process for attesting location needs additional details. The way the LongFi location attestation works is on a per beacon basis. The witnesses are determined as valid or invalid based on expected RSSI/SNR values given the supposed distance between hotspots. There is nothing like a status that indicates whether the location is accurate or not. For LongFi witeness data to be used for verifying the location of the hotspot for 5G PoC rewards, more definition is needed on how the witness data will be converted into an indication of whether the location is accurate or not before providing 5G PoC rewards.
2. In the time between now and the second halving, there should be a ramp up to the non-Lorawan reward pool in line with the 5G hotspot ramp up. As written, the entire unused DC pool is given to non-Lorawan POC. Presently, this is a higher amount than the Lorawan PoC pool. If not ramped up, the initial few batches of only a few hundred 5G gateways will receive a larger pool of rewards than all 150,000 LoraWAN gateways. The ramp will be constrained by supply not This will be very poorly received by the community and a detriment to the growth of the network.
3. The non-POC traffic filter scenario could also be done on the radio side. At least with WiFi (I'm not versed in 5G), it is trivial to put a MAC address filter on the access point. One could filter all MAC addresses other than their own witness phones devices.

[anthonyra]

2. In the time between now and the second halving, there should be a ramp up to the non-Lorawan reward pool in line with the 5G hotspot ramp up. As written, the entire unused DC pool is given to non-Lorawan POC. Presently, this is a higher amount than the Lorawan PoC pool. If not ramped up, the initial few batches of only a few hundred 5G gateways will receive a larger pool of rewards than all 150,000 LoraWAN gateways. The ramp will be constrained by supply not This will be very poorly received by the community and a detriment to the growth of the network.

I am also fearful of this aspect. That's why when 5G was first proposed I opposed the use of PoC with the protocol. The PoC is a mechanism used to incentivize the growth of a network before there's an actual use of it. For 5G especially in regards to FreedomFi (FFi) they continue to discuss the contracts in the works for a customer. I'd imagine for good contracts specific locations will need coverage well before others. They probably won't have a blanket approval to just put these systems anywhere. Meaning for FFi case they will have a use before the network is built out. I don't think the same need is required.

[anthonyra]

Another important thing to note, If you take a look at the Biacells being circulated as potential micro cells it wouldn't be impossible for it to provide 1 GBps... which the current proposal for HIP27 is saying 333 LTE packets per DC which is roughly 45,500 DC per GB (~$0.50/GB) so if we simply use the $0.50 = 50,000 DC per second

50,000 DC/sec * 60 sec/min * 30 min/epoch = 90,000,000 DC per epoch for one miner if it's able to push 1 GBps
That's more DC moved in one epoch than currently being moved daily from LoRa for comparison
https://api.helium.io/v1/dc_burns/stats (take a look at state channels)

The DC at current price to hit BME is 1,519,097,212.5 per epoch based on $25/HNT (conservative estimate)
Which means 16 miners/cells could reach BME pushing 1 GBps 24/7... Just some numbers to think about

[Vagabond]

I'd really like to see this as 2 separate HIPs, the first one covering the economic proposals (combining reward buckets, dividing rewards based on usage) and a second HIP that covers a proposal for the eSIM/WiFi stuff.

The eSIM/WiFi stuff is very interesting but I'm not up to speed on how all that stuff works so I feel like we need to increase understanding of the technologies at play there before making a decision.

[kidreveloution]

I am also fearful of this aspect. That's why when 5G was first proposed I opposed the use of PoC with the protocol. The PoC is a mechanism used to incentivize the growth of a network before there's an actual use of it. For 5G especially in regards to FreedomFi (FFi) they continue to discuss the contracts in the works for a customer. I'd imagine for good contracts specific locations will need coverage well before others. They probably won't have a blanket approval to just put these systems anywhere. Meaning for FFi case they will have a use before the network is built out. I don't think the same need is required.

Still new at this so help me out as you can, hehe.

So how is that fair tho? God knows when Lora will actually prove its worth when burning DC's. Or, if we even have enough LoRa coverage to be useful at the moment (I still think we are very far from that)

On the other hand, we have 5G which does have a customer, and does burn DC's. So (and again, please correct me if I am wrong), why are we forcing a successful network to subsidize one that isn't doing so well?

I don't think punishing one network for burning DC's is a fair move, even if it is for a short period of time. Especially 5G, because at least in my personal opinion, it will take a hecka more coverage until Lora catches up to 5G and wifi miners (When the time comes)

[mfalkvidd]

The latest podcast episode ( https://www.thehotspot.co/episodes/15-5g-omni-protocol-proof-of-coverage-w-boris-renski-james-fayal ) has a pretty good discussion on LoRaWAN vs 5G rewards. If you haven't already, listen to it to quickly and easily get up to speed. The podcast discussion is not the last word though, so any questions/feedback/critique is welcome.

[jamiew]

@zer0tweets @jmfayal any updates on the proposal here? Particularly the suggestions around breaking into two HIPs (see @Vagabond's post above)

[jmfayal]

I will need to hand off the technical questions to @zer0tweets and others, but I can address a couple of the concerns.

1. CBRS would not immediately adopt the entire left over DC bucket for PoC. As laid out in the HIP, it would only grow into that bucket as DC usage on CBRS grows. Yes, it could grow to outpace Lorawan, but that will require more carrier partners (DISH is a big step in the right direction) and many well placed units, so I think it will be gradual, especially as Lora DC usage has been growing exponentially recently. At the end of the day, if CBRS grows to be the dominant source of DC burn, I think it should have a correspondingly strong PoC incentive bucket.

2. I would like to see both of these things pass together because the eSIM PoC requires the economics portion of the HIP and the eSIM PoC part of the HIP is the first implementation of the economic portion of the HIP. It could be separated out, but I think that's only necessary if we don't think the eSIM portion of the HIP Is ready for implementation or is controversial. Now that units are going out into the world, I think it's important to back those up with a PoC function as quickly as possible.

[PaulVMo]

Hi guys, I still have a few comments/question on the latest version:

1. Depending on Lorawan to prevent location spoofing is not sufficient. First, there is no reason to require all 5G/WiFi hotspots to also support Lorawan. Also, more importantly, the location spoofing information from Lorawan PoC is not actually proposed to be used in omni-PoC calculations/validations in this HIP. So, while someone may spoof location, it doesn't actually impact omni-PoC rewards, just Lorawan. I don't believe that is a significant deterrent. Just like Lorawan, omni-POC should compare the asserted location of the hotspot and with the witnesses location (in this case, GPS from the mobile device). If the witness is not plausible based on the appropriate metrics for the network (maybe primarily distance), it should be invalid.
2. How are the rewards for individual challenges calculated? Is there a similar split between beaconer and witness like in Lorawan? That has a factor of 4 to 1 witness-to-beacon because of the need for redundancy in lorawan. However, redundancy doesn't apply with 5G and WiFi connections so maybe it ought to be different. Also, does density of hotspots play a role in the calculation at all?
3. Per James's frist point in the above reply, there needs to be clarification in the HIP on the exact allocation of rewards to omni-PoC until the second halving. Reading between the lines, I think what is meant is that non-lorawan PoC allocation will be calculated based on the ratio of DC usage between the two but then capped such that Lorawan allocation doesn't fall below 32.5% of all rewards. This could real use clarification since it is a point of confusion.

[vincenzospaghetti]

This HIP is deprecated by HIP 53 #345