From 6443818fec083b9a8580100e25d017b9a0317891 Mon Sep 17 00:00:00 2001 From: Joey Hiller <1965053+jthiller@users.noreply.github.com> Date: Tue, 16 Jan 2024 21:57:32 -0800 Subject: [PATCH] Run prettier across all HIPs (#878) --- ...x-density-based-transmit-reward-scaling.md | 14 +- 0033-regional-reward-adjustments.md | 6 +- 0055-validator-challenges.md | 9 +- 0072-secure-concentrators.md | 55 ++-- 0077-solana-parameters.md | 6 +- 0079-mobile-poc-mappers-rewards.md | 2 +- 0080-simplifying-dao-utility-score.md | 34 +-- 0081-minimum-onboarding-fee.md | 32 +- 0082-helium-mobile-service-provider.md | 18 +- 0083-restore-first-to-witness.md | 2 +- 0084-service-provider-hex-boosting.md | 2 +- 0085-mobile-hex-coverage-limit.md | 75 +++-- 0086-increase-iot-data-transfer-cost.md | 26 +- 0087-proportional-service-provider-rewards.md | 53 ++-- 0088-adjustment-of-dao-utility-a-score.md | 8 + 0089-mobile-network-onboard-fees.md | 35 ++- ...e-iot-location-assert-cost-indefinitely.md | 7 +- ...en-extension-reduced-iot-assertion-cost.md | 2 +- 0093-addition-of-wifi-aps-to-mobile-subdao.md | 35 ++- ...onse-time-windows-for-witness-rewarding.md | 286 +++++++++--------- ...-self-onboard-hotspots-after-maker-exit.md | 12 +- 0096-wifi-ap-onboarding-structure.md | 23 +- ...oving-manual-mobile-location-assertions.md | 33 +- ...-subdao-quality-of-service-requirements.md | 140 +++++---- ...8-region-plan-to-the-majority-of-africa.md | 82 +++-- ...lizing-poc-rewards-across-wifi-and-cbrs.md | 45 ++- 0102-helium-educational-lns.md | 4 + 0103-oracle-hex-boosting.md | 44 +-- ...tune-hip17-parameters-to-tackle-density.md | 27 +- ...odification-of-mobile-subdao-hex-limits.md | 129 ++++---- ...spot-bidirectional-coverage-requirement.md | 16 +- 31 files changed, 675 insertions(+), 587 deletions(-) diff --git a/0017-hex-density-based-transmit-reward-scaling.md b/0017-hex-density-based-transmit-reward-scaling.md index 1a11684c0..c906f5a5e 100644 --- a/0017-hex-density-based-transmit-reward-scaling.md +++ b/0017-hex-density-based-transmit-reward-scaling.md @@ -131,7 +131,7 @@ Hotspots. Note there are 7 “neighbor” hexs (6 + reference hex in center). The density limit follows the following criteria: | | | -|----------------------:|:-----------------------------------------------------| +| --------------------: | :--------------------------------------------------- | | **Occupied Count** | ![image n formula](files/0017/n_formula.PNG) | | **Hex Density Limit** | ![image limit formula](files/0017/limit_formula.PNG) | | | @@ -147,7 +147,7 @@ Density_max=4. The yellow / orange lines show the res7 hex boundaries to make it neighboring hexs do not have to belong to the same parent | Example 1 | Example 2 | Example 3 | Example 4 | -|:-----------------------------------------------:|:-----------------------------------------------:|:-----------------------------------------------:|:-----------------------------------------------:| +| :---------------------------------------------: | :---------------------------------------------: | :---------------------------------------------: | :---------------------------------------------: | | ![1 Hex occupied](files/0017/example_1_hex.svg) | ![1 Hex occupied](files/0017/example_2_hex.svg) | ![1 Hex occupied](files/0017/example_3_hex.svg) | ![1 Hex occupied](files/0017/example_7_hex.svg) | **Example 1**: there is one occupied hex that has 5 interactive Hotspots in it. Since this is the @@ -206,11 +206,11 @@ average and orange to red being below average. The map has a lot of content and speed so it may be laggy to view. | Manhattan, NY | San Fransisco, CA | -|:------------------------------------------:|:----------------------------------------:| +| :----------------------------------------: | :--------------------------------------: | | ![myc scaling](files/0017/nyc_scaling.png) | ![sf scaling](files/0017/sf_scaling.png) | | Modesto, CA | Austin, TX | -|:--------------------------------------------------:|:------------------------------------------------:| +| :------------------------------------------------: | :----------------------------------------------: | | ![modesto scaling](files/0017/modesto_scaling.png) | ![austin scaling](files/0017/austin_scaling.png) | ### How Transmit Reward Scaling is Used @@ -242,7 +242,7 @@ each Hotspot transmits exactly once. Finally, the rewards earned are assumed to simplified) reward distribution from beaconing above. | Topology | Reward Distribution | -|---------------------------------------------|--------------------------------------------| +| ------------------------------------------- | ------------------------------------------ | | ![ex 1 topo](files/0017/example_topo_1.png) | ![ex 2 topo](files/0017/example_rew_1.png) | This is an over-simplification of real-word data, but we can see that although D-H have a transmit @@ -257,7 +257,7 @@ Hotspots circled, assume transmissions can be heard by everyone in the set(s) th So for example D and E can witness all Hotspots but A can only witness C-E, not F or G. | Topology | Reward Distribution | -|---------------------------------------------|--------------------------------------------| +| ------------------------------------------- | ------------------------------------------ | | ![ex 2 topo](files/0017/example_topo_2.png) | ![ex 2 topo](files/0017/example_rew_2.png) | Based on this example we can see D and E earn the most even though they have half the transmit @@ -273,7 +273,7 @@ area. The table on the left below gives an estimate of the rewards when there is per hex and the table on the right when there are 20 Hotspots per hex. | 1 Hotspot per Hex | 20 Hotspots per Hex | -|:-------------------------------------------------:|:------------------------------------------------:| +| :-----------------------------------------------: | :----------------------------------------------: | | ![modesto scaling](files/0017/example_rew_3a.png) | ![austin scaling](files/0017/example_rew_3b.png) | We can see that although the per-hex earnings do go up with increased density, they only see a diff --git a/0033-regional-reward-adjustments.md b/0033-regional-reward-adjustments.md index 4e604888d..16e69f592 100644 --- a/0033-regional-reward-adjustments.md +++ b/0033-regional-reward-adjustments.md @@ -116,9 +116,7 @@ significant documentation update on how proof-of-coverage is performed and rewar -[hip-17]: - https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md -[jan 27 firmware update]: - https://engineering.helium.com/2021/01/27/hotspot-firmware-power-updates.html +[hip-17]: https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md +[jan 27 firmware update]: https://engineering.helium.com/2021/01/27/hotspot-firmware-power-updates.html [sf8125khz]: https://www.semtech.com/products/wireless-rf/lora-transceivers/sx1276 [miner pr #613]: https://github.com/helium/miner/pull/613 diff --git a/0055-validator-challenges.md b/0055-validator-challenges.md index 8690b3727..288be1435 100644 --- a/0055-validator-challenges.md +++ b/0055-validator-challenges.md @@ -266,11 +266,8 @@ new model, before that happens we need the new code to be merged, deployed to th Hotspots, validators, node users) and this HIP needs to be ratified. [hip54]: https://github.com/helium/HIP/blob/main/0054-h3dex-targeting.md -[proto]: - https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101 -[message-sequence]: - https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit -[poc-challenge-rate]: - https://user-images.githubusercontent.com/75/153673071-550eb970-4ab6-44e0-b9fc-e9b04e1b4dad.png +[proto]: https://github.com/helium/proto/blob/andymck/poc-grpc-msg-defs-WIP/src/service/gateway.proto#L101 +[message-sequence]: https://docs.google.com/drawings/d/1eVTK89ob66vlcEwwoVNi0BFaCEaU2DYki8778LIRWpA/edit +[poc-challenge-rate]: https://user-images.githubusercontent.com/75/153673071-550eb970-4ab6-44e0-b9fc-e9b04e1b4dad.png [hip10]: https://github.com/helium/HIP/blob/main/0010-usage-based-data-transfer-rewards.md [docs]: https://docs.helium.com/blockchain/mining#hnt-distributions-per-epoch diff --git a/0072-secure-concentrators.md b/0072-secure-concentrators.md index 191d96668..5436cbb92 100644 --- a/0072-secure-concentrators.md +++ b/0072-secure-concentrators.md @@ -17,7 +17,7 @@ In this HIP, we propose an amendment to HIP 19 to enable a new type of IoT netwo ## Motivation -Today's Helium Hotspots have a large security flaw. Anyone can modify the software running on a Hotspot and generate fake LoRa packets. This is a big problem because PoC rewards are based on these packets. The new Secure Concentrator Card solves this problem by digitally signing packets in hardware making it _prohibitively_ difficult to generate fake data. +Today's Helium Hotspots have a large security flaw. Anyone can modify the software running on a Hotspot and generate fake LoRa packets. This is a big problem because PoC rewards are based on these packets. The new Secure Concentrator Card solves this problem by digitally signing packets in hardware making it _prohibitively_ difficult to generate fake data. Also, Secure Concentrators will provide the Helium PoC Oracles data about the local area in which they are deployed. The trustworthy data can be used to build the next generation of gaming detection AI and improved PoC algorithms. The end result is a more secure Physical Root of Trust for the Helium IoT system and fair PoC earnings for all. @@ -40,67 +40,74 @@ The entire IoT Helium network will be affected by this HIP as the introduction o (TDOA)) ## Proof of Coverage Rewards + In order to incentivize adoption of Secure Concentrators, we propose increasing the earnings of PoC Witness packets received by Secure Concentrator by a factor of **(1.25x)**. We believe this is justified due to the increased security benefits the entire Helium network will enjoy with the addition of Secure Concentrators. A Secure Concentrator Hotspot is only eligible for the PoC reward if the Witness packet includes valid GPS time and location data. If a Secure Concentrator does not have a valid GPS lock at the time of receiving the Witness packet, it will not receive any reward. This incentive structure is part of a larger future roadmap with more network improvements and hardware types that will each have their own incentives. The proposed 1.25x rewards is intended to incentivize initial adoption. The rewards structure is subject to change with adoption of future HIP. ## Manufacturers + Hardware Manufacturers of Secure Concentrators will be required to be approved by the Helium -Manufacturer Compliance Committee and pass a hardware audit process similar to the hardware audit process required for Hotspot manufacturers (see HIP-19). +Manufacturer Compliance Committee and pass a hardware audit process similar to the hardware audit process required for Hotspot manufacturers (see HIP-19). The process of onboarding new Secure Concentrators onto the Helium network is very similar to the Hotspot onboarding process as described in HIP-19. Manufacturers will also be bound by the same code of ethics as described in HIP-19. Also, the Helium Manufacturing Compliance Committee (MCC) will have the same authority over approved Manufacturers. ## Installation -Hotspot owners can optionally upgrade their existing Hotspot with a Secure Concentrator if they have a Hotspot that is capable of the upgrade. Most Hotspot designs that use a mPCIe card slot are capable of the upgrade. However, upgrading a Hotspot may void the warranty. Hotspot manufacturers are NOT required to support upgrade to Secure Concentrator. It is the Hotspot Manufacturer's discretion to provide support for SCCs. + +Hotspot owners can optionally upgrade their existing Hotspot with a Secure Concentrator if they have a Hotspot that is capable of the upgrade. Most Hotspot designs that use a mPCIe card slot are capable of the upgrade. However, upgrading a Hotspot may void the warranty. Hotspot manufacturers are NOT required to support upgrade to Secure Concentrator. It is the Hotspot Manufacturer's discretion to provide support for SCCs. manufacturers can include SCCs in new Hotspots designs, in which case manufacturers are responsible for providing installation and service for Secure Concentrator. Use of SCC in Hotspot design satisfies the HIP 19 requirement for Encrypted/locked-down firmware and Encrypted storage of the miner swarm_key. To be clear, Hotspots that use SCC will not be required to have locked-down firmware and will not be required to securely store the swarm_key. (Note swarm_key is not the same as the SCC's Hardware Key). ## General Requirements + This HIP gives authority the MCC to design a process for approving Secure Concentrators. The approval process may involve engaging with 3rd party security labs for intensive hardware/software penetration testing. Ultimately, the MCC shall hold final approval power of a candidate Secure Concentrator design. That being said, a Secure Concentrator design should meet the following requirements: ### Hardware features An SCC design must meet the following minimum hardware requirements: - - Onboard GNSS (GPS) receiver. GPS provides geolocation and timestamping reference of every received packet. The GPS horizontal and vertical position error must be less than 20 meters 99% of the time. - - Appropriate hardware to precisely timestamp the arrival of received LoRa packets on par with Semtech SX1303. - - Ability to sign the received LoRa packets and associated metadata (GPS location, time, frequency, etc.) with a secured asymmetric key (see further security requirements). +- Onboard GNSS (GPS) receiver. GPS provides geolocation and timestamping reference of every received packet. The GPS horizontal and vertical position error must be less than 20 meters 99% of the time. +- Appropriate hardware to precisely timestamp the arrival of received LoRa packets on par with Semtech SX1303. +- Ability to sign the received LoRa packets and associated metadata (GPS location, time, frequency, etc.) with a secured asymmetric key (see further security requirements). ### Security requirements An SCC design must meet all the following minimum security requirements: - 1. A Secure Element capable of managing a permanent, unique ED25519 asymmetric key. - 2. A Security Boundary that ensures that: +1. A Secure Element capable of managing a permanent, unique ED25519 asymmetric key. +2. A Security Boundary that ensures that: - The Secure Element only obeys signature requests from a Secure Processor. - The radio hardware is exclusively controlled by the Secure Processor. - All packets and meta-data attested by the Secure Processor come only from the radio and not from an external source. - The Secret key is only used to sign packet and meta-data or data with `no-rf` prefix. - Read access to Secret key material is restricted to the Secure Processor only. - Write access to the Secret key material if forbidden. - 3. A Secure Processor that only runs software which has been cryptographically authenticated to have come from the Manufacturer (or the MCC). +3. A Secure Processor that only runs software which has been cryptographically authenticated to have come from the Manufacturer (or the MCC). No design will be approved unless it meets all criteria. Example design choices that reflect these requirements are: - - Using buried traces (2 & 3) - - Placing components under metal shields (2 & 3) - - Using potting material (2 & 3) - - Resistance to timing attacks (1) - - Resistance to fault injection (1, 2 and 3). - - Separate buses between the Host and the Secure Element (2) + +- Using buried traces (2 & 3) +- Placing components under metal shields (2 & 3) +- Using potting material (2 & 3) +- Resistance to timing attacks (1) +- Resistance to fault injection (1, 2 and 3). +- Separate buses between the Host and the Secure Element (2) ### Performance requirements - 1. Can sign 10 or more packet receipts per second. + +1. Can sign 10 or more packet receipts per second. ### Process requirements + All effort must be taken to ensure the Hardware Key stored in the Secure Concentrator remains a secret. Manufacturers themselves should never have access to the keys. Also, Manufacturers are required to have strong processes in place for handling firmware updates. manufacturers must demonstrate prudence when handling firmware update key. Manufacturers must also have a firmware update contingency plan in place in the event the Manufacturer should cease to support their product. To these ends, Manufacturers of Secure Concentrator are required to practice the following process requirements: - 1. Secure key generation is performed on the Secure Concentrator hardware itself. The key material is never transferer in or out of the Secure Concentrator. - 2. The Provisioning process must disable all diagnostic/debug interfaces permanently. - 3. The Manufacturer must disclose via written document to the MCC their process for handling firmware updates including who has access to the firmware update keys and how the key is securely stored. - 4. The Manufacturer must disclose via written document to the MCC their firmware update contingency plan. +1. Secure key generation is performed on the Secure Concentrator hardware itself. The key material is never transferer in or out of the Secure Concentrator. +2. The Provisioning process must disable all diagnostic/debug interfaces permanently. +3. The Manufacturer must disclose via written document to the MCC their process for handling firmware updates including who has access to the firmware update keys and how the key is securely stored. +4. The Manufacturer must disclose via written document to the MCC their firmware update contingency plan. One possible contingency plan is to use the "dual-key" update design. Under this plan, a Secure Concentrator will accept updates from either the Manufacturer's firmware update key OR the MCC's firmware update key. Another possible contingency plan is to enter into an escrow agreement in which a third-party keeps a copy of the firmware update key. In the event the Manufacturer ceases to support the product, the third party transfers control of the firmware update key to the MCC. @@ -123,6 +130,7 @@ The Secure Concentrator signs LoRa packets and metadata with its unique ED25519 Signing data packets is performed by first converting the packet's metadata, payload, gps time, and location into a byte stream. The data is encoded using [Borsh](https://borsh.io/) serialization. Here we have the structure of received LoRa packets and metadata. + ``` struct RxPkt { /// Frequency in Hertz @@ -162,6 +170,7 @@ struct WGS84Position { ``` ### Example Signature + ``` let pkt = RxPkt { freq: 904_000_000, @@ -202,6 +211,7 @@ Note: Secure Concentrators use ED25519 streaming (incremental) API for producing The SMCU can also sign any arbitrary data with its Hardware Key upon request. However, the signature will always include the string prefix `nonrf` in its message creation to distinguish from RF data. For example, signing the ascii-encoded byte array: `hello world` would result: + ``` private key: 38870584fa7cb9e56efe921a65e02fcc18d6d8e9fcfec7796181f422e6aa1e3fd466e616d43b44e2e045be240ad9faf7090fb444312445cef01f21ed5f74e55e noise: 000102030405060708090a0b0c0d0e0f @@ -210,9 +220,8 @@ sig (ED25519): 388609f27448a6981876edac0b9ed13f65015b36e48963056393434f562af0763 Note: Secure Concentrators use ED25519 streaming (incremental) API for producing encrypted signatures. - - ## Example Hardware Architecture + NLighten Systems has developed an open-source hardware and firmware Secure Concentrator reference design with the aid of a Helium Foundation grant. The design files can be found here: https://gitlab.com/nlighten-systems/kompressor/ The following sections describe the reference design choices. Alternative Secure Concentrator design does not necessarily need to include the same design components as long as it adheres to the General Requirements. @@ -221,6 +230,7 @@ Note: approval of this HIP does NOT automatically approve NLighten System's desi ![image ](files/0072/hardware_block.png) NLighten hardware architecture for SCC is based on Semtech's LoRa Corecell Gateway reference design. The major change involves the addition of a Secure MCU (**SMCU**) placed in between the communication path of the Host CPU and the SX1303. The SMCU's primary job is to cryptographically sign RF data received over the air such that other nodes participating on the Helium network are able to verify the data is authentic and unaltered from it original form. It is important the SMCU has exclusive access SX1303's SPI bus to eliminate the possibility of spoofing incoming RF packets. The hardware design employs several techniques to make it physically difficult to access the SMPU and SX130x including using buried traces, placing the components under a metal shield, and using hard-curing potting material. ### Semtech SX1303 + The Semtech SX1303 is a new generation of LoRa baseband processor for gateways. It is size and pin compatible with SX1302 and like SX1302, it excels in cutting down current consumption, simplifying thermal design, lowering Bill Of Materials cost, and reducing overall size of gateways. In addition to supporting all the features of SX1302, SX1303 introduces a new Fine Timestamp capability that enables Time Difference of Arrival (TDOA) network-based geolocation. The new TDOA feature could potentially enable another layer of Proof of Coverage. For example, Helium Hotspots using SX1303 chipset could coordinate together to assert that another Helium Hotspot's beacon signal actually originated from the stated geolocation. ### Hardware Key @@ -251,4 +261,3 @@ Changes to the blockchain code will need to be made and tested on the `testnet`. ## Success Metrics SCC success can be measured several ways. One metric will be the number of DIY Hotspots and Secure mapper devices built with SCC. Another metric is the amount of low-power sensors that utilize the TDoA location services SCC provide. Also the amount of DCs associated with those sensors. Finally, Secure Concentrators will enjoy in the success of any future PoC algorithm that utilizes its data. - diff --git a/0077-solana-parameters.md b/0077-solana-parameters.md index e4599fe3e..ecb11ee72 100644 --- a/0077-solana-parameters.md +++ b/0077-solana-parameters.md @@ -11,6 +11,7 @@ This HIP describes several parameters analogous to the chain variables of the current L1. These parameters can be changed by an update authority which will be held by a wallet requiring multiple signatures (multisig) initially held by the Helium Foundation. The HIP proposes the following initial parameters: + - Decimals for HNT: `8` - Decimals for MOBILE: `6` - Decimals for IOT: `6` @@ -96,7 +97,6 @@ will need to be adjusted as more rewardable entities, like mappers, are added. T The full token emissions schedule as of Solana Migration can be downloaded [here](files/0077/token-emissions-as-of-solana-migration.pdf). - ### Landrush Period HIP-51 specified a 7 day landrush period. Due to the fact that the migration will likely happen between UTC days, we feel that it is better to extend the landrush period to 10 days to guarantee that everyone in every time zone has a minimum of 7 days to get the landrush bonus. @@ -109,9 +109,9 @@ We propose that the chain halt and Solana launch should start on April 18th, 202 On Solana, we have access to a Pyth price oracle on the HNT price. This oracle includes data from multiple exchanges, as well as market makers and other publishers on the HNT token. We propose using this Oracle instead of the existing oracle approach. -Pyth is not available for MOBILE and IOT prices, and so we propose these prices should follow a similar pattern to the current HNT price oracle on the helium L1, documented [here](https://docs.helium.com/blockchain/oracles/). During the initial few weeks post-launch, Pyth price feeds will also not be available for HNT. We propose using the same pattern for the current HNT price oracle until Pyth oracles are live. +Pyth is not available for MOBILE and IOT prices, and so we propose these prices should follow a similar pattern to the current HNT price oracle on the helium L1, documented [here](https://docs.helium.com/blockchain/oracles/). During the initial few weeks post-launch, Pyth price feeds will also not be available for HNT. We propose using the same pattern for the current HNT price oracle until Pyth oracles are live. -It is necessary to know the IOT and MOBILE prices for rewards calculations. +It is necessary to know the IOT and MOBILE prices for rewards calculations. # Drawbacks diff --git a/0079-mobile-poc-mappers-rewards.md b/0079-mobile-poc-mappers-rewards.md index 86db70d63..2658736c0 100644 --- a/0079-mobile-poc-mappers-rewards.md +++ b/0079-mobile-poc-mappers-rewards.md @@ -121,7 +121,7 @@ The Mobile PoC Working Group has also agreed to initiate work on a Mapper subDAO #### Subscribers -Subscribers will share detailed location information with their Service Providers, allowing them to define which hexes to boost. Service Providers voted to participate in Helium Mobile subDAO are required to keep exact subscriber mobile location data confidential. The specific confidentiality terms are subject to the service agreement between each particular service provider and the subscribers. +Subscribers will share detailed location information with their Service Providers, allowing them to define which hexes to boost. Service Providers voted to participate in Helium Mobile subDAO are required to keep exact subscriber mobile location data confidential. The specific confidentiality terms are subject to the service agreement between each particular service provider and the subscribers. Subscribers will share binary information about whether location sharing event has occurred and the timestamp of the event to the Mobile Oracle for reward eligibility determination. Service Providers will verify the information Subscribers share before it is sent to the Mobile Oracle to prevent gaming. diff --git a/0080-simplifying-dao-utility-score.md b/0080-simplifying-dao-utility-score.md index 8288a7a85..ddf1735a1 100644 --- a/0080-simplifying-dao-utility-score.md +++ b/0080-simplifying-dao-utility-score.md @@ -3,8 +3,8 @@ - Author: [@ferebee](https://github.com/ferebee), [@jmfayal](https://github.com/jmfayal), [@rawrmaan](https://github.com/rawrmaan), [@gateholder](https://github.com/gateholder) - Start Date: 2023-03-29 - Category: Economic, Technical -- Original HIP PR: -- Tracking Issue: +- Original HIP PR: +- Tracking Issue: # Summary @@ -62,7 +62,7 @@ $A = \text{max}(1, \sqrt[4]{\text{DNP Active Device Count} \times \text{DNP Devi HIP-53 describes a [$40 onboarding fee](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md#economics-overview) and $10 location assertion fee, analogous to the traditional fees assessed for IOT Hotspots. However, the gateways developed by FreedomFi and used to launch the MOBILE network, as well as models introduced by other manufacturers, include both IOT and MOBILE Hotspot functions, which operate independently. In the existing implementation, the IOT Hotspot component is onboarded in the same way as all other Helium IOT Hotspots, with a $40 onboarding fee and a $10 location assert. However, the MOBILE Hotspot component itself currently performs no onboarding operation of its own, but it is treated as if it were onboarded nonetheless. -As a result, the *A* component of the Score is currently 1 for the MOBILE subDAO, as no onboarding fees (a. k. a. Activation Fees) have yet been burned to the MOBILE subDAO. +As a result, the _A_ component of the Score is currently 1 for the MOBILE subDAO, as no onboarding fees (a. k. a. Activation Fees) have yet been burned to the MOBILE subDAO. Due to this implementation oversight, the DAO Utility Score of MOBILE as defined by HIP-51 is slated to launch far below its intended value, which would impair the incentive for participants to deploy new MOBILE Hotspots for Helium 5G. The buildout of Helium 5G is essential for the upcoming launch of Helium Mobile and therefore the growth of the Helium DAO as a whole. @@ -74,13 +74,13 @@ Therefore, under the existing model, the DAO Utility Score of the IOT subDAO cou ## Influence of veHNT -Independent of the installed Hotspots and the Data Transfer and DC burn they contribute, the *V* component of the DAO Utility Score as defined in HIP-51 considers the veHNT delegated to the various subDAOs. This is intended as a way for network participants to signal their preference for a particular subDAO. By encouraging participants to lock their HNT for veHNT, it also contributes to the stability of the Helium DAO and its governance. +Independent of the installed Hotspots and the Data Transfer and DC burn they contribute, the _V_ component of the DAO Utility Score as defined in HIP-51 considers the veHNT delegated to the various subDAOs. This is intended as a way for network participants to signal their preference for a particular subDAO. By encouraging participants to lock their HNT for veHNT, it also contributes to the stability of the Helium DAO and its governance. -While the *A* component, which counts Hotspots and their onboarding fees, is counted by its fourth root, and the *D* component, which counts Data Transfer, is counted by its square root, the *V* component is counted linearly. +While the _A_ component, which counts Hotspots and their onboarding fees, is counted by its fourth root, and the _D_ component, which counts Data Transfer, is counted by its square root, the _V_ component is counted linearly. This gives inordinate weight to the delegation of veHNT. For example, 10 times the amount of delegated veHNT would have the same weight as 100 times the DC burn from Data Transfer, or 10,000 times the number of Hotspots. -Modeling has shown that this favors a winner-takes-all scenario. Once one subDAO has received a large majority of delegated veHNT, the *V* component of the DAO Utility Score dominates the Score to such an extent that it becomes economically unattractive to delegate to any other subDAO, considering the delegation rewards that are available in the different subDAOs, as valued through the treasury exchange rate to HNT. Another subDAO, even if it provides network coverage and DC burn that are valuable to the Helium DAO as a whole, could be unable to attract sufficient veHNT delegation to reward its participants appropriately. +Modeling has shown that this favors a winner-takes-all scenario. Once one subDAO has received a large majority of delegated veHNT, the _V_ component of the DAO Utility Score dominates the Score to such an extent that it becomes economically unattractive to delegate to any other subDAO, considering the delegation rewards that are available in the different subDAOs, as valued through the treasury exchange rate to HNT. Another subDAO, even if it provides network coverage and DC burn that are valuable to the Helium DAO as a whole, could be unable to attract sufficient veHNT delegation to reward its participants appropriately. ## Onboarding Fee @@ -104,9 +104,9 @@ $V = \text{max}(1, \sqrt{veHNT_{DNP}})$ $D = \text{max}(Floor, \sqrt{\text{DNP DCs burned per epoch in USD}})$ -and *Floor* is 7 for all subDAOs except for the IOT subDAO. +and _Floor_ is 7 for all subDAOs except for the IOT subDAO. -*Floor* shall be 40 for the IOT subDAO until the fourth halvening of HNT emissions, which is currently scheduled to occur on 1 August 2027. Then, it shall revert to 7. +_Floor_ shall be 40 for the IOT subDAO until the fourth halvening of HNT emissions, which is currently scheduled to occur on 1 August 2027. Then, it shall revert to 7. # Discussion of HIP-80 Utility Score @@ -114,9 +114,9 @@ and *Floor* is 7 for all subDAOs except for the IOT subDAO. HIP-51 recognizes that the participants of the IOT subDAO jumpstarted the Helium DAO with a large investment in hardware despite challenges in the supply chain, and have decided to invite the MOBILE subDAO and future subDAOs into the Helium DAO while anticipating that they would be able to share in the joint success of all future DAO networks. -The *A* factor of the DAO Utility Score as proposed in HIP-51, which counts the number of active Hotspots multiplied by their onboarding fees, was intended to respect this contribution by giving an initial advantage to the IOT subDAO. +The _A_ factor of the DAO Utility Score as proposed in HIP-51, which counts the number of active Hotspots multiplied by their onboarding fees, was intended to respect this contribution by giving an initial advantage to the IOT subDAO. -To respect this intent while simplifying the calculation, HIP-80 proposes to give the IOT subDAO an explicit—but limited—advantage by setting its *Floor* to 40. +To respect this intent while simplifying the calculation, HIP-80 proposes to give the IOT subDAO an explicit—but limited—advantage by setting its _Floor_ to 40. The effect of this is to treat the IOT subDAO as if @@ -126,19 +126,19 @@ $\text{IOT DCs burned per epoch in USD} = 40 \times 40 \text{USD} = 1,600 \text{ $\text{IOT DCs burned per 30 days in USD} = 48,000 \text{USD.}$ -This special treatment of IOT shall last until the fourth halvening of HNT emissions, which is scheduled for 1 August 2027, when *Floor* for IOT shall revert to 7. +This special treatment of IOT shall last until the fourth halvening of HNT emissions, which is scheduled for 1 August 2027, when _Floor_ for IOT shall revert to 7. In other words, as soon as the IOT subDAO achieves a monthly DC burn of $48,000, its founder’s bonus will become irrelevant. If it cannot achieve this burn by 1 August 2027, it will have to succeed or fail on its own merits. As was proposed in the discussions leading up to HIP-51, this will ensure that the IOT subDAO has the opportunity to receive a majority share of total HNT emissions as long as other subDAOs are not contributing significant DC burn. -Similarly to the calculations above, the effect of the *Floor* of 7 for all other subDAOs besides IOT is to treat all subDAOs as if they were to burn at least $1,470 of DC per month. This ensures that the MOBILE treasury will get some share of HNT emissions from launch, and provides for a minimum level of HNT emissions (subject to the *V* factor) to any future subDAOs which may be approved to join the Helium DAO. +Similarly to the calculations above, the effect of the _Floor_ of 7 for all other subDAOs besides IOT is to treat all subDAOs as if they were to burn at least $1,470 of DC per month. This ensures that the MOBILE treasury will get some share of HNT emissions from launch, and provides for a minimum level of HNT emissions (subject to the _V_ factor) to any future subDAOs which may be approved to join the Helium DAO. On the other hand, once Helium Mobile and possibly other Service Providers begin moving data over Helium 5G, the MOBILE subDAO may quickly begin burning significantly more DC than the notional $48,000/month floor attributed to the IOT subDAO, so the MOBILE subDAO may then be able to capture a larger share of total HNT emissions, while also contributing the greater value to the Helium DAO and thus to HNT itself by virtue of its greater rate of DC burn. This in turn will benefit the IOT subDAO as well. -## *A* Factor +## _A_ Factor -As discussed above, HIP-80 eliminates the *A* factor of the DAO Utility Score entirely, replacing the implicit advantage at launch it would grant the IOT subDAO with an explicit guaranteed minimum DC burn factor. +As discussed above, HIP-80 eliminates the _A_ factor of the DAO Utility Score entirely, replacing the implicit advantage at launch it would grant the IOT subDAO with an explicit guaranteed minimum DC burn factor. By eliminating the dependence on the number of active Hotspots and the onboarding fees charged by subDAOs, the new Utility Score introduced by HIP-80 greatly simplifies calculations that would otherwise need to be performed by Oracles and/or smart contracts of the Helium DAO. @@ -150,7 +150,7 @@ The Score proposed in HIP-51 gives such a high weight to veHNT delegation, which Therefore, the new DAO Utility Score proposed by HIP-80 considers veHNT delegation and DC burn equally, by multiplying together the square root of each. -# New Onboarding Fee +# New Onboarding Fee The Utility Score proposed in HIP-80 eliminates the incentive for subDAOs to compete for HNT emissions through the onboarding fees charged to their Hotspots, as fees are no longer relevant to the Score and thus the share of HNT emissions to each subDAO. @@ -173,14 +173,14 @@ This proposal may require some DAO participants to revisit their evaluations of # Deployment Impact -The calculation of Utility Score will need to be adjusted. Based on feedback from the HIP-70 implementation team, this is possible within the existing development framework. It would be desirable to finalize all changes to the Utility Score before the Solana transition on 18 April 2023. +The calculation of Utility Score will need to be adjusted. Based on feedback from the HIP-70 implementation team, this is possible within the existing development framework. It would be desirable to finalize all changes to the Utility Score before the Solana transition on 18 April 2023. # Clarifications - subDAOs may continue to assess location assertion fees, which are determined by subDAO governance. - The Helium DAO HNT emissions contract distributes HNT to HST holders as specified in HIP-20. - In clarification of HIP-51, all remaining HNT is distributed between all subDAOs in proportion to their relative DAO Utility Scores. -- If the fourth halvening of HNT emissions falls on a different date than 1 August 2027 for any reason, the founder’s bonus IOT *Floor* of 40 shall remain in effect until then and end on that date. +- If the fourth halvening of HNT emissions falls on a different date than 1 August 2027 for any reason, the founder’s bonus IOT _Floor_ of 40 shall remain in effect until then and end on that date. # Success Metrics diff --git a/0081-minimum-onboarding-fee.md b/0081-minimum-onboarding-fee.md index e79d1eacc..963b21b27 100644 --- a/0081-minimum-onboarding-fee.md +++ b/0081-minimum-onboarding-fee.md @@ -1,24 +1,24 @@ # HIP 81: Minimum Device Onboarding Fee -- Author(s): @mawdegroot, @Maxgold91 -- Start Date: 2023-04-07 +- Author(s): @mawdegroot, @Maxgold91 +- Start Date: 2023-04-07 - Category: economic Economic - Original HIP PR: #606 - Tracking Issue: ## Summary -This HIP proposes to set a minimum onboarding fee for devices in the subDAO structure. This HIP also proposes that devices for which the minimum onboarding fee has not been burned are not eligible for rewards from the subDAO. The minimum onboarding fee will be dynamically defined as $10 on August 1, 2023 and will follow the same halving schedule as HNT emissions as shown in the chart below. It is important to note, this HIP only defines a minimum fee and at the time of its writing, HIPs 51-53 have defined the onboarding fees as $40 per hotspot. If a subDAO wishes to change its onboard fees, it must do so through the subDAO governance process. This HIP will be implemented in phases, first clearly defining the requirements at the time of its passing, then on-chain with a target date of August 1, 2023. +This HIP proposes to set a minimum onboarding fee for devices in the subDAO structure. This HIP also proposes that devices for which the minimum onboarding fee has not been burned are not eligible for rewards from the subDAO. The minimum onboarding fee will be dynamically defined as $10 on August 1, 2023 and will follow the same halving schedule as HNT emissions as shown in the chart below. It is important to note, this HIP only defines a minimum fee and at the time of its writing, HIPs 51-53 have defined the onboarding fees as $40 per hotspot. If a subDAO wishes to change its onboard fees, it must do so through the subDAO governance process. This HIP will be implemented in phases, first clearly defining the requirements at the time of its passing, then on-chain with a target date of August 1, 2023. | Date | Minimum Onboard Fee in DC | -|------------|--------------------------:| -| 08/01/2023 | 1,000,000 | -| 08/01/2025 | 500,000 | -| 08/01/2027 | 250,000 | -| 08/01/2029 | 125,000 | -| 08/01/2031 | 62,500 | -| 08/01/2033 | 31,250 | -| 08/01/2035 | 15,625 | +| ---------- | ------------------------: | +| 08/01/2023 | 1,000,000 | +| 08/01/2025 | 500,000 | +| 08/01/2027 | 250,000 | +| 08/01/2029 | 125,000 | +| 08/01/2031 | 62,500 | +| 08/01/2033 | 31,250 | +| 08/01/2035 | 15,625 | The HIP authors fully support any community initiative to set a floor price to stop the halving at a future date. However, it is our opinion that the current halving schedule gives the network about 8-10 years to figure out which figure works best. The halving schedule was chosen to be in line with the theory of Moore's Law and roughly correlate to the CAPEX required for these networks. If these features, in the future, are no longer relevant, the Helium DAO should update the minimum onboard price to be in line with future economic forces. @@ -26,8 +26,8 @@ The HIP authors fully support any community initiative to set a floor price to s A minimum onboarding fee is necessary to: -1. Stop subDAOs from arbitrarily onboarding Hotspots. -2. Prevent nuisance attacks against subDAOs and the Helium DAO. +1. Stop subDAOs from arbitrarily onboarding Hotspots. +2. Prevent nuisance attacks against subDAOs and the Helium DAO. HIP51 has described the onboarding of Hotspots but has not made this explicit. Hotspots for which the minimum onboarding fee has not been burnt are not eligible for rewards. SubDAOs attempting to bypass this requirement will be subject to slashing. @@ -73,13 +73,13 @@ The DAO Utility Score will use the onboarding fee that has been burned for a spe #### Grace Period -Due to technical limitations of the network architecture, and the complexities of the engineering required, during the proposal of this Helium Improvement Proposal (HIP), as well as the timing of the Solana migration, this HIP hereby sets a compliance deadline of August 1, 2023, for subDAOs that are non-compliant. This grace period affords subDAOs the opportunity to operate as if the burn occurred on April 17, 2023 (prior to the migration). However, it necessitates a retroactive burn to reconcile any outstanding onboarding debts [in a manner consistent with the previous IOT retroactive burn.](https://explorer.helium.com/txns/5hSdF8hhyYz1VNI6DxdI_GiaKV0xyR5IJQzIluYDu0w) +Due to technical limitations of the network architecture, and the complexities of the engineering required, during the proposal of this Helium Improvement Proposal (HIP), as well as the timing of the Solana migration, this HIP hereby sets a compliance deadline of August 1, 2023, for subDAOs that are non-compliant. This grace period affords subDAOs the opportunity to operate as if the burn occurred on April 17, 2023 (prior to the migration). However, it necessitates a retroactive burn to reconcile any outstanding onboarding debts [in a manner consistent with the previous IOT retroactive burn.](https://explorer.helium.com/txns/5hSdF8hhyYz1VNI6DxdI_GiaKV0xyR5IJQzIluYDu0w) For purposes of determining the MOBILE subDAO's $A$ score, a value of $40 shall be allocated per FreedomFi and 'Bobcat 5G' gateway that has been onboarded and is actively participating in either subDAO's Proof of Coverage at any point during the preceding 30 epochs. In the event that the MOBILE subDAO onboards via burn before the compliance deadline, the greater of the allocated value or the actual burn shall be counted. If the actual onboard burn number falls short of the grace period amount, the Helium DAO shall reduce any incremental HNT earned from the MOBILE subDAO treasury via slashing. #### Onboarding Devices -[HIP51](./0051-helium-dao.md) defines active devices as "_Active devices are the subDAO's definition of devices creating valid coverage (aka Hotspots) and therefore being rewarded during the epoch_". This definition will implicitly prevent devices that have not been onboarded to be credited towards the DAO Utility Score as the unonboarded devices are not allowed to be rewarded for anything other than data transfer. This includes, but is not limited to, Proof-of-Coverage rewards, pre-mine rewards, challenge construction rewards, and any other rewards that are not directly related to data transfer. Devices onboarded at the time of the Solana migration that do not meet the minimum outlined in this HIP may still be credited towards the DAO Utility Score based on the DC burn to onboard them (data only LoRaWAN hotspots). +[HIP51](./0051-helium-dao.md) defines active devices as "_Active devices are the subDAO's definition of devices creating valid coverage (aka Hotspots) and therefore being rewarded during the epoch_". This definition will implicitly prevent devices that have not been onboarded to be credited towards the DAO Utility Score as the unonboarded devices are not allowed to be rewarded for anything other than data transfer. This includes, but is not limited to, Proof-of-Coverage rewards, pre-mine rewards, challenge construction rewards, and any other rewards that are not directly related to data transfer. Devices onboarded at the time of the Solana migration that do not meet the minimum outlined in this HIP may still be credited towards the DAO Utility Score based on the DC burn to onboard them (data only LoRaWAN hotspots). We believe any incremental additions to hotspots that materially increase its price and materially increases its ability to mine more of a subDAO’s DNT constitutes a new device that must be onboarded. However, Helium DAO will give the subDAOs the freedom to reasonably decide what it considers to be a device. It is the position of Helium DAO that, while we encourage ECC chips and other similar security measures for devices, it is not a requirement and leave that distinction up to the subDAO. We also feel it is not necessary for a device to live on-chain if a subDAO feels it can effectively count and reward devices using off-chain oracles. SubDAOs that choose to maintain their device list and Proof-of-Coverage architecture in off-chain oracles agree to reasonable periodic audits at the Helium DAOs request. @@ -107,7 +107,7 @@ The migration to Solana requires every Hotspot to be onboarded to every subDAO i ## Implementation -To be implemented at the time of the Solana Migration on April 18th as part of the ongoing smart contract and subDAO work by the Helium Foundation. Full implentation will take place on or around August 1, 2023. +To be implemented at the time of the Solana Migration on April 18th as part of the ongoing smart contract and subDAO work by the Helium Foundation. Full implentation will take place on or around August 1, 2023. ## Unresolved Questions diff --git a/0082-helium-mobile-service-provider.md b/0082-helium-mobile-service-provider.md index b5b3ee85c..abd88200b 100644 --- a/0082-helium-mobile-service-provider.md +++ b/0082-helium-mobile-service-provider.md @@ -15,7 +15,7 @@ This HIP proposes to introduce Helium Mobile as a Service Provider (as defined i The Community has gone a long way in building the Helium Mobile Network. Now is the perfect time to bring usage and utility to it. -As a Service Provider member of the Helium Mobile subDAO, Helium Mobile will actively offload its subscriber traffic onto the Helium Mobile Network. The launch of the Helium Mobile carrier will help pave the way for other Service Providers coming to the Helium Mobile Network by ironing out any undiscovered issues and creating a smooth onboarding process. In addition, the increased traffic on the network as a result of the launch will have a commensurate increase in HNT burn and data rewards for Hotspot operators. +As a Service Provider member of the Helium Mobile subDAO, Helium Mobile will actively offload its subscriber traffic onto the Helium Mobile Network. The launch of the Helium Mobile carrier will help pave the way for other Service Providers coming to the Helium Mobile Network by ironing out any undiscovered issues and creating a smooth onboarding process. In addition, the increased traffic on the network as a result of the launch will have a commensurate increase in HNT burn and data rewards for Hotspot operators. ## Stakeholders @@ -37,19 +37,19 @@ In compliance with HIP53 staking requirements for Service Providers, Helium Mobi Once the required amount is staked, the Helium Mobile Service Provider will be minted as an NFT by the ‘Helium entity manager’ smart contract on the Solana blockchain and will become a rewardable entity. -This stake will need to remain locked and will not earn any staking rewards, as long as the Service Provider remains as part of the MOBILE subDAO. In lieu of staking rewards, the Service Provider has the right to claim up to 10% of MOBILE rewards (provided [HIP79](https://github.com/helium/HIP/blob/main/0079-mobile-poc-mappers-rewards.md) passes) in the Service Provider bucket. +This stake will need to remain locked and will not earn any staking rewards, as long as the Service Provider remains as part of the MOBILE subDAO. In lieu of staking rewards, the Service Provider has the right to claim up to 10% of MOBILE rewards (provided [HIP79](https://github.com/helium/HIP/blob/main/0079-mobile-poc-mappers-rewards.md) passes) in the Service Provider bucket. -This HIP requires a cooldown period of 90-days after a public announcement by the Service Provider of its intention to cease data offloading on Helium's mobile network before it can stop such data offloading. An additional 90-day cooldown period will be required before the Service Provider can claim the tokens they staked for the right to operate as a Service Provider on Helium's mobile network. +This HIP requires a cooldown period of 90-days after a public announcement by the Service Provider of its intention to cease data offloading on Helium's mobile network before it can stop such data offloading. An additional 90-day cooldown period will be required before the Service Provider can claim the tokens they staked for the right to operate as a Service Provider on Helium's mobile network. ### Data Offloading to the Helium Mobile Network -Helium Mobile will operate as a roaming partner on Helium's mobile network using Data Credits (DC) to pay for data transfer at a minimum price of $0.50 per 1 GB as specified in HIP53. Any changes to the minimum price for data transfer anywhere on Helium's mobile network must be approved by MOBILE subDAO vote. More specific regional or individual radio pricing options above the minimum price can be set by Helium Mobile but are subject to approval by MOBILE subDAO vote. +Helium Mobile will operate as a roaming partner on Helium's mobile network using Data Credits (DC) to pay for data transfer at a minimum price of $0.50 per 1 GB as specified in HIP53. Any changes to the minimum price for data transfer anywhere on Helium's mobile network must be approved by MOBILE subDAO vote. More specific regional or individual radio pricing options above the minimum price can be set by Helium Mobile but are subject to approval by MOBILE subDAO vote. Where Helium Mobile Network coverage is unavailable, Helium Mobile will rely on the additional coverage provided by their current Mobile Network Operator (MNO), T-Mobile. The partnership of Nova Labs with their MNO allows Helium Mobile subscribers to access both nationwide 5G coverage by the MNO and the growing Helium Mobile Network, which, due to its people-driven nature, is available in places that are hard to reach and acquire by traditional service providers. More details about Nova Labs and T-Mobile partnership can be found in the [press release](https://www.webwire.com/ViewPressRel.asp?aId=294475). -### Governance +### Governance HIP53 specifies two conditions which a Service Provider needs to meet to be allowed to operate on the Mobile Network: @@ -60,21 +60,21 @@ Once voted in as a Service Provider, the operation of Helium Mobile on the Mobil ### Data Reward Limits for Hotspot Owners and Gaming Prevention for Unlimited Plans -Helium Mobile specifically plans to launch an Unlimited Plan offering to the market as part of its line-up and is faced with solving a potential gaming problem. Helium Mobile rewards Hotspots for data on a per GB basis. This creates a potential gaming loophole whereby a person can purchase an unlimited plan for a fixed price and then stream movies and shows from a streaming service 24/7 through their own hotspots to rake up massive rewards. +Helium Mobile specifically plans to launch an Unlimited Plan offering to the market as part of its line-up and is faced with solving a potential gaming problem. Helium Mobile rewards Hotspots for data on a per GB basis. This creates a potential gaming loophole whereby a person can purchase an unlimited plan for a fixed price and then stream movies and shows from a streaming service 24/7 through their own hotspots to rake up massive rewards. We propose a basic anti-gaming mechanism for unlimited plans that is Helium Mobile-specific. This means that other carriers planning to join the Helium Mobile Network can propose their own algorithms or none. -For Helium Mobile unlimited plans we propose to set the limit on rewardable data that each Subscriber can send to the Helium MOBILE subDAO during the 30-day billing cycle. We propose that this limit is expressed in terms of gigabytes and equal to $COST_of_Subscription / $0.50 (price per GB set by MOBILE subDAO). For instance, if a subscriber purchases a Helium Mobile unlimited subscription for $20, the maximum number of rewardable gigabytes to be sent to the Helium network is $20/$0.50 = 40. 40 Gb will be the rewardable limit to the network for this subscriber. As such, the total value of MOBILE rewards received by all hotspots for servicing any unique unlimited plan cannot exceed the price for which the plan was purchased; thus decreasing the incentive to game. +For Helium Mobile unlimited plans we propose to set the limit on rewardable data that each Subscriber can send to the Helium MOBILE subDAO during the 30-day billing cycle. We propose that this limit is expressed in terms of gigabytes and equal to $COST_of_Subscription / $0.50 (price per GB set by MOBILE subDAO). For instance, if a subscriber purchases a Helium Mobile unlimited subscription for $20, the maximum number of rewardable gigabytes to be sent to the Helium network is $20/$0.50 = 40. 40 Gb will be the rewardable limit to the network for this subscriber. As such, the total value of MOBILE rewards received by all hotspots for servicing any unique unlimited plan cannot exceed the price for which the plan was purchased; thus decreasing the incentive to game. The rewardable limit will reset at the start of a new 30-day billing cycle for each Subscriber with an unlimited data plan. The data traffic cap is not limited to a particular Hotspot. It is applicable to all Hotspots that provide data for a specific Subscriber. It’s important to note that Helium Mobile offers an unlimited plan without data caps for Subscribers. This means that the data offloading will still continue after the maximal rewardable limit is reached, however Hotspot Owners won’t earn MOBILE rewards for providing data traffic to such Subscribers. Additionally, DCs won’t be burned from the Helium Mobile Carrier account for the data traffic routing after the data caps are reached for Subscribers. -Additionally, we propose a 6 calendar month grace period to allow for unrewarded traffic over rewardable limit on the Hotspots. Nova Labs will implement an option to opt-in for unrewarded data traffic in a Cloud Dashboard or similar tool no later than the expiration of the grace period. 6 month countdown will start on the day this HIP is approved. The default setting will be for radios to opt-out of allowing unrewarded traffic; it will require operators to manually opt-in before unrewarded traffic can be transferred on their radios. +Additionally, we propose a 6 calendar month grace period to allow for unrewarded traffic over rewardable limit on the Hotspots. Nova Labs will implement an option to opt-in for unrewarded data traffic in a Cloud Dashboard or similar tool no later than the expiration of the grace period. 6 month countdown will start on the day this HIP is approved. The default setting will be for radios to opt-out of allowing unrewarded traffic; it will require operators to manually opt-in before unrewarded traffic can be transferred on their radios. If Nova Labs fails to implement the opt-in feature past the expiration of the grace period, the reward cap is to be completely removed on the day of the expiration of the grace period and will remain so until Nova Labs has implemented the opt-in feature. -Helium Mobile shall provide a subscriber usage report to the MOBILE subDAO on a minimum of a yearly basis, on the 1st of August, if not on a continual basis, such as a dashboard. The report will present information about how much data traffic has been transferred; indicating the amount of rewarded traffic and unrewarded traffic by subscriber plan. +Helium Mobile shall provide a subscriber usage report to the MOBILE subDAO on a minimum of a yearly basis, on the 1st of August, if not on a continual basis, such as a dashboard. The report will present information about how much data traffic has been transferred; indicating the amount of rewarded traffic and unrewarded traffic by subscriber plan. Approval of this approach is necessary for Helium Mobile to start offloading data to the Helium Mobile Network. diff --git a/0083-restore-first-to-witness.md b/0083-restore-first-to-witness.md index d43e169f0..279203e9b 100644 --- a/0083-restore-first-to-witness.md +++ b/0083-restore-first-to-witness.md @@ -67,7 +67,7 @@ The most crucial reason for proposing rewarding the first witnesses to respond a - Which hotspots are faster than others, and which hotspots are slower. -With the help of [HeliumGeek](https://heliumgeek.com/) a tool has been created to visualize what the proposed change means for individual hotspots. +With the help of [HeliumGeek](https://heliumgeek.com/) a tool has been created to visualize what the proposed change means for individual hotspots. [HeliumGeek HIP 83 tool](https://heliumgeek.com/maps/hip83.html). diff --git a/0084-service-provider-hex-boosting.md b/0084-service-provider-hex-boosting.md index da0c97aa7..bf08fd8df 100644 --- a/0084-service-provider-hex-boosting.md +++ b/0084-service-provider-hex-boosting.md @@ -49,7 +49,7 @@ Network Subscribers: More coverage will be available to new and existing users o - Once a Service Provider burns MOBILE into a hex, it remains “boosted” indefinitely until some coverage is created in the hex location. - Creation of coverage will be considered to have been confirmed when at least three unique phones with discovery mapping enabled have successfully connected and passed at least 1MB of data at the location of coverage (as evidenced by the Mobile Oracle). - We propose the price for boosting one res12 hex for one month by 1x be initially set at $.005. This would roughly mean that boosting an area covered by a 436h (assuming it covers 500 res12 hexes) for six months to a 10x multiplier would cost $150. -**- The above number can be adjusted by the subDAO community vote down the line.** + **- The above number can be adjusted by the subDAO community vote down the line.** ## Drawbacks diff --git a/0085-mobile-hex-coverage-limit.md b/0085-mobile-hex-coverage-limit.md index 96dfea724..a1a828afc 100644 --- a/0085-mobile-hex-coverage-limit.md +++ b/0085-mobile-hex-coverage-limit.md @@ -8,55 +8,58 @@ - Voting Requirements: veMOBILE ## Summary: + This Helium Improvement Proposal (HIP) suggests adding a baseline hex multiplier score to the MOBILE Proof-of-Coverage (PoC) Modeled Coverage Points based on whether other coverage from Helium 5G deployments exists within that res12 hex. This HIP only applies to outdoor radios, and no changes to the reward structure of indoor mobile radios are being made with this HIP. ## Motivation: -The Helium Community passed [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) to incorporate obstruction data and radio signal power into the PoC reward model; however, it weighed all coverage within each res12 hex equally, even if multiple radios already provided coverage within that res12 hex. This means deployers could point five (5) outdoor radios in the same direction and still be awarded total Modeled Coverage points for each res12 hex. This results in the dilution of MOBILE and reduced MOBILE rewards to deployments that are strategically placed to minimize overlap in coverage. -This proposal aims to improve the value of Mobile network coverage by incentivizing users to deploy radios that minimize overlapping coverage and encourage deployments in new areas. +The Helium Community passed [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) to incorporate obstruction data and radio signal power into the PoC reward model; however, it weighed all coverage within each res12 hex equally, even if multiple radios already provided coverage within that res12 hex. This means deployers could point five (5) outdoor radios in the same direction and still be awarded total Modeled Coverage points for each res12 hex. This results in the dilution of MOBILE and reduced MOBILE rewards to deployments that are strategically placed to minimize overlap in coverage. + +This proposal aims to improve the value of Mobile network coverage by incentivizing users to deploy radios that minimize overlapping coverage and encourage deployments in new areas. ## Stakeholders: -All Mobile Radio Deployers / Mobile Hotspot Owners. - + +All Mobile Radio Deployers / Mobile Hotspot Owners. + ## Detailed Explanation: -Currently, any redundant and overlapping network coverage is still rewarded the same as non-overlapping coverage under HIP 74. This discourages the buildout of coverage to new areas. To prevent overcrowding and overlapping of coverage in hexes, this HIP proposes to limit the amount of modeled coverage points radios receive for redundant coverage in res12 hexes. -To ensure that only the best setups are rewarded, only the top three (3) ranked radio signals in each res12 hex will be awarded modeled coverage points, with a decaying multiplier based on the radio rank noted below. Any radios not ranked within the top three (3) will be ranked as “Fail”, and receive no modeled coverage points for that res12 hex. +Currently, any redundant and overlapping network coverage is still rewarded the same as non-overlapping coverage under HIP 74. This discourages the buildout of coverage to new areas. To prevent overcrowding and overlapping of coverage in hexes, this HIP proposes to limit the amount of modeled coverage points radios receive for redundant coverage in res12 hexes. -| Rank |Multiplier| -|--------------|----------| -| 1 | 1X | -| 2 | .75X | -| 3 | .25X | -| Fail | 0X | +To ensure that only the best setups are rewarded, only the top three (3) ranked radio signals in each res12 hex will be awarded modeled coverage points, with a decaying multiplier based on the radio rank noted below. Any radios not ranked within the top three (3) will be ranked as “Fail”, and receive no modeled coverage points for that res12 hex. -Please note that the multiplier table above only affects the modeled coverage points that are given to each outdoor radio and does not affect rewards distributed for the transfer of data or PoC rewards for indoor radios. +| Rank | Multiplier | +| ---- | ---------- | +| 1 | 1X | +| 2 | .75X | +| 3 | .25X | +| Fail | 0X | + +Please note that the multiplier table above only affects the modeled coverage points that are given to each outdoor radio and does not affect rewards distributed for the transfer of data or PoC rewards for indoor radios. ### Radio Ranking & Criteria All outdoor radios that provide coverage to any res12 hex will be given a rank for each res12 hex they provide coverage in based on the following potential attributes (note, this rank is only for a single res12 hex and not the entire radio): -- Modeled Signal Strength - +- Modeled Signal Strength - Coverage Claim Time (Only used as a tiebreaker for Modeled Single Strenght) If there are more than 1 Radio with the same signal strength level, use the `coverage_claim_time` value to rank the top 3 oldest installations where `coverage_claim_time` is the timestamp when the Radio received the spectrum access grant for the first time. The oldest Radio will receive the higher rank, while newest radio will receive the lowest rank. To prevent rewarding "dead" Radios, we propose to reset `coverage_claim_time` if the Radio was not generating a Heartbeat for more than 72 hours and use the time of the last Heartbeat as the new `coverage_claim_time`. - ### Modeling Radio Ranking See the example below of how ranking based on a hex multiplier would affect deployment of five (5) outdoor radios if they are providing modeled coverage to the same res12 hex: -| Radio |Signal Strength| Coverage Claim Start Date | Rank | Coverage Points Per HIP 74| New Coverage Points| -|-------|---------------|-----------------------------|-------|---------------------------|--------------------| -| A | -77.33 dBm |05/01/2023 23:24:25 | 1 | 16 (16 * 1) | 16 (16 * 1) | -| B | -88.75 dBm |12/01/2022 01:01:01 | 2 | 16 (16 * 1) | 12 (16 * .75) | -| C | -88.75 dBm |12/02/2022 12:11:01 | 3 | 16 (16 * 1) | 4 (16 * .25) | -| D | -93.60 dBm |12/05/2022 11:51:01 | Fail | 16 (16 * 1) | 0 (16 * 0) | -| E | -94.69 dBm |08/01/2022 05:01:59 | Fail | 16 (16 * 1) | 0 (16 * 0) | +| Radio | Signal Strength | Coverage Claim Start Date | Rank | Coverage Points Per HIP 74 | New Coverage Points | +| ----- | --------------- | ------------------------- | ---- | -------------------------- | ------------------- | +| A | -77.33 dBm | 05/01/2023 23:24:25 | 1 | 16 (16 \* 1) | 16 (16 \* 1) | +| B | -88.75 dBm | 12/01/2022 01:01:01 | 2 | 16 (16 \* 1) | 12 (16 \* .75) | +| C | -88.75 dBm | 12/02/2022 12:11:01 | 3 | 16 (16 \* 1) | 4 (16 \* .25) | +| D | -93.60 dBm | 12/05/2022 11:51:01 | Fail | 16 (16 \* 1) | 0 (16 \* 0) | +| E | -94.69 dBm | 08/01/2022 05:01:59 | Fail | 16 (16 \* 1) | 0 (16 \* 0) | **Table Key:** + - **Radio:** Example radio name. - **Signal Strength:** The Signal Strength of the res12 hex from the modeled coverage explorer. - **Coverage Claim:** The date/time that the Coverage Claim period started. @@ -68,15 +71,15 @@ See the example below of how ranking based on a hex multiplier would affect depl Since Radio A has the highest signal strength in that hex, it will be ranked as "1", and granted a 1X multiplier to the modeled coverage score of 16, which will award it with the full 16 (16 x 1) modeled coverage points for that epoch. - -Since radios B and C tied in Signal Strength, the Coverage Claim date is used to determine which radio is ranked next. For this example, radio B had its Coverage Claim date start on 12/01/2022 01:01:01 while radio C had a its Coverage Claim date starts on 12/02/2022 12:11:01. Therefore, since radio B has an earlier Coverage Claim date, it will be ranked "2", while radio C having a rank of "3". +Since radios B and C tied in Signal Strength, the Coverage Claim date is used to determine which radio is ranked next. For this example, radio B had its Coverage Claim date start on 12/01/2022 01:01:01 while radio C had a its Coverage Claim date starts on 12/02/2022 12:11:01. Therefore, since radio B has an earlier Coverage Claim date, it will be ranked "2", while radio C having a rank of "3". Since radios D and E had the lowest signal strength out of all five (5) radios, and only the top three (3) radios will earn PoC rewards, radios D and E will not earn any modeled coverage points for this res12 hex, and are ranked as "Fail". -As noted in the example above, outdoor radio deployers will now need to be cognizant of where they are placing their radios in order to maximize modeled coverage point. +As noted in the example above, outdoor radio deployers will now need to be cognizant of where they are placing their radios in order to maximize modeled coverage point. ### Changes to Multipliers and Ranks -As the MOBILE network matures, these multiplier scores may need to be fine tuned or changed. Therefore, the multipliers and ranks presented in this HIP shall be implemented as chain variables. In order for these chain variables to be modified, or deleted, one of two things must happen: + +As the MOBILE network matures, these multiplier scores may need to be fine tuned or changed. Therefore, the multipliers and ranks presented in this HIP shall be implemented as chain variables. In order for these chain variables to be modified, or deleted, one of two things must happen: 1. A new HIP is proposed modifying the multipliers and or ranks; or 2. A Governance or Working Group (herewithin reffered to as "the group") for the MOBILE Network must create a MOBILE PoC Change Proposal. The proposal will then be discussed by the group, in which a general consensus must be reached (consensus defined by the group). Once consensus is reached, the proposal will be put to a vote by the community, with the voting requirement being veMOBILE. @@ -86,28 +89,34 @@ The proposal must be announced within the Official Helium Community Discord Serv A new vote with the same or modified change(s) to that multiplier and or rank may be put to vote by the community again with the groups consensus no earlier than 60 calendar days after the last voting has ended. ## Drawbacks: + Implementing this proposal could increase the complexity of modeled coverage scores due to adding additional variables used to calculate total MOBILE rewards. Additionally, radio deployers may lose out on awarded coverage points in instances where multiple radios are set up in the same hex. ## Rationale and Alternatives: -An alternative would be allowing radios and hexes to keep earning the defined amount of modeled coverage points as described in HIP 74. -However, this may prevent or stagnate the network's growth because HIP 74 does not incentivize deployment of Hotspots to minimize overlapping coverage. +An alternative would be allowing radios and hexes to keep earning the defined amount of modeled coverage points as described in HIP 74. + +However, this may prevent or stagnate the network's growth because HIP 74 does not incentivize deployment of Hotspots to minimize overlapping coverage. ## Unresolved Question: + None ## Deployment Impact: -HIP 85 affects only Outdoor radios, and coverage from indoor radios will continue to earn Modeled Coverage Points based on HIP 74. + +HIP 85 affects only Outdoor radios, and coverage from indoor radios will continue to earn Modeled Coverage Points based on HIP 74. Nova Labs will need to add new fields into the Modeled Coverage Explorer to make Radio Hex Ranks and Coverage Claim date visible. -Further, a large amount of overlapping coverage exists within the MOBILE network. Deployers may have to find new locations for some or all of their radios in order for them to continue to earn modeled coverage points. +Further, a large amount of overlapping coverage exists within the MOBILE network. Deployers may have to find new locations for some or all of their radios in order for them to continue to earn modeled coverage points. This HIP leaves the implementation open to interpretation by Helium Core Developers who will implement this change on behalf of the community. -## Success Metrics: +## Success Metrics: + This HIP is successful if: -1. There is more broad coverage extended to new locations on the modeled coverage map + +1. There is more broad coverage extended to new locations on the modeled coverage map 2. and less redundant coverage in areas of saturation diff --git a/0086-increase-iot-data-transfer-cost.md b/0086-increase-iot-data-transfer-cost.md index 87ee6b2b0..213a5913f 100644 --- a/0086-increase-iot-data-transfer-cost.md +++ b/0086-increase-iot-data-transfer-cost.md @@ -1,4 +1,5 @@ # HIP 86: Increase IOT Data Transfer Cost + - Author(s): [@KeithRettig](https://github.com/KeithRettig) - Start Date: 2023-05-28 - Category: Economic @@ -7,31 +8,40 @@ - Voting Requirements: veIOT Holders ## Summary + This HIP proposes to change the per packet cost of transferring messages on the Helium IOT Network from 1 data credit (DC) per 24-byte packet to 2 data credits (DC) per 24-byte packet to better align the price with its value to our customers. ## Motivation -The primary motivation is to align the cost of packet transfer closer to the true value of packet transfer within the IOT subDAO. While it is believed by the author that the true value of packet transfer is closer to 100 DC, it would be economically unfeasible to implement a 100-fold increase in the price in one action. + +The primary motivation is to align the cost of packet transfer closer to the true value of packet transfer within the IOT subDAO. While it is believed by the author that the true value of packet transfer is closer to 100 DC, it would be economically unfeasible to implement a 100-fold increase in the price in one action. ## Stakeholders + Any and all customers (e.g., sensor owners), hosts, and operators of the Helium IOT Network. ## Detailed Explanation -The cost of packet transfer on the Helium IOT Network, is far too inexpensive. Our customers have publicly commented that the cost is too low. Due to the low cost of data transfer, a Hotspot must transfer a huge number of packets to earn meaningful revenue. The cost of packet transfer is so cheap, that this proposed change of doubling the cost is unlikely to change any behaviors of the users of the Helium IOT Network. -Currently to transfer a 24 byte packet on the Helium IOT Network, a customer must spend 1 DC. This HIP proposes to make that cost be 2 DC per 24 byte packet. This HIP does not change any mechanism on how Hotspots are paid for data transfer; if the HIP passes, a Hotspot will now earn 2 DC for each message transferred. +The cost of packet transfer on the Helium IOT Network, is far too inexpensive. Our customers have publicly commented that the cost is too low. Due to the low cost of data transfer, a Hotspot must transfer a huge number of packets to earn meaningful revenue. The cost of packet transfer is so cheap, that this proposed change of doubling the cost is unlikely to change any behaviors of the users of the Helium IOT Network. + +Currently to transfer a 24 byte packet on the Helium IOT Network, a customer must spend 1 DC. This HIP proposes to make that cost be 2 DC per 24 byte packet. This HIP does not change any mechanism on how Hotspots are paid for data transfer; if the HIP passes, a Hotspot will now earn 2 DC for each message transferred. ## Implementation -We leave the implementation of the smart contract components, verifiability, and compliance up to the Helium Core Developers to determine. It is understood that the cost function of packet transfer is implemented as a variable and thus it is believed this change should be very easy to implement in the IOT Packet Verifier. It would be ideal if the proposed increase could be appropriately scaled based on region, and thus allow for regional governance to define said increase. For instance, the community may decide to raise the price of data transfer in regions where backhaul costs are more expensive. Or they may allow a country to delay the price increase to help adoption of the service. However, since there are currently no known mechanisms for such regional policy actions, implementing such scaling will need to be left as a future feature. Therefore, regional pricing is out of scope of this HIP but is mentioned so that the developers will consider the possibilities as they code for this HIP (if there is any coding necessary). + +We leave the implementation of the smart contract components, verifiability, and compliance up to the Helium Core Developers to determine. It is understood that the cost function of packet transfer is implemented as a variable and thus it is believed this change should be very easy to implement in the IOT Packet Verifier. It would be ideal if the proposed increase could be appropriately scaled based on region, and thus allow for regional governance to define said increase. For instance, the community may decide to raise the price of data transfer in regions where backhaul costs are more expensive. Or they may allow a country to delay the price increase to help adoption of the service. However, since there are currently no known mechanisms for such regional policy actions, implementing such scaling will need to be left as a future feature. Therefore, regional pricing is out of scope of this HIP but is mentioned so that the developers will consider the possibilities as they code for this HIP (if there is any coding necessary). ## Drawbacks -A potential drawback is that customers will view the doubling of cost as too aggressive and not transfer as many packets in the future. It is believed that at this time, and with the current price range, the usage of packet transfer is one of relatively inelastic demand. No change in purchasing nor usage behavior is expected. -Since Data Credits are distributed to wallets first, there will be a reduction in available tokens for Proof-of-Coverage rewards. With only a doubling of the cost at this point, it is unlikely to be a significant reduction. However, some thought should be given as to this when future increases in the cost are considered. + +A potential drawback is that customers will view the doubling of cost as too aggressive and not transfer as many packets in the future. It is believed that at this time, and with the current price range, the usage of packet transfer is one of relatively inelastic demand. No change in purchasing nor usage behavior is expected. +Since Data Credits are distributed to wallets first, there will be a reduction in available tokens for Proof-of-Coverage rewards. With only a doubling of the cost at this point, it is unlikely to be a significant reduction. However, some thought should be given as to this when future increases in the cost are considered. ## Unresolved Questions + There are no unresolved questions other than how our customers will respond to the price change. ## Deployment Impact -There are no known dependencies by the author. As soon as the variable has been changed, customers would pay 2 DC to transfer data rather than 1 DC. + +There are no known dependencies by the author. As soon as the variable has been changed, customers would pay 2 DC to transfer data rather than 1 DC. ## Success Metrics -There are two success metrics. First that the price is changed and, second, that the demand remains inelastic. Only the first is required for the HIP to be considered successful. + +There are two success metrics. First that the price is changed and, second, that the demand remains inelastic. Only the first is required for the HIP to be considered successful. diff --git a/0087-proportional-service-provider-rewards.md b/0087-proportional-service-provider-rewards.md index 1efaa2b30..99ac5b3e4 100644 --- a/0087-proportional-service-provider-rewards.md +++ b/0087-proportional-service-provider-rewards.md @@ -1,4 +1,5 @@ # HIP 87: Proportional Service Provider Rewards + - Author(s): [@KeithRettig](https://github.com/KeithRettig), [@zer0tweets](https://github.com/zer0tweets), [@meowshka](https://github.com/meowshka) - Start Date: 2023-05-15 - Category: Economic, Technical @@ -7,58 +8,66 @@ - Voting Requirements: veMOBILE Holders ## Summary -This HIP proposes to make specific how Service Providers are eligible for rewards from the HIP-53 specified Service Provider MOBILE Reward bucket. The proposal suggests a usage-based approach to calculate rewards for Service Providers based on the amount of Data Credits burned. Service Providers would be rewarded in MOBILE tokens at a 1:1 ratio for the burned Data Credits with proportional distribution if the total exceeds the reward bucket value. + +This HIP proposes to make specific how Service Providers are eligible for rewards from the HIP-53 specified Service Provider MOBILE Reward bucket. The proposal suggests a usage-based approach to calculate rewards for Service Providers based on the amount of Data Credits burned. Service Providers would be rewarded in MOBILE tokens at a 1:1 ratio for the burned Data Credits with proportional distribution if the total exceeds the reward bucket value. ## Motivation -The primary motivation is clarify how Service Provider Rewards are calculated. There is also a motivation to prevent a scenario in which a Service Provider is rewarded the full MOBILE reward bucket while burning little to no Data Credits. The content of this HIP was originally written within HIP-82. However, since the concept applies to all Service Providers in the Helium 5G Network and not to the specific Service Provider of HIP-82, it is more appropriate to have this as its own HIP. + +The primary motivation is clarify how Service Provider Rewards are calculated. There is also a motivation to prevent a scenario in which a Service Provider is rewarded the full MOBILE reward bucket while burning little to no Data Credits. The content of this HIP was originally written within HIP-82. However, since the concept applies to all Service Providers in the Helium 5G Network and not to the specific Service Provider of HIP-82, it is more appropriate to have this as its own HIP. ## Stakeholders + Any and all Service Providers of the Helium MOBILE Network. ## Detailed Explanation + HIP-53 specifies an overall rewards bucket for Service Providers but does not go into specifics of how rewards should be calculated based on the amount of data being offloaded. To prevent a scenario in which a Service Provider is rewarded the full MOBILE Service Provider Reward Bucket while burning little to no Data Credits (DC), we propose to follow a similar usage-based approach as outlined in HIP-10 for the IoT Network. -We propose that Service Providers are rewarded up to 1:1 in MOBILE tokens for the amount of DC burned during a reward period, similar to the approach in HIP-10. If the Service Providers collectively burn more DC than the equivalent amount of MOBILE tokens in the Service Provider reward bucket, each Service Provider will be rewarded proportionally to its share of DC burn. If the Service Providers collectively burn less DC than the equivalent amount of MOBILE tokens, the remainder of the Service Provider bucket will not be minted. +We propose that Service Providers are rewarded up to 1:1 in MOBILE tokens for the amount of DC burned during a reward period, similar to the approach in HIP-10. If the Service Providers collectively burn more DC than the equivalent amount of MOBILE tokens in the Service Provider reward bucket, each Service Provider will be rewarded proportionally to its share of DC burn. If the Service Providers collectively burn less DC than the equivalent amount of MOBILE tokens, the remainder of the Service Provider bucket will not be minted. To illustrate, here are two scenarios where the value of DC burned is **less than or exceeds** the rewards bucket: 1. Value of DCs burned for data traffic **is less than** the Service Provider Reward Bucket (10% of MOBILE emissions): -|Item|Rewards| -|:----------------------|---------:| -|DCs burned by SP|100,000,000| -|Price of DC|$0.00001| -|Price of MOBILE*|$0.0001| -|DCs burned in MOBILE**|10,000,000| -|10% SP bucket|500,000,000 MOBILE| -|SP rewards|10,000,000 MOBILE| +| Item | Rewards | +| :----------------------- | -----------------: | +| DCs burned by SP | 100,000,000 | +| Price of DC | $0.00001 | +| Price of MOBILE\* | $0.0001 | +| DCs burned in MOBILE\*\* | 10,000,000 | +| 10% SP bucket | 500,000,000 MOBILE | +| SP rewards | 10,000,000 MOBILE | 2. Value of DCs burned for data traffic **exceeds** the Service Provider Reward Bucket (10% of MOBILE emissions): -|Item|Rewards| -|:----------------------|---------:| -|DCs burned by SP|100,000,000,000| -|Price of DC|$0.00001| -|Price of MOBILE*|$0.0001| -|DCs burned in MOBILE**|10,000,000,000| -|10% SP bucket|500,000,000 MOBILE| -|SP rewards|500,000,000 MOBILE| +| Item | Rewards | +| :----------------------- | -----------------: | +| DCs burned by SP | 100,000,000,000 | +| Price of DC | $0.00001 | +| Price of MOBILE\* | $0.0001 | +| DCs burned in MOBILE\*\* | 10,000,000,000 | +| 10% SP bucket | 500,000,000 MOBILE | +| SP rewards | 500,000,000 MOBILE | -\* The price chosen is an example, not the actual price. The actual price will be determined by the Price Oracle on the Solana blockchain during the rewards calculation time. -\** Amount of MOBILE tokens with the same value as the value of the DCs burned by SP: (10,000 DC * $0.00001 (fixed price of DC) / $0.0001 (example price of MOBILE)) +\* The price chosen is an example, not the actual price. The actual price will be determined by the Price Oracle on the Solana blockchain during the rewards calculation time. \*_ Amount of MOBILE tokens with the same value as the value of the DCs burned by SP: (10,000 DC _ $0.00001 (fixed price of DC) / $0.0001 (example price of MOBILE)) While approval of this approach is not necessary for Helium Mobile to start offloading data to the Helium Mobile Network, it does modify a policy that is important to Helium Mobile as it determines the amount of its expected rewards from the MOBILE Service Provider Reward Bucket. ## Implementation + We leave the implementation of the smart contract components, verifiability, and Service Provider compliance up to the Helium Core Developers to determine. ## Drawbacks + As Helium 5G Network's first and only Service Provider, Helium Mobile, suggested the ideas within this HIP, there are no perceived drawbacks; there are no other Service Providers to be affected by this HIP. ## Dependencies -Nova Labs has done most of the work necessary to launch the Helium Mobile carrier on the data offloading, customer tooling, and support flows side. Launch of staking, Hotspot rewards, and other blockchain related functionality is dependent on the successful implementation of these features by Helium Core Developers. + +Nova Labs has done most of the work necessary to launch the Helium Mobile carrier on the data offloading, customer tooling, and support flows side. Launch of staking, Hotspot rewards, and other blockchain related functionality is dependent on the successful implementation of these features by Helium Core Developers. ## Deployment Impact + Service Providers will be able to offload data traffic to the Helium Mobile Network and receive Service Provider rewards. ## Success Metrics + The main success metric would be Service Providers receiving their proportionate rewards from the MOBILE Reward bucket. diff --git a/0088-adjustment-of-dao-utility-a-score.md b/0088-adjustment-of-dao-utility-a-score.md index d27744b1f..ef5027d6e 100644 --- a/0088-adjustment-of-dao-utility-a-score.md +++ b/0088-adjustment-of-dao-utility-a-score.md @@ -1,4 +1,5 @@ # HIP 88: Adjustment of DAO Utility A Score + - Authors: [Gateholder](https://github.com/gateholder), [Andy Zyvoloski](https://github.com/heatedlime), [Groot](https://github.com/mawdegroot) - Start Date: 2023-06-15 - Category: Technical & Economic @@ -7,9 +8,11 @@ - Voting Requirements: veHNT ## Summary + This HIP proposes to make the $A$ factor of the subDAO utility score more granular by using the individual onboarding fee of an active device paid instead of relying on a homogeneous onboarding fee. This will allow subDAOs to change their onboarding fee without either negatively affecting their subDAO utility score. ## Motivation + The current definition of the subDAO utility score as specified in HIP51 is shown below. The definition does not allow the changing of the onboarding fee without significantly affecting the $A$ factor of the score. The community has expressed the preference to change the onboarding fee; however, lowering the onboarding fee will significantly lower the subDAO utility score and thus subDAOs are disincentivized to do so. At the same time, increasing the onboarding fee will artificially inflate the subDAO utility score, an offense punishable by slashing as written in HIP51. This HIP proposes to change the $A$ score to align with the original intention of HIP51 while still allowing a subDAO to change their onboarding fee via their internal governance. $\text{DAO Utility Score} = V \times D \times A$ @@ -27,6 +30,7 @@ $A = \text{max}(1, \sqrt[4]{\text{DNP Active Device Count} \times \text{DNP Devi This change will impact the entire ecosystem as it alters the interpretation of the HIP51 subDAO utility score that is directly responsible for the distribution of HNT between subDAOs. ## Detailed Explanation + This HIP proposes to change the $A$ factor to only count the onboarding fees paid by each active device. The $A$ factor will _only_ take into account fees paid in DC. If a device has paid 40 USD but the current onboarding fee is 10 USD the device will still be counted as 40 USD Conversely a device that has paid 10 USD while the current onboarding fee is 40 USD will still be counted as 10 USD. This change will allow subDAOs to change their onboarding factor without affecting the $A$ factor of subDAO utility score that it had been awarded for previous onboarding fees. An active device is any rewardable entity that has been onboarded and has received rewards in the past 30 days. This definition of what an _active device_ entails allows any subDAO to use their own definition of _device_ without requiring Helium DAO oversight. The use of the actual onboarding fee that was paid for a device removes the ability to onboard devices for a low onboarding fee and later game the subDAO utility score by increasing the onboarding fee for new devices. @@ -50,14 +54,17 @@ Example 3: subDAO C has opted not to pay any onboarding fees and have 100k activ $A_{\text{C}} = max\left(1, \sqrt[4]{\sum_{k \in \mathcal{K_\text{C}}}A_{\text{C}}(k)}\right) = max\left(1, \sqrt[4]{100 000 \cdot 0}\right) = max\left(1, \sqrt[4]{0}\right) = 1$ ## Drawbacks: + This HIP would negatively impact any subDAOs in which have not paid onboarding fees for each active device. ## Alternatives + There are two alternatives to this HIP, the first is leaving the $A$ factor as is; however, this would allow any subDAO to artificially set an onboard fee to increase their $A$ factor, without requiring them to retroactively pay any unpaid fees. The second is a major revamp of the subDAO utility score. A major revamp of the subDAO utility score takes months of discussion and modeling whereas several actors within the ecosystem have voiced their wish to change the onboarding fee sooner rather than later. Without this change the changing of a subDAOs onboarding fee is either artificially inflating the subDAO utility score (punishable by slashing) or very disincentivized by losing part of the $A$ factor. ## Deployment Impact + The implementation of the `active-devices` will have to be altered. The `active-devices` oracle uses a database in which it stores key metrics such as `lastReward` that it can use to correctly determine the number of active devices. The `distribution` oracle uses this information to distribute HNT to the treasuries of the different subDAOs. This proposal proposes to add paid onboarding fee to this database in order to provide the `distribution` oracle with the correct values to use for the $A$ factor of the subDAO utility score. It is also suggested that the [Helium Network Stats](https://explorer.helium.com/stats) webpage be updated after implementation to include the sum of onboard fees paid for all active devices within each subDAO. @@ -65,4 +72,5 @@ It is also suggested that the [Helium Network Stats](https://explorer.helium.com The specific implementation of the proposed changes will be determined by the Helium Core Developers while conforming to the intent of the proposal in the fullest extent possible. ## Success Metrics + This proposal is a success when the `distribution` and `active-devices` oracles can correctly determine the $A$ factor of the subDAO utility score based on the amount of active devices and the corresponding onboarding fee that was paid. As a consequence, this will allow the subDAOs to set the onboarding fee via their internal governance without requiring a veHNT vote. diff --git a/0089-mobile-network-onboard-fees.md b/0089-mobile-network-onboard-fees.md index 83de0d0b2..1ed8b3f0b 100644 --- a/0089-mobile-network-onboard-fees.md +++ b/0089-mobile-network-onboard-fees.md @@ -1,4 +1,5 @@ -# HIP 89: MOBILE Network Onboarding Fees +# HIP 89: MOBILE Network Onboarding Fees + - Authors: [Andy Zyvoloski](https://github.com/heatedlime), [Keith Rettig](https://github.com/keithrettig), [Max Gold](https://github.com/MaxGold91) - Start Date: 6/14/2023 - Category: Technical & Economic @@ -7,33 +8,41 @@ - Voting Requirements: veMOBILE ## Summary -This HIP requests that Helium Foundation correct the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD as soon as possible so that the fees are in compliance with HIP-53 and HIP-19. + +This HIP requests that Helium Foundation correct the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD as soon as possible so that the fees are in compliance with HIP-53 and HIP-19. ## Stakeholders -MOBILE Hotspots - All currently onboarded MOBILE Hotspot owners. -Approved MOBILE Hotspot Makers - The sub-group of Approved Hotspot Makers that manufacture omni-protocol Hotspots that utilize the MOBILE Network and the IOT Network. +MOBILE Hotspots - All currently onboarded MOBILE Hotspot owners. + +Approved MOBILE Hotspot Makers - The sub-group of Approved Hotspot Makers that manufacture omni-protocol Hotspots that utilize the MOBILE Network and the IOT Network. ## Motivation -Current MOBILE Hotspots, such as the FreedomFi Gateway and the Bobcat 500, are both omni-protocol Hotspots; that is, they contain both IOT and MOBILE network capabilities. HIP-53 ('Economics Overview' section) dictates that all Hotspots must pay an Onboarding Fee of 40 USD and a Location Assert Fee of 10 USD. [Helium Maker Ethics Documentation](https://docs.helium.com/hotspot-makers/maker-ethics/) Section 9 indicates that Approved Hotspot Makers are responsible for funding the onboarding server for their Hotspots. HIP-19 ('Issuing Keys & Paying Staking Fees' section) requires manufacturers to acquire codes to validate, onboard a Hotspot, and pay the 40 USD Staking Fee, also referred to as the Onboarding Fee. -At the time of onboarding these Hotspots, there was no MOBILE subDAO which to designate the MOBILE subDAO's 40 USD Onboarding Fee. As such, all MOBILE Hotspots were only onboarded to the IOT network with its associated Onboarding Fee of 40 USD and Location Assert Fee of 10 USD. At the time of the Solana migration in April of 2023, these Hotspots continued to be onboarded to the MOBILE network with an Onboarding Fee of 0 USD instead of 40 USD and Location Assert Fee of 0 USD instead of 10 USD, as the migration kept feature parity with the old chain. The discrepancy continues to this day. As a result, 0 USD in Onboarding Fees have been burned towards the MOBILE subDAO's $A$ Factor, which creates a negative impact in the $A$ Score of the DAO Utility Score established in HIP-51. +Current MOBILE Hotspots, such as the FreedomFi Gateway and the Bobcat 500, are both omni-protocol Hotspots; that is, they contain both IOT and MOBILE network capabilities. HIP-53 ('Economics Overview' section) dictates that all Hotspots must pay an Onboarding Fee of 40 USD and a Location Assert Fee of 10 USD. [Helium Maker Ethics Documentation](https://docs.helium.com/hotspot-makers/maker-ethics/) Section 9 indicates that Approved Hotspot Makers are responsible for funding the onboarding server for their Hotspots. HIP-19 ('Issuing Keys & Paying Staking Fees' section) requires manufacturers to acquire codes to validate, onboard a Hotspot, and pay the 40 USD Staking Fee, also referred to as the Onboarding Fee. + +At the time of onboarding these Hotspots, there was no MOBILE subDAO which to designate the MOBILE subDAO's 40 USD Onboarding Fee. As such, all MOBILE Hotspots were only onboarded to the IOT network with its associated Onboarding Fee of 40 USD and Location Assert Fee of 10 USD. At the time of the Solana migration in April of 2023, these Hotspots continued to be onboarded to the MOBILE network with an Onboarding Fee of 0 USD instead of 40 USD and Location Assert Fee of 0 USD instead of 10 USD, as the migration kept feature parity with the old chain. The discrepancy continues to this day. As a result, 0 USD in Onboarding Fees have been burned towards the MOBILE subDAO's $A$ Factor, which creates a negative impact in the $A$ Score of the DAO Utility Score established in HIP-51. ## Detailed Explanation -Unfortunately, the framework for the MOBILE subDAO was established after the passage of HIP-51; and as such, there was no MOBILE subDAO to apply the paid Onboarding Fees for MOBILE Hotspots. Until the MOBILE subDAO framework was created, the Onboarding Fees for omni-protocol Hotspots were applied to the IOT subDAO only. The correct action at the time of migration in April of 2023 would have been to set the MOBILE Onboarding Fee to the required 40 USD and the Location Assert Onboarding Fee to the required 10 USD, pay the onboarding server for all Hotspots to be onboarded, and burn the Onboarding Fee for each Hotspot as required by HIP-51 and HIP-19. -HIPs 51 through 53 provide for the Onboarding Server to be correctly paid with 100 USD worth of Data Credits for each Hotspot by the Approved Hotspot Makers such that it can pay for the IOT subDAO Onboarding Fee of 40 USD, the IOT subDAO Location Assert Fee of 10 USD, the MOBILE subDAO Onboarding Fee of 40 USD, and the MOBILE subDAO Location Assert Fee of 10 USD. Given that there is no Location Assert operation in the MOBILE subDAO, what to do with the excess funding (10 USD per Hotspot) presumed to be paid into each manufacturer's Maker Account for Location Asserts is outside of the scope of this HIP. +Unfortunately, the framework for the MOBILE subDAO was established after the passage of HIP-51; and as such, there was no MOBILE subDAO to apply the paid Onboarding Fees for MOBILE Hotspots. Until the MOBILE subDAO framework was created, the Onboarding Fees for omni-protocol Hotspots were applied to the IOT subDAO only. The correct action at the time of migration in April of 2023 would have been to set the MOBILE Onboarding Fee to the required 40 USD and the Location Assert Onboarding Fee to the required 10 USD, pay the onboarding server for all Hotspots to be onboarded, and burn the Onboarding Fee for each Hotspot as required by HIP-51 and HIP-19. + +HIPs 51 through 53 provide for the Onboarding Server to be correctly paid with 100 USD worth of Data Credits for each Hotspot by the Approved Hotspot Makers such that it can pay for the IOT subDAO Onboarding Fee of 40 USD, the IOT subDAO Location Assert Fee of 10 USD, the MOBILE subDAO Onboarding Fee of 40 USD, and the MOBILE subDAO Location Assert Fee of 10 USD. Given that there is no Location Assert operation in the MOBILE subDAO, what to do with the excess funding (10 USD per Hotspot) presumed to be paid into each manufacturer's Maker Account for Location Asserts is outside of the scope of this HIP. ### Technical Implementations -The correction is reportedly easy. As such, Helium Foundation has agreed to modify the Helium multisig for the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE subDAO Location Assert Fee from 0 USD to 10 USD upon passing of the HIP. The expected workload is to on the order of minutes and, therefore, should be able to be completed within the day. + +The correction is reportedly easy. As such, Helium Foundation has agreed to modify the Helium multisig for the MOBILE Onboarding Fee from 0 USD to 40 USD and the MOBILE subDAO Location Assert Fee from 0 USD to 10 USD upon passing of the HIP. The expected workload is to on the order of minutes and, therefore, should be able to be completed within the day. ## Drawbacks -The biggest potential drawback applies if HIP-88 is passed. If the DAO Utility Score is modified to redefine the $A$ Factor calculation to be the sum of all onboarding fees for active devices rather than a multiple of active devices and the set Onboarding Fee value, then it would seem required to ensure that the funds from the Maker Accounts be used to burn the unpaid fees to the MOBILE subDAO's $A$ Factor. The mechanism for how to do such a burn is outside of the scope of this HIP. -Another drawback is that since there are no Location Assert requirements for the MOBILE subDAO, there is no use to paying the Onboarding Server for any MOBILE subDAO Location Asserts as specified in HIP-51. A separate HIP should be created to set the MOBILE subDAO Location Assert Fee to 0 USD, no longer require the MOBILE subDAO Location Assert Fee to be funded into the maker account, and propose to allow any MOBILE subDAO Location Assert funds in the Maker's Accounts to be utilized for paying for MOBILE subDAO Onboarding Fees. +The biggest potential drawback applies if HIP-88 is passed. If the DAO Utility Score is modified to redefine the $A$ Factor calculation to be the sum of all onboarding fees for active devices rather than a multiple of active devices and the set Onboarding Fee value, then it would seem required to ensure that the funds from the Maker Accounts be used to burn the unpaid fees to the MOBILE subDAO's $A$ Factor. The mechanism for how to do such a burn is outside of the scope of this HIP. + +Another drawback is that since there are no Location Assert requirements for the MOBILE subDAO, there is no use to paying the Onboarding Server for any MOBILE subDAO Location Asserts as specified in HIP-51. A separate HIP should be created to set the MOBILE subDAO Location Assert Fee to 0 USD, no longer require the MOBILE subDAO Location Assert Fee to be funded into the maker account, and propose to allow any MOBILE subDAO Location Assert funds in the Maker's Accounts to be utilized for paying for MOBILE subDAO Onboarding Fees. ## Alternatives -One alternative is to change the way the $A$ score of the DAO Utility Score is calculated so as to negate the need for Onboarding Fees. Given the significance of modifying the Helium ecosystem's tokenomics, such an alternative would require a vote to be held at the Helium DAO level with veHNT. + +One alternative is to change the way the $A$ score of the DAO Utility Score is calculated so as to negate the need for Onboarding Fees. Given the significance of modifying the Helium ecosystem's tokenomics, such an alternative would require a vote to be held at the Helium DAO level with veHNT. ## Success Metrics -This HIP is successful when the MOBILE Onboarding Fee is changed from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD. Once completed, all multi-protocol MOBILE Hotspots will automatically be onboarded to the MOBILE subDAO and the IOT subDAO and their required fees for both subDAOs are paid via the onboarding server. + +This HIP is successful when the MOBILE Onboarding Fee is changed from 0 USD to 40 USD and the MOBILE Location Assert Fee from 0 USD to 10 USD. Once completed, all multi-protocol MOBILE Hotspots will automatically be onboarded to the MOBILE subDAO and the IOT subDAO and their required fees for both subDAOs are paid via the onboarding server. diff --git a/0090-reduce-iot-location-assert-cost-indefinitely.md b/0090-reduce-iot-location-assert-cost-indefinitely.md index 0326d5ec9..be47777ab 100644 --- a/0090-reduce-iot-location-assert-cost-indefinitely.md +++ b/0090-reduce-iot-location-assert-cost-indefinitely.md @@ -2,7 +2,7 @@ - Author(s): [@nosmaster89](https://github.com/nosmaster89) - Start Date: 2023-06-22 -- Category: Economic +- Category: Economic - Original HIP PR: [#722](https://github.com/helium/HIP/pull/722) - Tracking Issue: [#735](https://github.com/helium/HIP/issues/735) - Vote Requirements: veIOT Holders @@ -12,23 +12,26 @@ This HIP proposes an adjustment to the Hotspot location assertion fees on the network. Currently, as per [HIP-69](https://github.com/helium/HIP/blob/main/0069-reassertion-fee-reduction.md) and since the Solana migration, the fees for IOT hotspots were halved. However, this adjustment is set to expire on July 20th, 2023, UTC, after which the fee will increase back to $10 in Data Credits. This proposal suggests maintaining the reduced fee to encourage hotspot relocation and support future HIPs aiming to distribute hotspots in densely populated areas. ## Motivation + The key motivations behind this proposal are as follows: - Lowering the cost for hosts to relocate their hotspots going forward, facilitating better network coverage and decentralization. - Establishing a minimum fee that reflects the network's expectations for hotspot relocation, ensuring a longer-term commitment from hotspot owners. ## Stakeholders + IOT Hotspot Makers, who will not have to pay the increased 1M DC ($10) Location assert fee on the first location reassertions. IOT Hotspot owners, who will not have to pay the increased 1M DC ($10) Location assert fee on subsequent location reassertions. And this proposal impacts the entire network as it affects the amount of DC burned, which influences the economics of all networks. ## Detailed Explanation + The proposal aims to extend the duration of the reduced asset fees for hotspot relocation that HIP 69 introduced indefinitely. By maintaining the lowered fee, it becomes more attractive for hotspot owners to relocate their hotspots, increasing the likelihood of achieving better network coverage in various locations. Additionally, this change supports future HIPss that aim to distribute hotspots in densely populated areas. - ## Drawbacks + The primary drawback of this proposal is a lower overall DC burn for the network. However, this can be balanced by the potential benefits gained from increased hotspot relocation and improved network coverage. diff --git a/0091-data-driven-extension-reduced-iot-assertion-cost.md b/0091-data-driven-extension-reduced-iot-assertion-cost.md index 73ebc0a6c..0126d347c 100644 --- a/0091-data-driven-extension-reduced-iot-assertion-cost.md +++ b/0091-data-driven-extension-reduced-iot-assertion-cost.md @@ -2,7 +2,7 @@ - Author(s): [@maxgold91](https://github.com/maxgold91), [@bfgneil](https://github.com/bfgneil), [@mawdegroot](https://github.com/mawdegroot), Fizzy, [@AndrewsMD](https://github.com/andrewsMD) - Start Date: 2023-07-09 -- Category: Economic +- Category: Economic - Original HIP PR: [#738](https://github.com/helium/HIP/pull/738) - Tracking Issue: [#743](https://github.com/helium/HIP/issues/743) - Vote Requirements: veIOT Holders diff --git a/0093-addition-of-wifi-aps-to-mobile-subdao.md b/0093-addition-of-wifi-aps-to-mobile-subdao.md index 09a36a97e..65dd2782b 100644 --- a/0093-addition-of-wifi-aps-to-mobile-subdao.md +++ b/0093-addition-of-wifi-aps-to-mobile-subdao.md @@ -77,7 +77,7 @@ Indoor access points are devices that are usually not outdoor-rated and they are ##### 3.1.1.1 Onboarding Location Assertion -Indoor Wi-Fi access points are usually not equipped with a GPS receiver that can be used to establish the location of the access point. This is because GPS has poor outside-in RF penetration and, with the exception of the upcoming Wi-Fi6E protocol called Standard Power, Wi-Fi access points are not required to report their location. Conversely, CBRS radios must talk to a SAS before they can operate in the CBRS band. +Indoor Wi-Fi access points are usually not equipped with a GPS receiver that can be used to establish the location of the access point. This is because GPS has poor outside-in RF penetration and, with the exception of the upcoming Wi-Fi6E protocol called Standard Power, Wi-Fi access points are not required to report their location. Conversely, CBRS radios must talk to a SAS before they can operate in the CBRS band. In the case of indoor Wi-Fi access points, we are proposing an automatic self-assertion method where the access point owner will be required to be in close proximity to the Wi-Fi access point and to utilize an app in a mobile phone enabled with GPS assisted technology to onboard the Wi-Fi access point into the blockchain. @@ -95,7 +95,7 @@ After an initial assertion of the location during the onboarding using the app a There are multiple and possibly concurrent ways to implement subsequent location validation: -1. The network can leverage 3rd_party location services (e.g., Google Cloud Location Services, Skyhook, etc.) to estimate location based on Wi-Fi neighbor scans that will come directly from the access point and will be signed using secure mechanisms (e.g., TrustZone, disk encryption, etc.) as assumed in section 1.1. +1. The network can leverage 3rd_party location services (e.g., Google Cloud Location Services, Skyhook, etc.) to estimate location based on Wi-Fi neighbor scans that will come directly from the access point and will be signed using secure mechanisms (e.g., TrustZone, disk encryption, etc.) as assumed in section 1.1. 2. The network can implement algorithms that leverage inter-access point communication for the purpose of probing the RF environment and gathering statistics that can be used for detecting significant changes in the environment correlated to a change of location. #### 3.1.2 Modeled Coverage @@ -108,7 +108,7 @@ We are proposing a maximum of 1 Indoor Wi-Fi access point in one hex for the PoC ### 3.2 Outdoor Access Points -Outdoor access points are devices that are rated for operating in outdoor conditions with certain operating ranges (usually defined by IP65/IP67 ratings). They are either wall- or pole-mounted, deployed outside buildings or venues, stationary or semi-stationary within those facilities and provide Wi-Fi coverage to Subscribers. +Outdoor access points are devices that are rated for operating in outdoor conditions with certain operating ranges (usually defined by IP65/IP67 ratings). They are either wall- or pole-mounted, deployed outside buildings or venues, stationary or semi-stationary within those facilities and provide Wi-Fi coverage to Subscribers. #### 3.2.1 Onboarding Location Assertion and First Installation Setup @@ -189,21 +189,20 @@ Note that until mappers are launched, there will be only two possible trust scor Given the nature of 5GHz band propagation and the shared spectrum nature of the Wi-Fi standard, we are proposing calculating MOBILE rewards based on a table similar to that used in HIP74: -| | Tier 1 | Tier 2 | Tier 3 | Tier 4 | -| ----------------------------- | ---------------- | ----------------------------- | ---------------------------- | ------------------- | -| **Potential RSSI** | $RSSI > -65 dBm$ | $-65 dBm \ge RSSI > -75 dBm$ | $-75 dBm \ge RSSI > -85 dBm$ | $RSSI \le -85 dBm$ | -| **Potential Signal Level** | High | Medium | Low | None | -| **Estimated Coverage Points** | 16 | 8 | 4 | 0 | +| | Tier 1 | Tier 2 | Tier 3 | Tier 4 | +| ----------------------------- | ---------------- | ---------------------------- | ---------------------------- | ------------------ | +| **Potential RSSI** | $RSSI > -65 dBm$ | $-65 dBm \ge RSSI > -75 dBm$ | $-75 dBm \ge RSSI > -85 dBm$ | $RSSI \le -85 dBm$ | +| **Potential Signal Level** | High | Medium | Low | None | +| **Estimated Coverage Points** | 16 | 8 | 4 | 0 | **Table 1.** Potential received signal strength indicator (RSSI), corresponding signal level, and estimated coverage points for Outdoor Radios. - The actual number of earned coverage points will be calculated based on: 1. Modeled coverage, if obstruction and/or terrain data is available (similar to HIP74). In this case, the total amount of coverage points will be based on the model and will vary by location. -2. Templated coverage, if obstruction and/or terrain data is not available. Based on the template set forth in section 3.2.3.1, the total amount of coverage points assigned to a templated coverage would be 500 (i.e., 6 Hexes@Tier 1 - 21 Hexes@Tier 2 - 59 Hexes@Tier 3). +2. Templated coverage, if obstruction and/or terrain data is not available. Based on the template set forth in section 3.2.3.1, the total amount of coverage points assigned to a templated coverage would be 500 (i.e., 6 Hexes@Tier 1 - 21 Hexes@Tier 2 - 59 Hexes@Tier 3). The values of the location trust score multiplier for outdoor access points are as follows: @@ -220,14 +219,13 @@ Following the 40% scaling factor compared to CBRS that we are proposing in 3.4.1 For reference, the updated model radio rewards scaling will be: -| Device Type | Reward Weight | -| ------------------------ | :-----------: | -| High Power CBRS Outdoor | `4.000` | -| CBRS Outdoor | `2.500` | -| CBRS Indoor | `1.000` | -| Wi-Fi Outdoor | `1.000` | -| Wi-Fi Indoor | `0.400` | - +| Device Type | Reward Weight | +| ----------------------- | :-----------: | +| High Power CBRS Outdoor | `4.000` | +| CBRS Outdoor | `2.500` | +| CBRS Indoor | `1.000` | +| Wi-Fi Outdoor | `1.000` | +| Wi-Fi Indoor | `0.400` | Please also note that prior to HIP-74 launch the cap described 3.1.3 and 3.2.4 cannot be enforced because the establishment of seniority is part of the HIP-74 implementation. @@ -244,6 +242,7 @@ The alternative is to continue to rely on the addition of new CBRS radio deploym ## Unresolved Questions Wi-Fi devices are expected to retail for significantly less than CBRS, which makes the $40 onboarding fee currently adopted for CBRS radios prohibitively high. The onboarding fee will be defined by subsequent HIP, in absence of which the onboarding and location assertions fee will be set to $0. + ## Deployment Impact Many network components and third-party apps will need to be updated to support this HIP. This is not an exhaustive list but rather a minimum checklist that needs to be implemented: diff --git a/0094-response-time-windows-for-witness-rewarding.md b/0094-response-time-windows-for-witness-rewarding.md index ba8adf800..aed65950f 100644 --- a/0094-response-time-windows-for-witness-rewarding.md +++ b/0094-response-time-windows-for-witness-rewarding.md @@ -7,54 +7,55 @@ - Tracking issue: [#764](https://github.com/helium/HIP/issues/764) - Voting Requirements: veIOT Holders -# Summary +# Summary -Currently, the Proof-of-Coverage Oracles reward the 14 first hotspots (defined in *default_max_witnesses_per_poc* ) reporting a witness. This rewards the fastest hotspots, incentivizing fiber backhauls and specific hardware models that happen to be able to produce fast signatures. The result is that always the same hotspots are selected, making others not viable even if they provide unique and useful coverage for the network. In other words, it punishes hotspots for falling short of millisecond optimizations when the LoRaWAN protocol functions to the order of seconds - [see also](#rewarded-hotspots-for-witnesses). +Currently, the Proof-of-Coverage Oracles reward the 14 first hotspots (defined in _default_max_witnesses_per_poc_ ) reporting a witness. This rewards the fastest hotspots, incentivizing fiber backhauls and specific hardware models that happen to be able to produce fast signatures. The result is that always the same hotspots are selected, making others not viable even if they provide unique and useful coverage for the network. In other words, it punishes hotspots for falling short of millisecond optimizations when the LoRaWAN protocol functions to the order of seconds - [see also](#rewarded-hotspots-for-witnesses). But a hotspot’s utility in providing LoRaWAN coverage depends on having “good enough” response times, not on being amongst the absolute fastest as absolute speeds provide no marginal utility: the Uplink does not have a particular time-window, the Downlink time windows is up to 2 seconds, and the Join process up to 6 seconds. -We see a continuous decrease of the number of [hotspots not participating to PoC anymore](#network-hotspot-loss-acceleration) over time, 41K (10%) are not seen anymore since August 15th compared to July 1st. The situations that is excluding or unequally rewarding a hotspot, when providing a valuable coverage, does not help is stabilize the number of active hotspots over time. +We see a continuous decrease of the number of [hotspots not participating to PoC anymore](#network-hotspot-loss-acceleration) over time, 41K (10%) are not seen anymore since August 15th compared to July 1st. The situations that is excluding or unequally rewarding a hotspot, when providing a valuable coverage, does not help is stabilize the number of active hotspots over time. This HIP proposes to evolve the hotspot selection by adding a response time window + - to eliminate only slow hotspots that fail to meet LoRaWAN-grade timing constraints -- to push helium hotspots to improve their response time, over time, reasonably. +- to push helium hotspots to improve their response time, over time, reasonably. # Motivation -The LoRaWAN network has some timing constraints to be considered. They are related to the JOIN mechanism -and the ACK/Downlink mechanism. JOIN requires a full loop within 5 seconds, up to 6 seconds. ACK/Downlink requires a full loop in 1 -second for RX1 windows, up to 2 seconds for RX2 windows. Out of this time frame, the response will be ignored by the sensor devices. [Appendix](#packet-processing-and-lorawan-time-constraints) gives the consequence of these constraints on the expected hotspot response time. +The LoRaWAN network has some timing constraints to be considered. They are related to the JOIN mechanism +and the ACK/Downlink mechanism. JOIN requires a full loop within 5 seconds, up to 6 seconds. ACK/Downlink requires a full loop in 1 +second for RX1 windows, up to 2 seconds for RX2 windows. Out of this time frame, the response will be ignored by the sensor devices. [Appendix](#packet-processing-and-lorawan-time-constraints) gives the consequence of these constraints on the expected hotspot response time. LoRaWAN is a question of seconds ($`10^0s`$ to $`10^{-1}s`$), not a question of microseconds ($`10^{-6}s`$), this is why creating a competition between hotspots and network connectivity at a millisecond ($`10^{-3}s`$) scale is not achieving any network goal. -Hotspots with highly valuable locations, such as the mountaintops, cell towers, and even rooftops -sometimes rely on higher latency connectivity (4G/5G, Home Plug, Satellites) which adds anywhere from -10ms to 100ms. These hotspots generally have a higher operating cost due to dedicated connectivity and hosting cost. They are unfairly impacted by the current selection algorithm as they still operate within LoRaWAN timing specifications. +Hotspots with highly valuable locations, such as the mountaintops, cell towers, and even rooftops +sometimes rely on higher latency connectivity (4G/5G, Home Plug, Satellites) which adds anywhere from +10ms to 100ms. These hotspots generally have a higher operating cost due to dedicated connectivity and hosting cost. They are unfairly impacted by the current selection algorithm as they still operate within LoRaWAN timing specifications. See [appendix](#highly-valuable-coverage) about highly valuable coverage. -Hotspots located out of city centers will get a slower Internet response time from the one in the city center, +Hotspots located out of city centers will get a slower Internet response time from the one in the city center, even with fast Internet access, due to some extra network hops or downgraded connectivity technology like xDSL. See [Appendix](#suburb-valuable-coverage) about suburb valuable coverage. -Hotspots with the worst locations, indoor, in the city center, can get the best response time experience +Hotspots with the worst locations, indoor, in the city center, can get the best response time experience with direct fiber connectivity. -We have seen that depending on the hardware of the hotspot, the Witness processing time is largely dependent -on the packet signature as described in the [appendix](#ecc-signature-impact). As the signature is delegated to the hardware -ECC chip for most of the deployed hotspots, the processing time depends on the [hardware solution](#mcu-performance-impact) soldered in. -Even if firmware can be improved, the current solution disqualifies certain hardware no matter the hotspot owner's efforts. +We have seen that depending on the hardware of the hotspot, the Witness processing time is largely dependent +on the packet signature as described in the [appendix](#ecc-signature-impact). As the signature is delegated to the hardware +ECC chip for most of the deployed hotspots, the processing time depends on the [hardware solution](#mcu-performance-impact) soldered in. +Even if firmware can be improved, the current solution disqualifies certain hardware no matter the hotspot owner's efforts. More generally speaking, it disqualifies lower-end hardware like light-hotspots based on microcontrollers as, by definition, their capacity to process the same thing as hotspots based on CPU [is lower](#mcu-performance-impact). This is a highly disadvantageous consequence as this hardware has a better fit for stability, long-life, energy saving, lower cost, and should be privileged long term. -The People's Network must be accessible to anyone and not be a competition of millisecond optimization limited to a +The People's Network must be accessible to anyone and not be a competition of millisecond optimization limited to a small group of experts. -The witness response time is not representative of the data packet processing. Witness response time does not have any -constraint of time. Witnesses are processed by Oracles, and response time depends on the Oracle localization, +The witness response time is not representative of the data packet processing. Witness response time does not have any +constraint of time. Witnesses are processed by Oracles, and response time depends on the Oracle localization, associated with the network path to reach that Oracle. It is totally different from the LNS network path taken by sensors. Response time can differ from one Witness to another Witness, the absolute response time is not a good way to measure a performance responding to the LoRaWAN timing constraints. The [Witness process](#witness-processing-waterfall) and the [Packet process](#packet-processing-waterfall) are detailed in the respective appendixes. -As for a given witness, the Hotspots from a similar area will report it to the same Oracle. We can consider a response -time window starting from the first witness received by the Oracle as a viable solution to eliminate the variable offset +As for a given witness, the Hotspots from a similar area will report it to the same Oracle. We can consider a response +time window starting from the first witness received by the Oracle as a viable solution to eliminate the variable offset timing and to eliminate those hotspots that are really slower and can cause a problem for data processing. # Stakeholders @@ -66,27 +67,29 @@ Nova Labs is the entity requested to implement the changes in the HIP. # Rationale and Alternatives -This HIP proposes to select a valid witness from the ones arriving in a time window of MAX_WITNESS_WAIT_WINDOW_MS starting -from the first received witness by the Oracle. +This HIP proposes to select a valid witness from the ones arriving in a time window of MAX_WITNESS_WAIT_WINDOW_MS starting +from the first received witness by the Oracle. -The MAX_WITNESS_WAIT_WINDOWS_MS parameter will be initially set to 200ms (0.2 seconds), accordingly to the calculation described in [appendix](#packet-processing-waterfall). +The MAX_WITNESS_WAIT_WINDOWS_MS parameter will be initially set to 200ms (0.2 seconds), accordingly to the calculation described in [appendix](#packet-processing-waterfall). It could be later adjusted from 100ms to 300ms by Helium Foundation to optimize the network quality without a need for a new -vote. The purpose of this adjustment is to push hardware manufacturers to optimize their solutions in a scheduled way. The initial 200ms take into consideration the ECC signature and radio backhaul normal impact vs DiY in the LoRaWan constraints. +vote. The purpose of this adjustment is to push hardware manufacturers to optimize their solutions in a scheduled way. The initial 200ms take into consideration the ECC signature and radio backhaul normal impact vs DiY in the LoRaWan constraints. When less than **default_max_witnesses_per_poc** Witnesses (Currently 14) have been received within the MAX_WITNESS_WAIT_WINDOWS_MS, the Oracle accepts Witnesses up to EXTENDED_WITNESS_WAIT_WINDOWS_MS, fixed at 500ms, the acceptable wait time for RX1 windows for regional traffic. This will allow slower responding hotspots to be accepted in the low density areas when in high density the constraint is stronger. The current situation, with HIP-83, is accepting witness without limit of time in a such case, even if the time makes no LoRaWAN downlink & join possible. -This means: +This means: + 1. Different hotspots receive a beacon and send the witness information to the related Oracle 2. The Oracle receives the first witness notification and opens a witness reception window for MAX_WITNESS_WAIT_WINDOWS_MS -milliseconds. Witness is marked Valid. + milliseconds. Witness is marked Valid. 3. The Oracle receives the next witnesses during the MAX_WITNESS_WAIT_WINDOWS_MS ms and mark them Valid. 4. When **default_max_witnesses_per_poc** or more have been received, it marks the other as Invalid 5. When MAX_WITNESS_WAIT_WINDOWS_MS is over and less than **default_max_witnesses_per_poc** received, Oracle marks the first received as selected and waits until **default_max_witnesses_per_poc** or EXTENDED_WITNESS_WAIT_WINDOWS_MS, mark them as valid, then the others invalid. -7. The Oracle selects all the **selected** witnesses and allocates rewards to the number of hotspots defined in **default_max_witnesses_per_poc** by selecting randomly from the ones marked as valid. +6. The Oracle selects all the **selected** witnesses and allocates rewards to the number of hotspots defined in **default_max_witnesses_per_poc** by selecting randomly from the ones marked as valid. ### Example 1 8 witnesses received: + - 4 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 3 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 1 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -94,7 +97,9 @@ milliseconds. Witness is marked Valid. The first 4 are marked as SELECTED, the 3 next are marked as VALID, the last one is marked as INVALID. Oracle rewards all the one marked as SELECTED, it can select 10 more randomly as part of the ones marked as VALID, so it reward all of them. The last one is not rewarded. Assuming **default_max_witnesses_per_poc** is 14 ### Example 2 + 25 witnesses received: + - 20 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 4 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 1 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -102,7 +107,9 @@ The first 4 are marked as SELECTED, the 3 next are marked as VALID, the last one Only the first 20 within MAX_WITNESS_WAIT_WINDOWS_MS will be selected and marked as VALID, all the others are INVALID and won't be part of the reward calculation. The Oracle will randomly select 14 of the 20 VALID witness and reward them. Assuming **default_max_witnesses_per_poc** is 14 ### Example 3 + 25 witnesses received: + - 10 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 8 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 7 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -111,26 +118,29 @@ The first 10 are marked as SELECTED, the next 8 are marked as VALID, the 7 other ** Alternate Proposal ** -This HIP proposes to select **all witness** arriving in a time window of MAX_WITNESS_WAIT_WINDOW_MS starting -from the first received witness by the Oracle. +This HIP proposes to select **all witness** arriving in a time window of MAX_WITNESS_WAIT_WINDOW_MS starting +from the first received witness by the Oracle. The MAX_WITNESS_WAIT_WINDOWS_MS parameter will be initially set to 200ms (0.2 seconds), accordingly to the calculation described in [appendix](#packet-processing-waterfall). It could be later adjusted from 100ms to 300ms by Helium Foundation to optimize the network quality without a need for a new -vote. The purpose of this adjustment is to push hardware manufacturers to optimize their solutions in a scheduled way. The initial 200ms take into consideration the ECC signature and radio backhaul normal impact vs DiY in the LoRaWan constraints. +vote. The purpose of this adjustment is to push hardware manufacturers to optimize their solutions in a scheduled way. The initial 200ms take into consideration the ECC signature and radio backhaul normal impact vs DiY in the LoRaWan constraints. When less than 5 Witnesses have been received within the MAX_WITNESS_WAIT_WINDOWS_MS, the Oracle accepts Witnesses, with a maximum ot 5 total, up to EXTENDED_WITNESS_WAIT_WINDOWS_MS, fixed at 500ms, the acceptable wait time for RX1 windows for regional traffic. This will allow slower hotspots to be accepted in the low density area when in high density the constraint is stronger. This allows to have satellite backhaul in low density areas. The current situation, with HIP-83, is accepting witness without limit of time in a such case, even if the time makes no LoRaWAN downlink & join possible. -This means: +This means: + 1. Different hotspots receive a beacon and send the witness information to the related Oracle 2. The Oracle receives the first witness notification and opens a witness reception window for MAX_WITNESS_WAIT_WINDOWS_MS -milliseconds. Witness is marked SELECTED. + milliseconds. Witness is marked SELECTED. 3. The Oracle receives the next witnesses during the MAX_WITNESS_WAIT_WINDOWS_MS ms and mark them SELECTED. 4. When 5 or more have been received, it marks the other as INVALID 5. When MAX_WITNESS_WAIT_WINDOWS_MS is over and less than 5 received, Oracle marks the next SELECTED until EXTENDED_WITNESS_WAIT_WINDOWS_MS with a maximum of 5 witnesses total, next are marked INVALID. -7. The Oracle selects all the **SELECTED** witnesses to be rewarded. +6. The Oracle selects all the **SELECTED** witnesses to be rewarded. ### Example 1 + 25 witnesses received: + - 20 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 4 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 1 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -138,7 +148,9 @@ milliseconds. Witness is marked SELECTED. Only the first 20 within MAX_WITNESS_WAIT_WINDOWS_MS will be selected and marked as SELECTED, all the others are INVALID and won't be part of the reward calculation. The Oracle will reward all the SELECTED witnesses. ### Example 2 + 25 witnesses received: + - 10 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 8 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 7 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -146,7 +158,9 @@ Only the first 20 within MAX_WITNESS_WAIT_WINDOWS_MS will be selected and marked The first 10 are marked as SELECTED, the next 8 are marked as INVALID, the 7 others are marked as INVALID. Oracle will reward all the SELECTED and reward them. ### Example 3 + 8 witnesses received: + - 4 within MAX_WITNESS_WAIT_WINDOWS_MS 200ms - 3 within EXTENDED_WITNESS_WAIT_WINDOWS_MS 200-500ms - 1 outside EXTENDED_WITNESS_WAIT_WINDOWS_MS 500ms @@ -155,36 +169,38 @@ The first 4 are marked as SELECTED, the first 1 of the next 3 is marked as SELEC ** Option on proposal ** -Community discussions proposes to keep an incentive on hotspot response time performance by getting a better reward distribution to the first responding and a lower to the last responding. This will be detailed if a later discussion comes to the selection of this option. +Community discussions proposes to keep an incentive on hotspot response time performance by getting a better reward distribution to the first responding and a lower to the last responding. This will be detailed if a later discussion comes to the selection of this option. The way it would work would basically be like: + - in first alternative: select the 7 (50% of the **default_max_witnesses_per_poc**) first responding hotspots then randomly select the 7 others ( 50% of the **default_max_witnesses_per_poc**) - in the second alternative: distribute 40% of the reward to the fastest 20%, 40% to the next 60%, 20% to the last 40%. Positive impact: -- Reduce the impact of the reward calculation change for the one having a benefit of HIP-83. + +- Reduce the impact of the reward calculation change for the one having a benefit of HIP-83. - Continue to incentive hardware provider optimization - Continue to incentive faster connectivity Negative impact: -- This option add complexity in the development. + +- This option add complexity in the development. - Continue to have inequity in reward distribution based on your geographical localization. - Continue to have an inequity between hotspot brands conducting to disconnection. - Push to hack hotspot to grab some ms and create an inequity in regard of owner technical skills. - # Unresolved Questions - Packet processing is currently involving signature from ECC for every packet, this is time costly and not mandatory. -Some discussions are already opened to move this with a software signature from an ECC derived key negotiated with Helium -Packet Router for a given period of time. + Some discussions are already opened to move this with a software signature from an ECC derived key negotiated with Helium + Packet Router for a given period of time. - Witness could be selected also in regard of their location. For example we could get a priority on the witnesses coming from the longest distance to offer an advantage to the hotspot offering the larger coverage. -- There could be some hotspot designs or configurations that always respond over 500ms, these would never be rewarded. +- There could be some hotspot designs or configurations that always respond over 500ms, these would never be rewarded. # Deployment Impact -Oracle PoC rewarding code needs to be modified to take this into consideration. Deployment is global, Hotspots are not impacted. +Oracle PoC rewarding code needs to be modified to take this into consideration. Deployment is global, Hotspots are not impacted. The Oracle PoC code update will impact the Nova team for deployment, the Author of this HIP is not attaching any code. # Success Metrics @@ -198,8 +214,8 @@ The Oracle PoC code update will impact the Nova team for deployment, the Author ## Highly Valuable Coverage -Some of the hotspot have a really large coverage by being installed in really good / high location. These hotspots, due to the -geographical location and the height are covering a wide zone, larger than a city. That way, they are offering a unique coverage. The following picture is illustrating this: the blue area is representing the coverage offered by this single hotspot, the orange +Some of the hotspot have a really large coverage by being installed in really good / high location. These hotspots, due to the +geographical location and the height are covering a wide zone, larger than a city. That way, they are offering a unique coverage. The following picture is illustrating this: the blue area is representing the coverage offered by this single hotspot, the orange represent the city coverage provided by the mass of the other hotspot in the same area. All these hotspots are in competition for the same witness. ![Highly valuable coverage illustration](files/0094/valuable-coverage.png) @@ -212,8 +228,8 @@ This HIP does not propose to give these hotspots any advantages, the existing PO ## Suburb Valuable Coverage -The hotspots located in suburb and above, in blue in the illustration, are expending the network coverage with unique -coverage zone and are in competition with the hotspot inside the city. +The hotspots located in suburb and above, in blue in the illustration, are expending the network coverage with unique +coverage zone and are in competition with the hotspot inside the city. ![Suburb illustration](files/0094/suburb-coverage.png) @@ -227,14 +243,15 @@ This HIP does not propose to give these hotspots any advantages, the existing PO ## Packet Processing and LoRaWan time constraints -The Helium Packet Router (HPR) is accepting all the coming packets up to the limit of the max_copies set on the route or eui in +The Helium Packet Router (HPR) is accepting all the coming packets up to the limit of the max_copies set on the route or eui in the config service. First come, first paid. Only for roaming the HPR is applying a short time limit. -According to Nova labs response, Helium packets, first arriving is opening a packet session for collecting the copies of it, during the session, all the packets up to max_copies are accepted and transmitted to LNS, after max_copies packets all are discarded. On every 30 minutes the session having an age higher than 30 minutes are closed. This means, a packet can be accepted up to 30 to 60 minutes after being emitted at HPR level. +According to Nova labs response, Helium packets, first arriving is opening a packet session for collecting the copies of it, during the session, all the packets up to max_copies are accepted and transmitted to LNS, after max_copies packets all are discarded. On every 30 minutes the session having an age higher than 30 minutes are closed. This means, a packet can be accepted up to 30 to 60 minutes after being emitted at HPR level. The time limit for accepting packets as a single group of copies is decided by the LNS after the HPR. This time limit for the LNS is a LNS setup and can vary for each of the LNS. A LNS operating a local fleet will prefer a larger time windows to collect more copies, 600-800ms are viable configurations, global LNS will prefer a shorter time windows (see above waterfall for details). LoRaWAN time constraints are the following: + - UPLINK first copy arrival has no time constraint, next copies are withing the defined LNS deduplication time windows. - JOIN REQUEST needs to be responded within 5 seconds for RX1 (same frequency, standard power) or 6 seconds for RX2 (other frequency, potentially higher power). LNS decides of the selection between RX1 and RX2 dynamically, according to the time available. - DOWNLINK REQUEST / ACK needs to be responded within 1 seconds for RX1 (same frequency, standard power) or 2 seconds for RX2 (other frequency, potentially higher power). LNS decides of the selection between RX1 and RX2 dynamically, according to the time available. @@ -247,64 +264,64 @@ Basically, only the DOWNLINK REQ / ACK creates generate a time constraint at the In this constraint of time, we need to execute the [full packet processing steps](#packet-processing-waterfall). Based on this the LNS is able to accept incoming packets in a time windows with a minimal duration of 210ms with a 200ms margin, -so basically up to 350-400ms. +so basically up to 350-400ms. ## Network hotspot loss acceleration The following data, computed on August 27th, gives the number of hotspots having given (witness, beacon, reward) activity at or after the given date. You can read it the following way: -- As seen on August 27th, there was 395717 uniq hotspots having received a witness (valid or not) since July 31st, 402719 having beaconned since July 31st, 395717 having been rewarded for any kind of activities including data reward. The max value of it can be considered as the number of active devices at this date. -- As the data are computed on August 27, the difference between two days is indicating the number of devices not been active on the network for at least a month. -- The reason of this can be denied list (the recent reactivation of the previously denied hostpot had a large impact on these day-to-day data), can be hostpot firmware bug stopping it, can be any local problem owner did not fixed, can be hostpot removal. - - -| Date | Hs Witnessing | Hs Beaconing | Hs Rewarded | Hs Active | Hs Disconnected | -| --------- | ------------- | ------------ | ----------- | --------- | --------------- | -|30/06/2023|422691|428140|422691|428140|5449|796| -|01/07/2023|421811|427280|421811|427280|5469|860| -|02/07/2023|420993|426464|420993|426464|5471|816| -|03/07/2023|420094|425652|420094|425652|5558|812| -|04/07/2023|419239|424849|419239|424849|5610|803| -|05/07/2023|418376|423994|418376|423994|5618|855| -|06/07/2023|417483|423052|417483|423052|5569|942| -|07/07/2023|416539|422301|416539|422301|5762|751| -|08/07/2023|415770|421635|415770|421635|5865|666| -|09/07/2023|415014|420909|415014|420909|5895|726| -|10/07/2023|414250|420142|414250|420142|5892|767| -|11/07/2023|413448|419409|413448|419409|5961|733| -|12/07/2023|412579|418673|412579|418673|6094|736| -|13/07/2023|411787|417936|411787|417936|6149|737| -|14/07/2023|411000|417222|411000|417222|6222|714| -|15/07/2023|410167|416446|410167|416446|6279|776| -|16/07/2023|409373|415686|409373|415686|6313|760| -|17/07/2023|408555|414893|408555|414893|6338|793| -|18/07/2023|407717|414105|407717|414105|6388|788| -|19/07/2023|406949|413387|406949|413387|6438|718| -|20/07/2023|406110|412624|406110|412624|6514|763| -|21/07/2023|405227|411752|405227|411752|6525|872| -|22/07/2023|404327|410880|404327|410880|6553|872| -|23/07/2023|403425|410057|403425|410057|6632|823| -|24/07/2023|402609|409319|402609|409319|6710|738| -|25/07/2023|401761|408483|401761|408483|6722|836| -|26/07/2023|400833|407595|400833|407595|6762|888| -|27/07/2023|399864|406718|399864|406718|6854|877| -|28/07/2023|398746|405635|398746|405635|6889|1083| -|29/07/2023|397776|404689|397776|404689|6913|946| -|30/07/2023|396629|403571|396629|403571|6942|1118| -|31/07/2023|395717|402719|395717|402719|7002|852| + +- As seen on August 27th, there was 395717 uniq hotspots having received a witness (valid or not) since July 31st, 402719 having beaconned since July 31st, 395717 having been rewarded for any kind of activities including data reward. The max value of it can be considered as the number of active devices at this date. +- As the data are computed on August 27, the difference between two days is indicating the number of devices not been active on the network for at least a month. +- The reason of this can be denied list (the recent reactivation of the previously denied hostpot had a large impact on these day-to-day data), can be hostpot firmware bug stopping it, can be any local problem owner did not fixed, can be hostpot removal. + +| Date | Hs Witnessing | Hs Beaconing | Hs Rewarded | Hs Active | Hs Disconnected | +| ---------- | ------------- | ------------ | ----------- | --------- | --------------- | ---- | +| 30/06/2023 | 422691 | 428140 | 422691 | 428140 | 5449 | 796 | +| 01/07/2023 | 421811 | 427280 | 421811 | 427280 | 5469 | 860 | +| 02/07/2023 | 420993 | 426464 | 420993 | 426464 | 5471 | 816 | +| 03/07/2023 | 420094 | 425652 | 420094 | 425652 | 5558 | 812 | +| 04/07/2023 | 419239 | 424849 | 419239 | 424849 | 5610 | 803 | +| 05/07/2023 | 418376 | 423994 | 418376 | 423994 | 5618 | 855 | +| 06/07/2023 | 417483 | 423052 | 417483 | 423052 | 5569 | 942 | +| 07/07/2023 | 416539 | 422301 | 416539 | 422301 | 5762 | 751 | +| 08/07/2023 | 415770 | 421635 | 415770 | 421635 | 5865 | 666 | +| 09/07/2023 | 415014 | 420909 | 415014 | 420909 | 5895 | 726 | +| 10/07/2023 | 414250 | 420142 | 414250 | 420142 | 5892 | 767 | +| 11/07/2023 | 413448 | 419409 | 413448 | 419409 | 5961 | 733 | +| 12/07/2023 | 412579 | 418673 | 412579 | 418673 | 6094 | 736 | +| 13/07/2023 | 411787 | 417936 | 411787 | 417936 | 6149 | 737 | +| 14/07/2023 | 411000 | 417222 | 411000 | 417222 | 6222 | 714 | +| 15/07/2023 | 410167 | 416446 | 410167 | 416446 | 6279 | 776 | +| 16/07/2023 | 409373 | 415686 | 409373 | 415686 | 6313 | 760 | +| 17/07/2023 | 408555 | 414893 | 408555 | 414893 | 6338 | 793 | +| 18/07/2023 | 407717 | 414105 | 407717 | 414105 | 6388 | 788 | +| 19/07/2023 | 406949 | 413387 | 406949 | 413387 | 6438 | 718 | +| 20/07/2023 | 406110 | 412624 | 406110 | 412624 | 6514 | 763 | +| 21/07/2023 | 405227 | 411752 | 405227 | 411752 | 6525 | 872 | +| 22/07/2023 | 404327 | 410880 | 404327 | 410880 | 6553 | 872 | +| 23/07/2023 | 403425 | 410057 | 403425 | 410057 | 6632 | 823 | +| 24/07/2023 | 402609 | 409319 | 402609 | 409319 | 6710 | 738 | +| 25/07/2023 | 401761 | 408483 | 401761 | 408483 | 6722 | 836 | +| 26/07/2023 | 400833 | 407595 | 400833 | 407595 | 6762 | 888 | +| 27/07/2023 | 399864 | 406718 | 399864 | 406718 | 6854 | 877 | +| 28/07/2023 | 398746 | 405635 | 398746 | 405635 | 6889 | 1083 | +| 29/07/2023 | 397776 | 404689 | 397776 | 404689 | 6913 | 946 | +| 30/07/2023 | 396629 | 403571 | 396629 | 403571 | 6942 | 1118 | +| 31/07/2023 | 395717 | 402719 | 395717 | 402719 | 7002 | 852 | Data after July 31th are impacted by Halving and later by the deny list changes. -Basically the average loss per day before HIP-83 is 785 and after HIP-83 is 845. +Basically the average loss per day before HIP-83 is 785 and after HIP-83 is 845. The average not rewarded was 5688 then 6583. -In a short term the HIP-83 did not have significant negative impact on disconnection rate (+6%) and it +In a short term the HIP-83 did not have significant negative impact on disconnection rate (+6%) and it did not add a significant impact on rewarded hotspots (beacons and data are not impacted by this evolution). -It did not have a positive impact either. +It did not have a positive impact either. In a longer term, it will be impossible to evaluate the impact as the halving started on August 1st. Between August 1st and August 15th, the average disconnection a day jumped to 1020 (+20%). ![Hotspot disconnection evolution over 45 days](files/0094/hotspot-disconnection-evoltution.png) -Up to 41.000 hotspots (10% of the initial fleet) have been lost between July 1st and August 15th. +Up to 41.000 hotspots (10% of the initial fleet) have been lost between July 1st and August 15th. ### Rewarded Hotspots for Witnesses @@ -312,49 +329,48 @@ The following [Helium Geek](https://heliumgeek.com/stats/epoch/iot) stats displa ![Hotspot daily stats](files/0094/hotspot-daily-stats.png) - You can notice that since HIP 83 launch we had a break in the witness participation by 10,000 hotspots. This means the witnesses rewards goes to fewer hotspots, even if all are participating to witness beaconing. 10,000 of the hotspots are out of most for the reward distribution, to the benefit of the others. - - There is no visible short term evolution of the other trends, daily stats continue to decrease the same way. +You can notice that since HIP 83 launch we had a break in the witness participation by 10,000 hotspots. This means the witnesses rewards goes to fewer hotspots, even if all are participating to witness beaconing. 10,000 of the hotspots are out of most for the reward distribution, to the benefit of the others. +There is no visible short term evolution of the other trends, daily stats continue to decrease the same way. ## MCU performance impact -| Hotspot | Motherboard | CPU/MCU | Clock | Cores | -|---------|-------------|---------|-------|-------| -| Nebra...| RPI CM3 | BCM2837B0 | 1400MHz | 4 | -| Rak... | RPI 4 | BCM2711 | 1500MHz | 4 | | -| Kerlink | Custom | MCIMX6X1CVO08AB | 800MHz | 1 | -| Senscap M2| Mediatek | MT7628 | 580MHz | 1 | +| Hotspot | Motherboard | CPU/MCU | Clock | Cores | +| ---------- | ----------- | --------------- | ------- | ----- | --- | +| Nebra... | RPI CM3 | BCM2837B0 | 1400MHz | 4 | +| Rak... | RPI 4 | BCM2711 | 1500MHz | 4 | | +| Kerlink | Custom | MCIMX6X1CVO08AB | 800MHz | 1 | +| Senscap M2 | Mediatek | MT7628 | 580MHz | 1 | ## ECC Signature impact -The ECC Signature process is having a significant impact on the overall processing, some measure have been conducted by +The ECC Signature process is having a significant impact on the overall processing, some measure have been conducted by community members like Miroslav (heliootics) & co, Jose Marcelino, using the gateway-mfr-rs test kit. For the tested hotspot provider we can the following average signature time: -| Manufacturer Brand | Model | Avg Signature Time | Note | -| ------------------ | ----- | ------------------ | ---- | -| Calchip v1 | | ? | no ECC | -| DiY | x86 | ? | no ECC | -| DiY | RPI 4 | ? | no ECC | -| Bobcat | RK3566 | 105 ms | | -| Milesight | | 105 ms | | -| Nebra | indoor CM3 v1 | 113 ms | | -| Synchrobit | CM4 | 120 ms | | -| Cotx | X3 | 130 ms | | -| Heltec | HT-M2808 | 135 ms | | -| Bobcat | Others | 150 ms | | -| Linxdot | | 152 ms | | -| Dusun | | 154 ms | | -| Nebra | indoor CM3 v2 | 157 ms | | -| RAK / MNTD | Gold | 165 ms | | -| RAK / MNTD | Black | 174 ms | | -| Pycom | Other | 175 ms | | -| Sensecap | M1 | 175 ms | | -| PantherX1 | | 179 ms | | -| Pisces | | 180 ms | | -| Controllino | | 180 ms | | -| Heltec | Other | 242 ms | | -| FreedomFi | | 400 ms | | +| Manufacturer Brand | Model | Avg Signature Time | Note | +| ------------------ | ------------- | ------------------ | ------ | +| Calchip v1 | | ? | no ECC | +| DiY | x86 | ? | no ECC | +| DiY | RPI 4 | ? | no ECC | +| Bobcat | RK3566 | 105 ms | | +| Milesight | | 105 ms | | +| Nebra | indoor CM3 v1 | 113 ms | | +| Synchrobit | CM4 | 120 ms | | +| Cotx | X3 | 130 ms | | +| Heltec | HT-M2808 | 135 ms | | +| Bobcat | Others | 150 ms | | +| Linxdot | | 152 ms | | +| Dusun | | 154 ms | | +| Nebra | indoor CM3 v2 | 157 ms | | +| RAK / MNTD | Gold | 165 ms | | +| RAK / MNTD | Black | 174 ms | | +| Pycom | Other | 175 ms | | +| Sensecap | M1 | 175 ms | | +| PantherX1 | | 179 ms | | +| Pisces | | 180 ms | | +| Controllino | | 180 ms | | +| Heltec | Other | 242 ms | | +| FreedomFi | | 400 ms | | The signature impacts on the first to arrive show a variability up to 250ms. ( to be completed with the non ECC device data later one) @@ -362,18 +378,19 @@ The consequence of this in regard of the HIP-83 can be shown on the following gr ![ECC Signature impact on witness selection](files/0094/hip83-delta-by-maker.png) -This graphic shows, after the start of the HIP-83, the witness selection change by maker. It shows the number of hotspot (Y axis) selected more time, on the right side of the 0 (X axis) or selected less time, on the left side of the 0 (X axis). +This graphic shows, after the start of the HIP-83, the witness selection change by maker. It shows the number of hotspot (Y axis) selected more time, on the right side of the 0 (X axis) or selected less time, on the left side of the 0 (X axis). We see that the distribution is not centered, with certain brands getting an advantage on the other, due to hardware and software implementation. Bobcat ( faster ECC ) and Kerlink ( MCU integrated ECC ) takes advantage over the other manufacturer. -The timing given above evolves based on the gateway-rs evolution, the manufacturer firmware improvement and my not be accurate at the day of the +The timing given above evolves based on the gateway-rs evolution, the manufacturer firmware improvement and my not be accurate at the day of the reading. This aimed to illustrate how a single piece of hardware in the solution, will have a significant impact on the PoC response time. ## Packet Processing Waterfall -The following waterfall represents the different steps in the data packet processing, in the case of a packet requesting an ACK or a downlink. The HPR is geo-replicated, time to reach it is within the zone. +The following waterfall represents the different steps in the data packet processing, in the case of a packet requesting an ACK or a downlink. The HPR is geo-replicated, time to reach it is within the zone. Two scenarios are identified: + - the first one in gray is the best case scenario, hotspot is fast and the LNS is in the same zone the device is, so the communication from HPR to LNS then LNS to Hotspot is short. - the second one in orange is the worst case scenario, hotspot is slower and LNS and device are in at the longest Internet distance, considering 600ms. @@ -381,10 +398,9 @@ The first scenario gives an idea of the acceptable copies reception windows to m ![Packer Processing Waterfall](files/0094/packet-processing-waterfall.png) -This minimum reception window to achieve the worst case has been used to propose the initial time windows for accepting the +This minimum reception window to achieve the worst case has been used to propose the initial time windows for accepting the witnesses. - ## Witness Processing Waterfall The following waterfall represent the different steps in the witness processing, the variability of each of the steps, depending on hardware, network access, network variability as been identified to have the scale of magnitude of each of the steps on the global processing. As steps normal variability is large and really context driven, this illustration tries to approximate the best way as possible but can't be exact. @@ -398,10 +414,4 @@ The following waterfall represent the different steps in the witness processing, The variation of time related to the hotspot type of connectivity (yellow block) is really limited compared to the overall variability in the Witness processing. Hotspot hardware is first impacting the performance, then network access is quite equivalent to Internet natural variability from one packet to the other ( distribution is different ). -A reception windows of 320ms should cancel all the natural variability, the use of a windows 200ms will still impact the slow hotspots. The extended windows, used in the low density area is covering all the variability. - - - - - - +A reception windows of 320ms should cancel all the natural variability, the use of a windows 200ms will still impact the slow hotspots. The extended windows, used in the low density area is covering all the variability. diff --git a/0095-self-onboard-hotspots-after-maker-exit.md b/0095-self-onboard-hotspots-after-maker-exit.md index 64745149a..c7291f943 100644 --- a/0095-self-onboard-hotspots-after-maker-exit.md +++ b/0095-self-onboard-hotspots-after-maker-exit.md @@ -23,7 +23,7 @@ This proposal excludes data-only hotspots as their owners can already onboard us ## Motivation -Over the last year, as the number of manufacturers has increased, so have the number of hotspots in the market. Some manufacturers find that they are no longer able to stay in business due to financial issues, and others are removed from the network for non-compliance. When a manufacturer exits the network, they may leave sold hotspots in the hands of customers who are then unable to onboard the hotspots to the network and/or assert the hotspot’s location. +Over the last year, as the number of manufacturers has increased, so have the number of hotspots in the market. Some manufacturers find that they are no longer able to stay in business due to financial issues, and others are removed from the network for non-compliance. When a manufacturer exits the network, they may leave sold hotspots in the hands of customers who are then unable to onboard the hotspots to the network and/or assert the hotspot’s location. The IOT location assertion and onboarding fee (Currently total $45 paid in DC) and MOBILE location assertion and onboarding fee (Currently total $50 paid in DC) in most cases have already been paid by the hotspot owner as part of the cost of purchasing the hotspot. Currently, when a manufacturer leaves the network, if these fees haven't been paid the hotspot owner is required to pay these fees if the maker account lacks funding for these fees. @@ -52,6 +52,7 @@ Currently, if a maker leaves the network (for whatever reason) and subsequently However, onboarding/ assertion fees can be deducted from the hotspot owner’s wallet instead of the maker wallet. This could use the same mechanism by which data only Hotspots are onboarded and the Helium Wallet App can assert IOT or MOBILE locations paying from the owner's wallet not the maker wallet. **Currently the onboarding process looks like this:** + - Maker uploads records containing many Hotspots and info about them. - These records tie the Hotspots to the specific maker - User purchases Hotspot @@ -61,10 +62,12 @@ However, onboarding/ assertion fees can be deducted from the hotspot owner’s w - User onboards Hotspot by paying the Onboarding Fee(s). Currently the maker pays the DC fees to onboard. This could be changed to the initiating wallet for makers that have exited. **Assumptions:** + - We trust the hotspots that are in the database for the hotspot manufacturer (if we don't, such as in the case of Deeper, there are already mechanisms to deal with this - such as Denylist and suspending the maker) - That the manufacturer and not a bad actor actually added those hotspots to the database (again, this is probably outside the scope of this HIP) **This HIP proposes to solve this issue by some fairly minor changes to the current process:** + - currently, if a maker leaves the ecosystem (such as Pycom, Syncrobit, Controllino have) the Helium Foundation may suspend their maker key or stop them from adding more records to the onboarding server. As part of this process, a flag should be added to the onboarding server marking this maker as defunct. When that flag is flipped, the transaction that is returned for onboarding has the hotspot owner as the payer - when onboarding, the Helium SDK / wallet app / maker apps can then look at this flag, and if a maker is found to be defunct/suspended/inactive and additionally has 0 onboarding credits left, it informs the user of this and allows them to optionally select to use their own HNT, performs an implicit burn to DC and onboards their hotspot all in a single action from the maker-app during onboarding - it is proposed that the MCC / Helium Foundation are in charge of the flag and deciding when it should be flipped @@ -83,9 +86,9 @@ Both of these drawbacks are determined to be small and not blockers to this prop ## Rationale and Alternatives -The only real alternative is the status-quo, which is not ideal whatsoever. +The only real alternative is the status-quo, which is not ideal whatsoever. -Whilst no options in the scenario of a maker leaving the ecosystem are particularly ideal, the priority should be to ensure the least-possible interruption to hardware onboarding and user participation in the network. +Whilst no options in the scenario of a maker leaving the ecosystem are particularly ideal, the priority should be to ensure the least-possible interruption to hardware onboarding and user participation in the network. The impact of not doing this is a sub-par onboarding experience for people who are already in the unfortunate situation of a maker that has let them down and left the network. Part of the reason the Helium Network has been so sucessful is the ease of onboarding and the great user experience - any ways of improving the onboarding user experience should be welcomed to ensure maximum possible uptake and to avoid perfectly capable hardware being left unused and obsolete due to a maker exiting the ecosystem. @@ -96,11 +99,12 @@ The impact of not doing this is a sub-par onboarding experience for people who a ## Deployment Impact **Who will implement the changes:** + - Helium Foundation or Nova Labs to make changes to Helium SDK / onboarding server / wallet app / maker-starter-app to allow for this functionality - Maker app creators to pull through and implement the necessary changes to their individual apps - Helium Foundation / MCC to manage the process of flagging the necessary maker wallets in the onboarding server -This will be deployed via updates to the Helium SDK, the onboarding server, wallet app and maker starter app. +This will be deployed via updates to the Helium SDK, the onboarding server, wallet app and maker starter app. Current users will not be impacted on any existing capabilities other than a much easier onboarding method in the scenario described. Makers will have to deploy a new version of their App which is compatible with this HIP. diff --git a/0096-wifi-ap-onboarding-structure.md b/0096-wifi-ap-onboarding-structure.md index 2cd29fe8a..62716c8b9 100644 --- a/0096-wifi-ap-onboarding-structure.md +++ b/0096-wifi-ap-onboarding-structure.md @@ -11,7 +11,7 @@ # Summary -This HIP outlines the onboarding fee structure for two new device types: "Indoor WiFi APs" and "Outdoor WiFi APs". The proposed onboarding fees are designed to be approximately 10% of the Manufacturer's Suggested Retail Price (MSRP) of the devices (please see below for specifics). The fees consist of a combination of HNT derived data credits and MOBILE tokens. It is expected that future devices of different classes will follow a similar pricing structure based on their respective MSRP. +This HIP outlines the onboarding fee structure for two new device types: "Indoor WiFi APs" and "Outdoor WiFi APs". The proposed onboarding fees are designed to be approximately 10% of the Manufacturer's Suggested Retail Price (MSRP) of the devices (please see below for specifics). The fees consist of a combination of HNT derived data credits and MOBILE tokens. It is expected that future devices of different classes will follow a similar pricing structure based on their respective MSRP. # Motivation @@ -21,9 +21,10 @@ As the Helium Network expands to accommodate various types of devices, it is cru ## Onboarding Fee Structure -Please note, this HIP does not define WiFi AP types and does intend to decouple from the definitions laid out in HIP-93. If a future HIP changes these definitions, this HIP intends to follow the guidance voted on by the MOBILE subDAO. +Please note, this HIP does not define WiFi AP types and does intend to decouple from the definitions laid out in HIP-93. If a future HIP changes these definitions, this HIP intends to follow the guidance voted on by the MOBILE subDAO. 1. **Indoor WiFi APs:** + - Cost:1,000,000 Data Credits ($10 worth of HNT) $10 in HNT derived data credits + $10 worth of MOBILE tokens -at the live Oracle price - Total Onboarding Fee: $20 @@ -33,7 +34,7 @@ Please note, this HIP does not define WiFi AP types and does intend to decouple ## MSRP-based Pricing -The proposed onboarding fees are based on the principle of being approximately 10% of the initial MSRP of the respective devices. This approach ensures a fair and consistent fee structure relative to the value of the devices being onboarded. It is important to note that this section is simply explaining the rationale behind the decision for the pricing and does advocate for any dynamic pricing. It is anticipated that future device classes introduced to the Helium Network will adopt a similar onboarding fee structure based on their own MSRP. This approach maintains consistency and predictability for device manufacturers, network operators, and other stakeholders. +The proposed onboarding fees are based on the principle of being approximately 10% of the initial MSRP of the respective devices. This approach ensures a fair and consistent fee structure relative to the value of the devices being onboarded. It is important to note that this section is simply explaining the rationale behind the decision for the pricing and does advocate for any dynamic pricing. It is anticipated that future device classes introduced to the Helium Network will adopt a similar onboarding fee structure based on their own MSRP. This approach maintains consistency and predictability for device manufacturers, network operators, and other stakeholders. ## Flexibility for Cost Reductions @@ -41,20 +42,20 @@ In the event of a significant reduction in the hardware costs associated with de # Rationale -The chosen onboarding fee structure balances the need for fair compensation, network expansion, and alignment with device value. The 10% approximation of MSRP serves as a reliable anchor for establishing these fees and ensuring their adaptability to changing circumstances. +The chosen onboarding fee structure balances the need for fair compensation, network expansion, and alignment with device value. The 10% approximation of MSRP serves as a reliable anchor for establishing these fees and ensuring their adaptability to changing circumstances. # Implementation -* This fee structure will be implemented in the Helium Network's onboarding process for the specified device types. This process will be handled within the maker app. Nova Labs has agreed to take on any engineering work required to pull the oracle price of Nova at the time of onboarding. The fees will be paid by the maker on behalf of the buyer otherwise referred to in HIP-53 as the “hotspot host.” -* Makers would be required to support this new onboarding fee process in their App -* Makers would be required to hold MOBILE in their Maker Wallet +- This fee structure will be implemented in the Helium Network's onboarding process for the specified device types. This process will be handled within the maker app. Nova Labs has agreed to take on any engineering work required to pull the oracle price of Nova at the time of onboarding. The fees will be paid by the maker on behalf of the buyer otherwise referred to in HIP-53 as the “hotspot host.” +- Makers would be required to support this new onboarding fee process in their App +- Makers would be required to hold MOBILE in their Maker Wallet # Drawbacks -* This fee structure is a bit more complicated to implement than the current onboarding process. -* There is a potential for a maker to either have insufficient DC or MOBILE to onboard devices. There is currently no mechanism to ensure that any maker has enough DC in their maker wallet and the authors believe another HIP should be written in the future to remedy this problem. Under the rules agreed to in HIP-53 a hotspot maker must stake 50M MOBILE tokens to be an approved maker. -* MOBILE prices are based on human oracles and not Python automated oracles. This creates a potential situation where if human oracles stop quoting prices we will be unable to calculate a price in MOBILE. - - The above is unlikely, as it would also mean any data transfer payments would not be calculated. +- This fee structure is a bit more complicated to implement than the current onboarding process. +- There is a potential for a maker to either have insufficient DC or MOBILE to onboard devices. There is currently no mechanism to ensure that any maker has enough DC in their maker wallet and the authors believe another HIP should be written in the future to remedy this problem. Under the rules agreed to in HIP-53 a hotspot maker must stake 50M MOBILE tokens to be an approved maker. +- MOBILE prices are based on human oracles and not Python automated oracles. This creates a potential situation where if human oracles stop quoting prices we will be unable to calculate a price in MOBILE. + - The above is unlikely, as it would also mean any data transfer payments would not be calculated. # Success Metrics diff --git a/0097-removing-manual-mobile-location-assertions.md b/0097-removing-manual-mobile-location-assertions.md index 753c4f04b..b7e9538a2 100644 --- a/0097-removing-manual-mobile-location-assertions.md +++ b/0097-removing-manual-mobile-location-assertions.md @@ -1,4 +1,4 @@ - # HIP 97: Removing Manual MOBILE Location Assertions +# HIP 97: Removing Manual MOBILE Location Assertions - Authors: [Andy Zyvoloski](https://github.com/heatedlime) & [Max Gold](https://github.com/maxgold91) - Start Date: 2023-10-02 @@ -7,45 +7,52 @@ - Tracking Issue: [#795](https://github.com/helium/HIP/issues/795) - Vote Requirements: veMOBILE Holders +## Summary -## Summary +This HIP proposes removing the MOBILE location assert fee for Helium 5G Hotspots and indoor Wi-Fi Hotspots, while having locations automatically updated on chain as they occur. -This HIP proposes removing the MOBILE location assert fee for Helium 5G Hotspots and indoor Wi-Fi Hotspots, while having locations automatically updated on chain as they occur. +## Motivation -## Motivation Paying a fee to manually self-assert a location change for Helium 5G Hotspots is wasteful, as the data obtained from self-assertions is unreliable as deployers can assert their equipment in a location other than where it's actually deployed without an impact to earnings. Additionally, indoor Wi-Fi AP's have the ability to self determine the location, bypassing the need for a manual assertion. ## Stakeholders + MOBILE Hotspot and indoor Wi-Fi AP Deployers - This stakeholder is impacted as it removes the cost and manual intervention needed to relocate their coverage devices. Helium (HNT) Token Holders - This stakeholder is impacted as less DC will be burned upon implementation. -Helium 5G Vendors/Manufactures - These stakeholders will be required to pay on chain transaction fees when Hotspots and indoor Wi-Fi APs move locations. +Helium 5G Vendors/Manufactures - These stakeholders will be required to pay on chain transaction fees when Hotspots and indoor Wi-Fi APs move locations. + +## Detailed Explanation -## Detailed Explanation -Currently, when Helium 5G Hotspots are asserted or re-asserted, the location of the Hotspot will update on the blockchain to note the Hotspot location at the res8 hex level. This location data is not used for any other purpose other than having the ability to display the hotspot location on a 3rd party explorer. This data is not useful, as it relies upon the self-assertion to be asserted in the correct spot, and does not show the assertion at the res12 hex level, which is used by the MOBILE subDAO. Further, currently, Hotspots do not need to be asserted at all, nor be asserted in the same location for the Hotspot to earn MOBILE rewards. +Currently, when Helium 5G Hotspots are asserted or re-asserted, the location of the Hotspot will update on the blockchain to note the Hotspot location at the res8 hex level. This location data is not used for any other purpose other than having the ability to display the hotspot location on a 3rd party explorer. This data is not useful, as it relies upon the self-assertion to be asserted in the correct spot, and does not show the assertion at the res12 hex level, which is used by the MOBILE subDAO. Further, currently, Hotspots do not need to be asserted at all, nor be asserted in the same location for the Hotspot to earn MOBILE rewards. -Additionally, unlike Helium 5G Hotspots, indoor Wi-Fi APs have the ability to self-assert their location through a third party vendor integrated within the Hotspot, which independently verifies the location. Eliminating the manual location assert process will give deployers a more enjoyable user experience, as after the AP is onboarded, the location will automatically report any location changes to the blockchain without manual intervention. +Additionally, unlike Helium 5G Hotspots, indoor Wi-Fi APs have the ability to self-assert their location through a third party vendor integrated within the Hotspot, which independently verifies the location. Eliminating the manual location assert process will give deployers a more enjoyable user experience, as after the AP is onboarded, the location will automatically report any location changes to the blockchain without manual intervention. This HIP will be implemented in three (3) phases, which are noted below: ### Phase 1 -Upon the passing of this HIP, the Helium Foundation will need to update the Helium multisig for the MOBILE Assertion Fee from 10 USD to 0 USD. + +Upon the passing of this HIP, the Helium Foundation will need to update the Helium multisig for the MOBILE Assertion Fee from 10 USD to 0 USD. ### Phase 2 -Phase 2 consists of reporting radio Spectrum Access System (SAS) and Wi-Fi Access Points location data at a res12 hex level to an oracle. Nova has agreed to undertake the work that is required to implement Phase 2. -As each indoor and outdoor Wi-Fi Access Point is placed or moved, a confidence score is generated from a third party vendor integration to determine how confident the system is that the automatically asserted location is accurate. To ensure that each Wi-Fi Access Point is given enough time to self determine its location and generate a confidence score, each time the Access Point is moved to a new location, or onboarded, it must first undergo a probationary period of 1 epoch, and within that epoch, have a distinct 12 valid heartbeats within the new location before it will be rewarded PoC. The probationary period will still allow the Access Point to be rewarded for data transfers. During each reported heartbeat, the confidence score at the time of the heartbeat will be recorded. The average confidence score captured from all heartbeats within the probationary period must be greater than or equal to 80%. If the average confidence score is not greater than or equal to 80% within the first probationary period of 1 epoch, and/or there was not at least 12 distinct, the Access Point will stay in a probationary period and not be eligible to earn PoC rewards (it will still earn data rewards) until the average confidence score per epoch is greater than or equal to 80%, and at least 12 distinct heartbeats occurred. +Phase 2 consists of reporting radio Spectrum Access System (SAS) and Wi-Fi Access Points location data at a res12 hex level to an oracle. Nova has agreed to undertake the work that is required to implement Phase 2. + +As each indoor and outdoor Wi-Fi Access Point is placed or moved, a confidence score is generated from a third party vendor integration to determine how confident the system is that the automatically asserted location is accurate. To ensure that each Wi-Fi Access Point is given enough time to self determine its location and generate a confidence score, each time the Access Point is moved to a new location, or onboarded, it must first undergo a probationary period of 1 epoch, and within that epoch, have a distinct 12 valid heartbeats within the new location before it will be rewarded PoC. The probationary period will still allow the Access Point to be rewarded for data transfers. During each reported heartbeat, the confidence score at the time of the heartbeat will be recorded. The average confidence score captured from all heartbeats within the probationary period must be greater than or equal to 80%. If the average confidence score is not greater than or equal to 80% within the first probationary period of 1 epoch, and/or there was not at least 12 distinct, the Access Point will stay in a probationary period and not be eligible to earn PoC rewards (it will still earn data rewards) until the average confidence score per epoch is greater than or equal to 80%, and at least 12 distinct heartbeats occurred. -After the probationary period, if it is detected that the Access Point has moved locations, it will then be required to undergo a new probationary period to establish a new confidence level. Movement detection is noted by a drop in confidence level for one or more heartbeats of 75% or lower. +After the probationary period, if it is detected that the Access Point has moved locations, it will then be required to undergo a new probationary period to establish a new confidence level. Movement detection is noted by a drop in confidence level for one or more heartbeats of 75% or lower. In any instances where a heartbeat is not generated or valid, that confidence score will not be reported, or counted towards any averages. ### Phase 3 + Phase 3 consists of moving location data on-chain. Once locations are on-chain, Wi-Fi Access Point manufactures will be required to pay for any on-chain fees associated with the assertions. ## Alternatives -One alternative is instead of reducing the assertion fee to 0 USD, would be to change how it is paid (i.e. MOBILE burn). However, prompting the user to pay a fee every time they change device locations may complicate the user experience. + +One alternative is instead of reducing the assertion fee to 0 USD, would be to change how it is paid (i.e. MOBILE burn). However, prompting the user to pay a fee every time they change device locations may complicate the user experience. ## Success Metrics + This HIP will be noted as successful once radio GPS coordinates from SAS and Wi-Fi Access Point location data are on chain and updated automatically. diff --git a/0098-mobile-subdao-quality-of-service-requirements.md b/0098-mobile-subdao-quality-of-service-requirements.md index 082387bcf..34441ee66 100644 --- a/0098-mobile-subdao-quality-of-service-requirements.md +++ b/0098-mobile-subdao-quality-of-service-requirements.md @@ -7,103 +7,99 @@ - Tracking Issue: [#797](https://github.com/helium/HIP/issues/797) - Vote Requirements: veMOBILE Holders - - - ## Related Prior HIPs: + [HIP 53](https://github.com/helium/HIP/blob/main/0053-mobile-dao.md) - Established the concept of the MOBILE SubDAO [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) - Established modeled proof of coverage, and modeled coverage points. -[HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) - Established limits to how many radios are rewarded proof of coverage rewards per res12 hex based on overlapping coverage. +[HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) - Established limits to how many radios are rewarded proof of coverage rewards per res12 hex based on overlapping coverage. [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) - Established Wi-Fi Access Points to be onboarded and rewarded to the Helium 5G network. - ## Summary + This Helium Improvement Proposal (HIP) sets quality of service (QOS) requirements that were noted within this [blog post](https://docs.helium.com/mobile/proof-of-coverage/). -## Motivation -Previous QOS requirements were implemented for the MOBILE network without community input and vote. As these requirements were previously implemented without a HIP, a HIP is being created to memorialize these QOS requirements. +## Motivation +Previous QOS requirements were implemented for the MOBILE network without community input and vote. As these requirements were previously implemented without a HIP, a HIP is being created to memorialize these QOS requirements. ## Stakeholders + MOBILE Deployers - MOBILE Deployers will be affected, as they will have to continue to meet speedtest and heartbeat requirements in order to earn rewards for Proof of Coverage (PoC). -Service Providers and Subscribers - Service Providers and Subscribers will benefit from this HIP, as it encourages MOBILE Deployers to have appropriate backhaul for their deployments, allowing for faster and smoother connections to the network. +Service Providers and Subscribers - Service Providers and Subscribers will benefit from this HIP, as it encourages MOBILE Deployers to have appropriate backhaul for their deployments, allowing for faster and smoother connections to the network. + +## Detailed Explanation -## Detailed Explanation -These QOS requirements only impact MOBILE Rewards for PoC, and do not affect rewards for the transfer of data. +These QOS requirements only impact MOBILE Rewards for PoC, and do not affect rewards for the transfer of data. ### Uptime Heartbeats + A "heartbeat" is data sent by the Wi-Fi Access point and or 5G Hotspot indicating that a connected Radio is authorized to transmit 5G coverage. Heartbeats occur every 60 seconds and transmit authorizations are valid for 240 seconds. This rolling overlap ensures that a Small Cell Radio can broadcast on an ongoing basis while allowing for brief interruptions. -To encourage reliable signal availability, 5G Hotspots and connected CBRS Small Cell Radios and Wi-Fi Access Points must generate at least one valid heartbeat per hour in 12 unique hours of the 24-hour Reward Period to earn Proof of Coverage (PoC) rewards. - - +To encourage reliable signal availability, 5G Hotspots and connected CBRS Small Cell Radios and Wi-Fi Access Points must generate at least one valid heartbeat per hour in 12 unique hours of the 24-hour Reward Period to earn Proof of Coverage (PoC) rewards. #### Heartbeat Reward Tiers Each Radio and Access Point is given a heartbeat multiplier of either 0 or 1. This multiplier only affects Proof of Coverage rewards. - Each Radio and Access Point is awarded 1 point for a valid heartbeat in each hour, with a maximum of 24 points in the Reward Period. All Radios and Access Points with at least 12 points in the 24-hour Reward Period are given a heartbeat multiplier of 1 and will be eligible to earn PoC MOBILE Rewards. ### Speed Test Reward Tiers -Many locations where connectivity is being deployed, including some rural areas, do not always have the high-speed Internet connectivity needed to meet the acceptable Internet requirements for Genesis rewards consistently. Note, the tiering and multipliers proposed below are only applicable to PoC rewards, MOBILE Rewards for data transfers are not affected. -Often these areas do not have good cellular coverage either. That's why it is essential to incentivize Helium deployments in less well-connected areas. +Many locations where connectivity is being deployed, including some rural areas, do not always have the high-speed Internet connectivity needed to meet the acceptable Internet requirements for Genesis rewards consistently. Note, the tiering and multipliers proposed below are only applicable to PoC rewards, MOBILE Rewards for data transfers are not affected. +Often these areas do not have good cellular coverage either. That's why it is essential to incentivize Helium deployments in less well-connected areas. ### Speed Test Reward Tiers -Many locations where connectivity is being deployed, including some rural areas, do not always have the high-speed Internet connectivity needed to meet the acceptable Internet requirements for Genesis rewards consistently. Note, the tiering and multipliers proposed below are only applicable PoC rewards, MOBILE Rewards for data transfers are not affected. -Often these areas do not have good cellular coverage either. That's why iit is essential to incentivize Helium deployments in less well-connected areas. +Many locations where connectivity is being deployed, including some rural areas, do not always have the high-speed Internet connectivity needed to meet the acceptable Internet requirements for Genesis rewards consistently. Note, the tiering and multipliers proposed below are only applicable PoC rewards, MOBILE Rewards for data transfers are not affected. +Often these areas do not have good cellular coverage either. That's why iit is essential to incentivize Helium deployments in less well-connected areas. Speed Test results are categorized into one of four Tiers - Good, Acceptable, Degraded, Poor, and Fail. Please note, this HIP proposes changing the name of the 1X speedtest multiplier to "Good", and adding a new 0.75X multiplier for "Acceptable". Please see the table below. - -|Speed Test Tier| Speedtest Multiplier| Requirement (speeds in Mbps, latency in ms) | -|---------------|---------------------|----------------------------------------------| -| Good | 1.00X |100+ Download, AND 10+ Upload, AND <50 Latency| -| Acceptable | 0.75X |75+ Download, AND 8+ Upload, AND <60 Latency | -| Degraded | 0.50X |50+ Download, AND 5+ Upload, AND <75 Latency | -| Poor | 0.25X |30+ Download, AND 2+ Upload, AND <100 Latency | -| Fail | 0.00X |<30 Download, OR <2 Upload, OR >100 Latency | - - +| Speed Test Tier | Speedtest Multiplier | Requirement (speeds in Mbps, latency in ms) | +| --------------- | -------------------- | ---------------------------------------------- | +| Good | 1.00X | 100+ Download, AND 10+ Upload, AND <50 Latency | +| Acceptable | 0.75X | 75+ Download, AND 8+ Upload, AND <60 Latency | +| Degraded | 0.50X | 50+ Download, AND 5+ Upload, AND <75 Latency | +| Poor | 0.25X | 30+ Download, AND 2+ Upload, AND <100 Latency | +| Fail | 0.00X | <30 Download, OR <2 Upload, OR >100 Latency | Tiered Speed Test values are used as a multiplier in Rewards calculations as follows: Speed Test Results are put into Tiers based on the minimum value of each Download, Upload, and Latency (logical AND). Speed Test results that do not meet the minimum requirements for any Download, Upload, or Latency are considered to have Failed and are not eligible for PoC Rewards until the Speed Test Average is improved (logical OR). -If a device (Radio and or Wi-Fi Access Point) is given a speed tier of “Fail”, the device will stop broadcasting a signal until a speed test tier of “Poor” or greater is given to that device. +If a device (Radio and or Wi-Fi Access Point) is given a speed tier of “Fail”, the device will stop broadcasting a signal until a speed test tier of “Poor” or greater is given to that device. #### Multiplier Effect + Upon implementation of [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md), this multiplier will be applied the total modeled coverage points received by that radio/access point. The multipliers will be used within the following order: Heartbeat Multiplier -Speed Test Multiplier +Speed Test Multiplier Any other multipliers, such as the ones approved in [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) (Upon implementation of [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md), this multiplier will be applied the total modeled coverage points received by that radio/access point.) See the table below for examples of how the multipliers will affect modeled coverage points (MCP): +| Device | Initial MCP | Heartbeat Multiplier | Speed Test Multiplier | HIP 85 Multiplier | Total MCP | +| ------ | ----------- | -------------------- | --------------------- | ----------------- | --------- | +| A | 1,000 | 1.00X | 1.00X | 1.00X | 1,000.00 | +| B | 1,000 | 1.00X | 0.75X | 0.75X | 562.50 | +| C | 1,000 | 1.00X | 0.50X | 1.00X | 500.00 | +| D | 1,000 | 1.00X | 0.00X | 1.00X | 0.00 | +| E | 1,000 | 0.00X | 1.00X | 1.00X | 0.00 | -|Device|Initial MCP|Heartbeat Multiplier| Speed Test Multiplier| HIP 85 Multiplier| Total MCP| -|------|-----------|--------------------|----------------------|------------------|----------| -| A | 1,000 | 1.00X | 1.00X | 1.00X | 1,000.00 | -| B | 1,000 | 1.00X | 0.75X | 0.75X | 562.50 | -| C | 1,000 | 1.00X | 0.50X | 1.00X | 500.00 | -| D | 1,000 | 1.00X | 0.00X | 1.00X | 0.00 | -| E | 1,000 | 0.00X | 1.00X | 1.00X | 0.00 | +### Radio Health Metrics +In order for CBRS Radios to earn rewards for the epoch, the radio must but authorized by SAS and on-air. If these metrics are not met for 12 or more heartbeats during an epoch, that radio will not earn PoC rewards for that epoch. -### Radio Health Metrics -In order for CBRS Radios to earn rewards for the epoch, the radio must but authorized by SAS and on-air. If these metrics are not met for 12 or more heartbeats during an epoch, that radio will not earn PoC rewards for that epoch. +### Location Trust Score -### Location Trust Score As per [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md), after an initial assertion of its location during Wi-Fi access point onboarding, the system will periodically verify the access point's location. This is to prevent situations in which the Wi-Fi access point is onboarded in one location and then moved to a different location. In the current implementation the Location Validation service performs this verification twice per day. The timestamp of the last verification and the last derived lat/lng are subsequently included in the heartbeats submitted by the Wi-Fi access point to the Oracles. The Mobile Verifier oracle, as part of validating each heartbeat, will validate the verified location and compare the provided lat/lng to the onchain asserted location and as per the rules defined in [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md), calculate a location trust score. In the current implementation, as the verified location can potentially change from one heartbeat to the next, the score is calculated and assigned on a per heartbeat basis. Then at the time of rewards calculation the Mobile Verifier oracle will take an average of the location trust scores assigned to the verified heartbeats and this averaged score will form the location trust score multiplier for the Wi-Fi access point for that epoch. @@ -111,43 +107,45 @@ The Mobile Verifier oracle, as part of validating each heartbeat, will validate Example Heartbeats The example below illustrates the location trust score calculated for 24 heartbeats received from an access point over the course of one epoch. -heartbeat_number assigned location trust score - -|heartbeat_number|assigned location trust score| -|----------------|-----------------------------| -|1 |0.25 | -|2 |0.25 | -|3 |0.25 | -|4 |0.25 | -|5 |0.25 | -|6 |0.25 | -|7 |0.25 | -|8 |0.25 | -|9 |0.25 | -|10 |0.25 | -|11 |1.00 | -|12 |1.00 | -|13 |1.00 | -|14 |1.00 | -|15 |1.00 | -|16 |1.00 | -|17 |1.00 | -|18 |1.00 | -|19 |1.00 | -|20 |1.00 | -|21 |1.00 | -|22 |1.00 | -|23 |1.00 | -|24 |1.00 | +heartbeat_number assigned location trust score + +| heartbeat_number | assigned location trust score | +| ---------------- | ----------------------------- | +| 1 | 0.25 | +| 2 | 0.25 | +| 3 | 0.25 | +| 4 | 0.25 | +| 5 | 0.25 | +| 6 | 0.25 | +| 7 | 0.25 | +| 8 | 0.25 | +| 9 | 0.25 | +| 10 | 0.25 | +| 11 | 1.00 | +| 12 | 1.00 | +| 13 | 1.00 | +| 14 | 1.00 | +| 15 | 1.00 | +| 16 | 1.00 | +| 17 | 1.00 | +| 18 | 1.00 | +| 19 | 1.00 | +| 20 | 1.00 | +| 21 | 1.00 | +| 22 | 1.00 | +| 23 | 1.00 | +| 24 | 1.00 | In the example above, the average would be 0.6875, and wojld be utilized during rewards. +## Rationale -## Rationale -As the Helium 5G network matures, it’s vitally important that the quality of the network and deployments provide usable and consistent coverage. +As the Helium 5G network matures, it’s vitally important that the quality of the network and deployments provide usable and consistent coverage. ## Deployment Impact -Protocol engineers will have to change the speedtest requirements to incorporate the new "Acceptable" multiplier of 0.75X upon passing. + +Protocol engineers will have to change the speedtest requirements to incorporate the new "Acceptable" multiplier of 0.75X upon passing. ## Success Metrics + As most of what is written in this HIP has already been previously implemented, this HIP will be considered successful if it is passed. If this HIP does not pass, any quality of service metrics already previously established outside of a HIP process, such as speed test and heartbeat requirements must immediately be removed from the Helium 5G network. diff --git a/0100-deploy-eu868-region-plan-to-the-majority-of-africa.md b/0100-deploy-eu868-region-plan-to-the-majority-of-africa.md index 1aca38e2b..2fcecfcfb 100644 --- a/0100-deploy-eu868-region-plan-to-the-majority-of-africa.md +++ b/0100-deploy-eu868-region-plan-to-the-majority-of-africa.md @@ -1,11 +1,11 @@ # HIP 100: Deploy EU868 Region Plan to the Majority of Africa -* Author: [Adrian Clint](https://github.com/waveform06) and [Helium Foundation](https://github.com/dewi-alliance) -* Start Date: 2023-09-22 -* Category: Technical -* Original HIP PR: [#789](https://github.com/helium/HIP/pull/789) -* Tracking Issue: [#809](https://github.com/helium/HIP/issues/809) -* Vote Requirements: veIOT Holders +- Author: [Adrian Clint](https://github.com/waveform06) and [Helium Foundation](https://github.com/dewi-alliance) +- Start Date: 2023-09-22 +- Category: Technical +- Original HIP PR: [#789](https://github.com/helium/HIP/pull/789) +- Tracking Issue: [#809](https://github.com/helium/HIP/issues/809) +- Vote Requirements: veIOT Holders ## Summary @@ -13,11 +13,11 @@ This HIP recommends that the community provisionally sets the currently unspecif As a summary, this HIP proposes: -* All Africa region countries with an “Unknown” LoRaWAN regional frequency plan are set to EU868 per ETSI [EN300.220-2]. -* All Africa region countries set to EU433 as the default LoRaWAN regional frequency parameter are set to EU868 on the Helium network. -* All Africa region countries with EU433 or an 800MHz based LoRaWAN regional frequency parameter are set to EU868 on the Helium network. -* The network, through the Helium Foundation and other participants, communicate with Telecom Regulatory Authorities in these countries and confirm Helium provisionally complies with the EU868 regional parameter recommendation from the Africa Telecoms Union. -* The network, through the Helium Foundation and other participants, present the approach to the LoRa Alliance Regulations and Regional Parameters Working Group. +- All Africa region countries with an “Unknown” LoRaWAN regional frequency plan are set to EU868 per ETSI [EN300.220-2]. +- All Africa region countries set to EU433 as the default LoRaWAN regional frequency parameter are set to EU868 on the Helium network. +- All Africa region countries with EU433 or an 800MHz based LoRaWAN regional frequency parameter are set to EU868 on the Helium network. +- The network, through the Helium Foundation and other participants, communicate with Telecom Regulatory Authorities in these countries and confirm Helium provisionally complies with the EU868 regional parameter recommendation from the Africa Telecoms Union. +- The network, through the Helium Foundation and other participants, present the approach to the LoRa Alliance Regulations and Regional Parameters Working Group. ## Motivation @@ -25,7 +25,7 @@ Africa shows growing LoRaWAN demand, yet has fractional or unspecified spectrum There's a rising interest from organizations aiming to deploy compatible infrastructure in Africa. They are seeking guidance on the suitable frequency plan, especially with the uncertainty around the legacy EU433 plan. Certain countries are eager to determine the appropriate legal spectrum for operation but may benefit from additional support. -The immediate objective is to promote EU868 as a provisional standard, enabling Helium deployers to roll out EU868 Hotspots across the African continent. By introducing this provisional amendment to the Helium network, there's an opportunity to influence changes in the LoRa Alliance's LoRaWAN Regional Parameters specifications. Major African countries like South Africa, Nigeria, Egypt and Kenya already utilize EU868. However, several African countries have yet to establish regulations specific to LoRaWAN. The EU868 plan is gaining traction as a potential global standard for IoT devices, particularly in the International Telecommunication Union (ITU) Region 1 (EMEA). The trigger countries for this HIP are Malawi, Liberia, The Democratic Republic of Congo, The Republic of Congo, and Ghana which the Foundation are working with on the ground through the One Planet Education Network team to establish local LoRaWAN connectivity on EU868 in these countries. +The immediate objective is to promote EU868 as a provisional standard, enabling Helium deployers to roll out EU868 Hotspots across the African continent. By introducing this provisional amendment to the Helium network, there's an opportunity to influence changes in the LoRa Alliance's LoRaWAN Regional Parameters specifications. Major African countries like South Africa, Nigeria, Egypt and Kenya already utilize EU868. However, several African countries have yet to establish regulations specific to LoRaWAN. The EU868 plan is gaining traction as a potential global standard for IoT devices, particularly in the International Telecommunication Union (ITU) Region 1 (EMEA). The trigger countries for this HIP are Malawi, Liberia, The Democratic Republic of Congo, The Republic of Congo, and Ghana which the Foundation are working with on the ground through the One Planet Education Network team to establish local LoRaWAN connectivity on EU868 in these countries. ![itu1 map](files/0100/itu1.png) @@ -35,27 +35,26 @@ A proactive step is essential to clarify the regulatory landscape and offer supp ## Stakeholders -* Prospective and current deployers of LoRaWAN Gateways and Sensors in each of the countries specified in this HIP. Example: [One Planet Education Network](https://www.oneplaneteducation.com/) (OPEN) -* The LoRaWAN Alliance Regulatory and Regional Parameters Working Groups (Foundation has been in contact) -* The African Telecoms Union (ATU) (Foundation has been in contact) -* The Regulatory Telecoms Authority in each of the countries in Tables 1,2 & 3 -* African Telecoms and Commercial and Economic organizations, including [ECOWAS](https://ecowas.int/ecowas-member-states-adopt-common-positions-on-agenda-items-of-the-world-radiocommunications-conference-2023-wrc-23/), [CRASA](https://www.crasa.org/), [ASMG](https://www.itu.int/en/ITU-R/terrestrial/broadcast/ASMG/Pages/default.aspx), and others listed [here](https://en.wikipedia.org/wiki/Regional_Economic_Communities). -* Other public or private LoRaWAN networks considering similar or different regional frequency plans. -* Hotspot owners and operators in affected regions and other nations. +- Prospective and current deployers of LoRaWAN Gateways and Sensors in each of the countries specified in this HIP. Example: [One Planet Education Network](https://www.oneplaneteducation.com/) (OPEN) +- The LoRaWAN Alliance Regulatory and Regional Parameters Working Groups (Foundation has been in contact) +- The African Telecoms Union (ATU) (Foundation has been in contact) +- The Regulatory Telecoms Authority in each of the countries in Tables 1,2 & 3 +- African Telecoms and Commercial and Economic organizations, including [ECOWAS](https://ecowas.int/ecowas-member-states-adopt-common-positions-on-agenda-items-of-the-world-radiocommunications-conference-2023-wrc-23/), [CRASA](https://www.crasa.org/), [ASMG](https://www.itu.int/en/ITU-R/terrestrial/broadcast/ASMG/Pages/default.aspx), and others listed [here](https://en.wikipedia.org/wiki/Regional_Economic_Communities). +- Other public or private LoRaWAN networks considering similar or different regional frequency plans. +- Hotspot owners and operators in affected regions and other nations. Communication will be established with all relevant authorities and organizations. - ## Detailed Explanation The proposed changes to regional frequency plans, based on the LoRaWAN Alliance's RP2-1.0.4 LoRaWAN Regional Parameters document, will be integrated into the regions.csv file and the corresponding .geojson files. The changes are aligned with the latest discussions, as documented in this [github issue](https://github.com/dewi-alliance/hplans/issues/51) and outlined in the tables below. ![tables 1-5](files/0100/tables1-5v3.png) -_Note: The countries marked with a * are members of CRASA and frequency harmonization amongst members is a goal of this organization._ +_Note: The countries marked with a \* are members of CRASA and frequency harmonization amongst members is a goal of this organization._ **Table 1**: Countries with no defined regional frequency plan (Unknown) will be set to EU868 - ATU discussed any countries wanting to define a regional frequency and looking for a recommendation for one from the ATU will have EU868 proposed -*Note: Eritrea and South Sudan do not appear to be or have been members of the ATU or CRASA - TBC. Some other countries need to have membership status confirmed* +_Note: Eritrea and South Sudan do not appear to be or have been members of the ATU or CRASA - TBC. Some other countries need to have membership status confirmed_ **Table 2**: Countries with the EU433 plan defined will be set to EU868 - as per reasoning for Table 1 and because the LoRaWAN Alliance recommend no new EU433 installations or support. Helium HIP19 has not approved any EU433 hotspots so far. @@ -66,11 +65,9 @@ This would support [hplans github issue 27](https://github.com/dewi-alliance/hpl **Table 5**: Saint Helena and its associated islands have been added as a proposal in this HIP though officially outside the Africa Region but is adjacent to other African islands and is a UK (EU868) Overseas Territory. It can be assumed that it would also be EU868 as African Islands that are French Overseas Territories are defined as EU868. And it exists within ITU Zone 1. - --- -Other countries such as Uganda (AS923-1), Tanzania (AS923-1) and Niger (IN865) have specifications other than EU868. Lesotho, Libya and Sudan have frequency spectrum specifications that need further review before deploying EU868. It would be expected that over time all these countries harmonize with the proposed region plan of the ATU for EU868, this HIP does not describe a current attempt to change them, but proposes to add EU868 to the list of their allowable regional frequencies in the Helium regions.csv file. - +Other countries such as Uganda (AS923-1), Tanzania (AS923-1) and Niger (IN865) have specifications other than EU868. Lesotho, Libya and Sudan have frequency spectrum specifications that need further review before deploying EU868. It would be expected that over time all these countries harmonize with the proposed region plan of the ATU for EU868, this HIP does not describe a current attempt to change them, but proposes to add EU868 to the list of their allowable regional frequencies in the Helium regions.csv file. The Southern African Development Community (SADC)’s regulatory arm - the Communications Regulators' Association of Southern Africa (CRASA) has a [frequency allocation plan](https://www.crasa.org/post-articles/sadc-radio-frequency-spectrum-allocation-plan-rfsap) common to all member countries. And members are urged to follow this “In order to achieve significant harmonization… as far as is practically possible.” @@ -97,9 +94,9 @@ Considering the pace of technological advancements, waiting for each country to **Waiting for the LoRaWAN Alliance to set the frequency** -The approach is significantly different from the LoRa Alliance. The Alliance primarily works with individual African countries on a case-by-case basis and has not contacted the ATU to discuss an overall harmonious Africa plan. Progress has been slow, especially for the smaller countries and it could literally take a decade before all African countries have finalized regulations. The Helium plan is to drastically shorten that time with provisional approval by promoting a suggested regional plan rather than waiting to approve a regional plan for one country at a time. +The approach is significantly different from the LoRa Alliance. The Alliance primarily works with individual African countries on a case-by-case basis and has not contacted the ATU to discuss an overall harmonious Africa plan. Progress has been slow, especially for the smaller countries and it could literally take a decade before all African countries have finalized regulations. The Helium plan is to drastically shorten that time with provisional approval by promoting a suggested regional plan rather than waiting to approve a regional plan for one country at a time. -The LoRaWAN Alliance Regulatory and Regional Parameters Working Groups are supportive of our efforts to speed up deployment and standardization of regional regulation in the African region. +The LoRaWAN Alliance Regulatory and Regional Parameters Working Groups are supportive of our efforts to speed up deployment and standardization of regional regulation in the African region. ## Deployment Impact @@ -107,20 +104,20 @@ Helium uses the configuration files at [https://github.com/dewi-alliance/hplans] The geojson does not contain the channel plan and spectrum definitions; it only contains the geographic regions they apply to. -* The regions.csv file is the table of frequencies and the .geojson files visually show the countries that each region code is applied to. -* The current file status is the configuration to be applied at the next release -* The last release was on the [2nd of June 2023](https://github.com/helium/lorawan-h3/releases) and uses this set of [regional frequency parameters and plans](https://github.com/dewi-alliance/hplans/tree/e2a3a57a86c71e05064037576b3bc5f910ef5267) -* [Lw-generator](https://github.com/helium/lorawan-h3/tree/region_params_2023.06.02) generates uber h3 files for helium to use from the geojson files +- The regions.csv file is the table of frequencies and the .geojson files visually show the countries that each region code is applied to. +- The current file status is the configuration to be applied at the next release +- The last release was on the [2nd of June 2023](https://github.com/helium/lorawan-h3/releases) and uses this set of [regional frequency parameters and plans](https://github.com/dewi-alliance/hplans/tree/e2a3a57a86c71e05064037576b3bc5f910ef5267) +- [Lw-generator](https://github.com/helium/lorawan-h3/tree/region_params_2023.06.02) generates uber h3 files for helium to use from the geojson files There are a small number of hotspots in Algeria Switching from AS923 to EU868 which means their hardware is now obsolete, unless the hotspots can have their LoRaWAN Concentrator replaced, ### Documentation/knowledge updates -* [https://docs.helium.com/iot/lorawan-region-plans](https://docs.helium.com/iot/lorawan-region-plans) will be updated - * A note will be added to each country affected, to a copy of this HIP and the decision and suitable processes for local regulatory authorities to use the frequency. - * Countries not yet confirmed as EU868 by the LoRa Alliance will be noted as provisional proposed - * Current status updates with countries viewing the EU868 proposal will be noted on this page or subpage -* [https://github.com/dewi-alliance/hplans](https://github.com/dewi-alliance/hplans) will match the docs site +- [https://docs.helium.com/iot/lorawan-region-plans](https://docs.helium.com/iot/lorawan-region-plans) will be updated + - A note will be added to each country affected, to a copy of this HIP and the decision and suitable processes for local regulatory authorities to use the frequency. + - Countries not yet confirmed as EU868 by the LoRa Alliance will be noted as provisional proposed + - Current status updates with countries viewing the EU868 proposal will be noted on this page or subpage +- [https://github.com/dewi-alliance/hplans](https://github.com/dewi-alliance/hplans) will match the docs site Any country's authorities confirming they do not want to provisionally or actively deploy EU868 will be returned using the above processes to the LoRaWAN frequency plan definition in the latest LoRa Alliance Regional Parameters documentation. And any known deployers in that country in contact with the Foundation will be notified of the return to Alliance definitions. @@ -140,10 +137,9 @@ A further success metric will be the willingness of other LoRaWAN network operat ## References -* LoRaWAN Alliance's [RP2-1.0.4 LoRaWAN Regional Parameters](https://resources.lora-alliance.org/technical-specifications/rp002-1-0-4-regional-parameters) -* ITU [Radio Regulations 2020](https://www.itu.int/hub/publication/r-reg-rr-2020/) -* ATU's [African Spectrum Allocation Plan](https://atuuat.africa/african-spectrum-allocation-plan-afrisap/) (AfriSAP) See page 61 for 862 to 890 Mhz -* CRASA’s [Radio Frequency Spectrum Allocation Plan](https://www.crasa.org/post-articles/sadc-radio-frequency-spectrum-allocation-plan-rfsap) (RFSAP) -* CEP [ERC Recommendation 70-03](https://docdb.cept.org/download/4358) Relating to the use of Short Range Devices (SRD) -* ETSI [EN 300 220-2](https://www.etsi.org/deliver/etsi_en/300200_300299/30022002/03.02.01_60/en_30022002v030201p.pdf) V3.2.1 (2018-06) Short Range Devices (SRD) operating in the frequency range 25 MHz to 1 000 MHz - +- LoRaWAN Alliance's [RP2-1.0.4 LoRaWAN Regional Parameters](https://resources.lora-alliance.org/technical-specifications/rp002-1-0-4-regional-parameters) +- ITU [Radio Regulations 2020](https://www.itu.int/hub/publication/r-reg-rr-2020/) +- ATU's [African Spectrum Allocation Plan](https://atuuat.africa/african-spectrum-allocation-plan-afrisap/) (AfriSAP) See page 61 for 862 to 890 Mhz +- CRASA’s [Radio Frequency Spectrum Allocation Plan](https://www.crasa.org/post-articles/sadc-radio-frequency-spectrum-allocation-plan-rfsap) (RFSAP) +- CEP [ERC Recommendation 70-03](https://docdb.cept.org/download/4358) Relating to the use of Short Range Devices (SRD) +- ETSI [EN 300 220-2](https://www.etsi.org/deliver/etsi_en/300200_300299/30022002/03.02.01_60/en_30022002v030201p.pdf) V3.2.1 (2018-06) Short Range Devices (SRD) operating in the frequency range 25 MHz to 1 000 MHz diff --git a/0101-equalizing-poc-rewards-across-wifi-and-cbrs.md b/0101-equalizing-poc-rewards-across-wifi-and-cbrs.md index c8ad4f868..9f730c484 100644 --- a/0101-equalizing-poc-rewards-across-wifi-and-cbrs.md +++ b/0101-equalizing-poc-rewards-across-wifi-and-cbrs.md @@ -1,4 +1,4 @@ -# HIP 101: Equalizing POC Rewards Across Wi-Fi and CBRS +# HIP 101: Equalizing POC Rewards Across Wi-Fi and CBRS - Author(s): [@zer0tweets](https://github.com/zer0tweets) (Nova Labs, Inc.) - Start Date: 2023-12-09 @@ -9,55 +9,52 @@ ## Summary -This Helium Improvement Proposal (HIP) suggests equalizing Proof-of-Coverage (PoC) rewards for Wi-Fi Indoor and Outdoor Hotspots with that of CBRS hotspots. +This Helium Improvement Proposal (HIP) suggests equalizing Proof-of-Coverage (PoC) rewards for Wi-Fi Indoor and Outdoor Hotspots with that of CBRS hotspots. ## Related Prior HIPs -* [HIP 74](0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage for the MOBILE subDAO. +- [HIP 74](0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage for the MOBILE subDAO. -* [HIP 85](0085-mobile-hex-coverage-limit.md) changed the limit of outdoor radios eligible for PoC rewards from 5 to 3, and introduced ranking multiplier. +- [HIP 85](0085-mobile-hex-coverage-limit.md) changed the limit of outdoor radios eligible for PoC rewards from 5 to 3, and introduced ranking multiplier. -* [HIP 93](0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced the addition of Wi-Fi Access Points and certain limitations. +- [HIP 93](0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced the addition of Wi-Fi Access Points and certain limitations. ## Motivation [HIP 93](0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced Wi-Fi Access Points (APs) as a new way to stay connected to the Helium Mobile Network and proposed a PoC algorithm for Wi-Fi Hotspots, largely mirroring the reward weights of CBRS radios. However, CBRS radios currently provide less utility on the network. Specifically: -- There is no immediate solution for Android phones to seamlessly hand-off data sessions between macro network like T-Mobile and CBRS; + +- There is no immediate solution for Android phones to seamlessly hand-off data sessions between macro network like T-Mobile and CBRS; - There is a way to do this for iOS17 devices, but, so far, this only works on iPhones 13+ and requires an install of a geo-fencing profile by the end user; - CBRS radios have no ability to provide guest / public Wi-Fi service and will always require an installation of additional, second CBRS sim on a client device to be accessible. Wi-Fi Hotspots solve all of the above, thereby providing more utility for the Helium Mobile Network, yet are currently compensated for PoC based on modeled coverage, which calculates rewards purely in terms of geographic coverage and gives no consideration to greater overall utility of Wi-Fi. This, in turn, results in unfairly lower PoC rewards for the Wi-Fi hotspot deployers since Wi-Fi hotspots are less capable than CBRS at covering large number of res12 hexes. -For the Helium Mobile Network to succeed, it is important to accelerate deployment of Wi-Fi Hotspots, which currently provide higher likelihood of real data usage on the Network for the reasons described above. - +For the Helium Mobile Network to succeed, it is important to accelerate deployment of Wi-Fi Hotspots, which currently provide higher likelihood of real data usage on the Network for the reasons described above. ## Stakeholders -- Deployers - this HIP will make it more fair for deployers who are able to deploy a more optimal Wi-Fi AP setup than current existing setups. -- Subscribers - Subscribers may see more coverage of Wi-Fi access as this HIP will encourage Wi-Fi deployments to not be bunched together. +- Deployers - this HIP will make it more fair for deployers who are able to deploy a more optimal Wi-Fi AP setup than current existing setups. +- Subscribers - Subscribers may see more coverage of Wi-Fi access as this HIP will encourage Wi-Fi deployments to not be bunched together. - Service Providers - if better Wi-Fi coverage is added due to this HIP, Service Providers will see an increased amount of data being offloaded onto the Helium Mobile Network. ## Detailed Explanation Based on the benefits of Wi-Fi over CBRS explained in the motivation section above, we propose to equalize POC for CBRS and Wi-Fi by increasing Wi-Fi PoC reward points for 180 days after implementation as follows: -- 1.5x for Indoor Wi-Fi. I.e. 600 rewards points for Wi-Fi AP vs. current 400 reward points; +- 1.5x for Indoor Wi-Fi. I.e. 600 rewards points for Wi-Fi AP vs. current 400 reward points; - 2.5x for Outdoor Wi-Fi AP per each covered hex. I.e. 1250 (instead of 500) points for templated coverage and the following points per modeled coverage hex - -| | Tier 1 | Tier 2 | Tier 3 | Tier 4 | -| ----------------------------- | ---------------- | ----------------------------- | ---------------------------- | ------------------- | -| **Potential RSSI** | $RSSI > -65 dBm$ | $-65 dBm \ge RSSI > -75 dBm$ | $-75 dBm \ge RSSI > -85 dBm$ | $RSSI \le -85 dBm$ | -| **Potential Signal Level** | High | Medium | Low | None | -| **Estimated Coverage Points** | 40 | 20 | 10 | 0 | - - +| | Tier 1 | Tier 2 | Tier 3 | Tier 4 | +| ----------------------------- | ---------------- | ---------------------------- | ---------------------------- | ------------------ | +| **Potential RSSI** | $RSSI > -65 dBm$ | $-65 dBm \ge RSSI > -75 dBm$ | $-75 dBm \ge RSSI > -85 dBm$ | $RSSI \le -85 dBm$ | +| **Potential Signal Level** | High | Medium | Low | None | +| **Estimated Coverage Points** | 40 | 20 | 10 | 0 | ## Outdoor Coverage Limit -To prevent the stacking of outdoor Wi-Fi AP's, this HIP limits modeled coverage rewards to the top two (2) outdoor Wi-Fi signals per res12 hex. If there is a tie, coverage claim time (explained below) is used to determine which top two will be rewarded. -If there are more than 2 Outdoor Wi-Fi AP signals within the same res12 hex with the same signal strength, the `coverage_claim_time` value will be used as a tiebreaker where `coverage_claim_time` is the timestamp when the Wi-Fi AP was asserted in that hex. To prevent rewarding "dead" Wi-Fi APs, we propose to reset `coverage_claim_time` if the Wi-Fi AP was not generating a Heartbeat for more than 72 hours and use the time of the last Heartbeat as the new `coverage_claim_time`. +To prevent the stacking of outdoor Wi-Fi AP's, this HIP limits modeled coverage rewards to the top two (2) outdoor Wi-Fi signals per res12 hex. If there is a tie, coverage claim time (explained below) is used to determine which top two will be rewarded. +If there are more than 2 Outdoor Wi-Fi AP signals within the same res12 hex with the same signal strength, the `coverage_claim_time` value will be used as a tiebreaker where `coverage_claim_time` is the timestamp when the Wi-Fi AP was asserted in that hex. To prevent rewarding "dead" Wi-Fi APs, we propose to reset `coverage_claim_time` if the Wi-Fi AP was not generating a Heartbeat for more than 72 hours and use the time of the last Heartbeat as the new `coverage_claim_time`. ## Drawbacks @@ -65,7 +62,7 @@ Implementing this proposal will decrease long term PoC rewards for CBRS Hotspot ## Rationale and Alternatives -An alternative would be to introduce a temporary multiplier to the PoC rewards based on radio type, which can be quickly adjusted, within some limits, by voting of a Mobile Working Group. +An alternative would be to introduce a temporary multiplier to the PoC rewards based on radio type, which can be quickly adjusted, within some limits, by voting of a Mobile Working Group. The issue with CBRS handovers is on its way of being solved and phone manufacturers are moving towards improving CBRS UX across the board, therefore future similar adjustments to rewards based on the quality of the UX for a particular radio technology may be needed. Doing such adjustments through Mobile Working Group voting vs. a dedicated HIP every time could be a viable alternative. @@ -75,8 +72,8 @@ None. ## Deployment Impact -Implementation of this HIP is extremely simple and will involve updating a few variables in the Mobile Oracle to calculate Wi-Fi PoC rewards using the new reward points scheme, described above. If voted, it passed, it is expected that implementation of this HIP should not take longer than 1 week. Upon approval by community vote Nova Labs will complete the implementation and deployment of this HIP, collaborating with Helium Foundation as required. +Implementation of this HIP is extremely simple and will involve updating a few variables in the Mobile Oracle to calculate Wi-Fi PoC rewards using the new reward points scheme, described above. If voted, it passed, it is expected that implementation of this HIP should not take longer than 1 week. Upon approval by community vote Nova Labs will complete the implementation and deployment of this HIP, collaborating with Helium Foundation as required. ## Success Metrics -This HIP is successful if we see the number of Wi-Fi Hotspots being actived on the Network continue to outpace that of CBRS radios, resulting in higher paid data usage and more HNT emitted into MOBILE subDAO treasury. +This HIP is successful if we see the number of Wi-Fi Hotspots being actived on the Network continue to outpace that of CBRS radios, resulting in higher paid data usage and more HNT emitted into MOBILE subDAO treasury. diff --git a/0102-helium-educational-lns.md b/0102-helium-educational-lns.md index 6fdf4dae3..ae273f011 100644 --- a/0102-helium-educational-lns.md +++ b/0102-helium-educational-lns.md @@ -18,11 +18,13 @@ The goals of the changes proposed in this HIP are to foster learning and experim As a broad overview, these bulleted sections highlight the impact areas and opportunities. **Future of Foundation Console** + - Foundation Console will continue to operate. However, no new accounts will be added. Existing users will be able to continue to fund their accounts and operate up to 10 devices. The operation of Foundation Console remains under the purview of the Helium Foundation. - The home page of Console will be restyled to serve as an index of other known public LNSs in the ecosystem, leveraging the list maintained at [docs.helium.com](https://docs.helium.com/iot/find-a-lns-provider). - Moving the community past Foundation Console drives growth across the broader ecosystem of LNS operators. **Continued Trial & Educational Access** + - A new LNS is created using ChirpStack since the platform drives the underlying infrastructure of current public LNS offerings. It is configured for simple sign up and devices are permitted to operate for one day. - Eventually, this offering can grow into an ecosystem of trial services, such as instances of ThingPark Community or others, all following the same trial model as outlined for ChirpStack. - The new LNS offering, sitting on top of the Helium Foundation Type 6 NetID, would not issue rewards to Hotspots responsible for data transfer. @@ -32,9 +34,11 @@ As a broad overview, these bulleted sections highlight the impact areas and oppo This HIP affects all participants of the Helium IoT Network. The two most greatly impacted stakeholders are explained below. ### Network Users + Network users, as stakeholders in the new LNS, will benefit from a dedicated space for learning and testing. This LNS, which does not offer rewards for data transfer, aims to prevent misuse and maintain the network's integrity. Users will need to understand its different rules and purpose compared to the main Helium Network and adapt to its use limitations, including temporary device blocking. Their feedback will be important in shaping the future of this educational platform. ### Hotspot Operators + Data traffic passed through the special LNS would not be rewarded to Hotspots or their operators. However, the core intent of this service is to drive more users to the network. If successful, this would drive greater traffic for Hotspots and their operators. ## Detailed Explanation diff --git a/0103-oracle-hex-boosting.md b/0103-oracle-hex-boosting.md index 27197fdf3..9ae37009d 100644 --- a/0103-oracle-hex-boosting.md +++ b/0103-oracle-hex-boosting.md @@ -9,70 +9,78 @@ - Vote Requirements: veMOBILE Holders ## Summary: + This Helium Improvement Proposal (HIP) discusses how Oracle Boosting rewards are calculated and creates three (3) new Oracles: - Footfall Oracle - incentives deployments in areas that have heavy footfall traffic - Land Type Oracle - discourages deployments that cover empty fields and bodies of water - Urbanization Oracle - encourages deployments in urbanized areas - ## Prior Related HIPs -* [HIP-74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage. -* [HIP-84](https://github.com/helium/HIP/blob/main/0084-service-provider-hex-boosting.md) created Service Provider Hex Boosting. -* [HIP-85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) introduced penalties for overlapping CBRS coverage. -* [HIP-93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced Wi-Fi Access Points. +- [HIP-74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage. +- [HIP-84](https://github.com/helium/HIP/blob/main/0084-service-provider-hex-boosting.md) created Service Provider Hex Boosting. +- [HIP-85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) introduced penalties for overlapping CBRS coverage. +- [HIP-93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced Wi-Fi Access Points. ## Motivation: -HIP 74 was passed to incorporate obstruction data and radio signal power into the PoC reward model; however, it weighs all hexes equally, even if there's a low probability of actual coverage being needed in that area. This proposal aims to improve the value of the network coverage by incentivizing users to deploy CBRS and Wi-Fi in areas where Oracles have determined coverage is most likely needed. + +HIP 74 was passed to incorporate obstruction data and radio signal power into the PoC reward model; however, it weighs all hexes equally, even if there's a low probability of actual coverage being needed in that area. This proposal aims to improve the value of the network coverage by incentivizing users to deploy CBRS and Wi-Fi in areas where Oracles have determined coverage is most likely needed. ## Stakeholders: + The stakeholders of this proposal are: - **Service Providers & Subscribers** will benefit from increased radio/wi-fi coverage in more useful places - **Radio/Wi-Fi Deployers** can benefit from increased rewards for providing coverage in areas where coverage is needed ## Detailed Explanation: + MOBILE Boosting Oracles (refer herewith as “Oracles”) are data sources used to estimate how useful mobile coverage will be in a specific area. This HIP proposes allowing Oracles to be established to help guide deployments in areas that need more coverage. Oracles will be used to give applicable hexes boosts (increasing or decreasing) based on the area they are deployed in. -The data from each Oracle will be divided into categories and assigned a letter, beginning with A as the highest value and proceeding through the alphabet from there (B is the second highest value, C is the third highest value, etc.) based on the different types of locations that are delineated in the data. To avoid over complication, an Oracle shall not exceed X categories. +The data from each Oracle will be divided into categories and assigned a letter, beginning with A as the highest value and proceeding through the alphabet from there (B is the second highest value, C is the third highest value, etc.) based on the different types of locations that are delineated in the data. To avoid over complication, an Oracle shall not exceed X categories. The categories from each Oracle will then be combined to identify areas of overlap to create a set of subcategories. For example: If Footfall Oracle is A, Land Type Oracle is B, and Urbanization Oracle is A, then the hex will be assigned the tag ABA. Once all variations are accounted for, each tag will be assigned a value as outlined here: - ![Screen Shot 2024-01-09 at 4 37 11 PM](https://github.com/helium/HIP/assets/104723888/529d3ece-e685-498f-afdc-943e816fa9fc) - -Before the Final Multiplier equation is run, the calculations will check to see whether or not that res12 hex is boosted by a Service Provider greater than 1x. If not, then the assigned value will be maintained. If yes, then the Final Multiplier will automatically be 1X. +Before the Final Multiplier equation is run, the calculations will check to see whether or not that res12 hex is boosted by a Service Provider greater than 1x. If not, then the assigned value will be maintained. If yes, then the Final Multiplier will automatically be 1X. Once the Final Multiplier is calculated, this will be multiplied by any Service Provider Hex boosts, and then multiplied by the radio/wifi hex limit multiplier identified within HIP 85 and 105. The whole calculation is as followed: Final Multiplier X Service Provider Hex Boost Multiplier X HIP 85/105 Multiplier X Modeled Coverage Points from HIP 74/93. -### Footfall Oracle -This HIP recommends using data from third parties [Veraset](https://www.veraset.com/) and [SafeGraph](https://www.safegraph.com/), which identifies the level of footfall traffic in an area, and uses the method described [here](https://www.safegraph.com/guides/visit-attribution-white-paper) to determine areas that should have a higher multiplier based on their level of footfall. This data can be visualized on a map [here](https://shdw-drive.genesysgo.net/GANQ5D1hQVswq42Fk3vA3EYDddbNLLp1G2VmodQdprrF/index.html). This data is to be refreshed at least once per calendar year, but may be refreshed more frequently as new data from this source becomes available. Further, Nova Labs is able to add, but A process for suggesting changes to the data (e.g., increasing the level for a location like a hospital or school, or reducing a residential or farm area) will be considered in a subsequent HIP. +### Footfall Oracle + +This HIP recommends using data from third parties [Veraset](https://www.veraset.com/) and [SafeGraph](https://www.safegraph.com/), which identifies the level of footfall traffic in an area, and uses the method described [here](https://www.safegraph.com/guides/visit-attribution-white-paper) to determine areas that should have a higher multiplier based on their level of footfall. This data can be visualized on a map [here](https://shdw-drive.genesysgo.net/GANQ5D1hQVswq42Fk3vA3EYDddbNLLp1G2VmodQdprrF/index.html). This data is to be refreshed at least once per calendar year, but may be refreshed more frequently as new data from this source becomes available. Further, Nova Labs is able to add, but A process for suggesting changes to the data (e.g., increasing the level for a location like a hospital or school, or reducing a residential or farm area) will be considered in a subsequent HIP. + +### Land Type Oracle -### Land Type Oracle This HIP recommends using data from the European Space Agency’s [WorldCover project](https://esa-worldcover.org/), as visualized [here](https://viewer.esa-worldcover.org/worldcover/?language=en&bbox=-255.05859374999997,-78.6991059255054,255.05859374999997,78.69910592550542&overlay=false&bgLayer=OSM&date=2023-12-25&layer=WORLDCOVER_2021_MAP), to identify the type of land, and provide multipliers based on land type. New data from this source will be incorporated into the Oracle as it becomes available. This Land Type Oracle will also be smoothed out to the res10 level like the Footfall Oracle above. -### Urbanization Oracle -This HIP recommends using data from the United States Census Bureau's urban-rural classification, as defined [here](https://www.census.gov/programs-surveys/geography/guidance/geo-areas/urban-rural.html) and visualized [here](https://www.arcgis.com/apps/mapviewer/index.html?layers=10551da8fcd24062b1857473252b3df8), to provide multipliers based on if they are, or are not urbanized. New data from this source will be incorporated into the Oracle as it becomes available. This Urbanization Oracle will also be smoothed out to the res10 level like the Footfall Oracle above. +### Urbanization Oracle +This HIP recommends using data from the United States Census Bureau's urban-rural classification, as defined [here](https://www.census.gov/programs-surveys/geography/guidance/geo-areas/urban-rural.html) and visualized [here](https://www.arcgis.com/apps/mapviewer/index.html?layers=10551da8fcd24062b1857473252b3df8), to provide multipliers based on if they are, or are not urbanized. New data from this source will be incorporated into the Oracle as it becomes available. This Urbanization Oracle will also be smoothed out to the res10 level like the Footfall Oracle above. ### Smoothing of Data + As data from Oracles stem from third parties, the HIP authors recognize that there may be gaps or errors within the map and data used. Therefore, data from Oracles will be represented at a res10 hex level, and all res12 hexes within each res10 hex will have the same, highest value. For example, if one res12 hex within the res10 hex has a footfall range higher than 1.00, and all other res12 hexes within that res10 hex have 0, all res12 hexes within that res10 hex will be awarded for having footfall traffic of 1.01+ ## Deployment Impact -Nova Labs has agreed to undertake the work to implement this HIP shall it pass. + +Nova Labs has agreed to undertake the work to implement this HIP shall it pass. ## Drawbacks: -The implementation of this proposal could increase the complexity of the Helium Mobile network, and modeled coverage scores. There may be concerns about the accuracy of the population data provided, or the need to update the data regularly. + +The implementation of this proposal could increase the complexity of the Helium Mobile network, and modeled coverage scores. There may be concerns about the accuracy of the population data provided, or the need to update the data regularly. ## Alternatives -Alternative methods of how Oracles interact and calculated were explored during the community discussion phase of this HIP, but ultimately, having Oracle's multiply, add, or be weighted didn't allow for the fine tuning of the Oracles to mirror real world scenarios. + +Alternative methods of how Oracles interact and calculated were explored during the community discussion phase of this HIP, but ultimately, having Oracle's multiply, add, or be weighted didn't allow for the fine tuning of the Oracles to mirror real world scenarios. ## Success Metrics + The primary success metric will be greater coverage on the modeled coverage map in areas where top carriers have already identified as areas that need data. diff --git a/0104-finetune-hip17-parameters-to-tackle-density.md b/0104-finetune-hip17-parameters-to-tackle-density.md index b96be7884..635d73926 100644 --- a/0104-finetune-hip17-parameters-to-tackle-density.md +++ b/0104-finetune-hip17-parameters-to-tackle-density.md @@ -14,7 +14,7 @@ This proposal aims to modify the IOT LoRaWAN Networks HIP17's hex density-based ## Motivation -The motivation for revising HIP17 stems from the evolving landscape of the Helium network, particularly the rapid growth in the number of hotspots, especially in urban areas. When [HIP17 was initially implemented](https://docs.helium.com/devblog/2020/12/09/blockchain-release-hip-17/), its parameters were designed to scale down IOT Proof of Coverage (PoC) rewards with increasing hotspot density, allowing a certain level of redundant coverage. However, as the network has expanded over the years, these parameters have not been updated to reflect the changing dynamics. Consequently, this has led to an imbalance, with city centers, now densely populated with hotspots, garnering a larger share of PoC rewards. This disproportionate reward distribution is not conducive to expanding network coverage into rural areas, as it provides little incentive for deployers to install hotspots outside urban centers. +The motivation for revising HIP17 stems from the evolving landscape of the Helium network, particularly the rapid growth in the number of hotspots, especially in urban areas. When [HIP17 was initially implemented](https://docs.helium.com/devblog/2020/12/09/blockchain-release-hip-17/), its parameters were designed to scale down IOT Proof of Coverage (PoC) rewards with increasing hotspot density, allowing a certain level of redundant coverage. However, as the network has expanded over the years, these parameters have not been updated to reflect the changing dynamics. Consequently, this has led to an imbalance, with city centers, now densely populated with hotspots, garnering a larger share of PoC rewards. This disproportionate reward distribution is not conducive to expanding network coverage into rural areas, as it provides little incentive for deployers to install hotspots outside urban centers. The proposed adjustments to HIP17 seek to address this issue by recalibrating its parameters, thereby aiming to enhance the share of rural areas in the PoC reward pool and encouraging a more evenly distributed network growth. @@ -41,14 +41,15 @@ The current [HIP17 parameters](https://github.com/helium/HIP/blob/main/0017-hex- To address these issues, we propose the following adjustments: -* To reduce redundancy: - * Limit Res8 hexes (each covering only 0.78 sq km) to a single hotspot. - * Lower the hotspot limit, `max`, which is applied when more neighboring hexes become occupied. - * Increase the number of occupied neighboring hexes required to reach higher limits. -* To avoid unnecessary scaling in large areas and reduce sharp discrepancies: - * Increase the limit for res-4. +- To reduce redundancy: + - Limit Res8 hexes (each covering only 0.78 sq km) to a single hotspot. + - Lower the hotspot limit, `max`, which is applied when more neighboring hexes become occupied. + - Increase the number of occupied neighboring hexes required to reach higher limits. +- To avoid unnecessary scaling in large areas and reduce sharp discrepancies: + - Increase the limit for res-4. + +Here are the current and proposed sets of parameters: -Here are the current and proposed sets of parameters: ``` +---------------------------+----------------------------+ | As-is Parameters | Proposed Parameters | @@ -74,8 +75,9 @@ Here are the current and proposed sets of parameters: ### How to Evaluate the Performance To assess the effectiveness of the new parameter set compared to the existing ones, we've created a website that displays scales for different hex resolutions on a map. This tool allows users to observe changes in various cities and areas and understand the scaling of hexes and hotspots. The site is accessible at: -* Existing parameter set: https://heliumgeek.com/maps/hip17.html?p=default -* Proposed parameter set: https://heliumgeek.com/maps/hip17.html?p=t1 + +- Existing parameter set: https://heliumgeek.com/maps/hip17.html?p=default +- Proposed parameter set: https://heliumgeek.com/maps/hip17.html?p=t1 The maps demonstrate that urban areas generally experience more significant scaling down, and the previously sharp edges at res-4 boundaries are less pronounced. Example images are included at the document's end to illustrate this effect. @@ -103,7 +105,7 @@ The vertical axis indicates the number of Hexes with the corresponding value in -*PS: To estimate the reward distribution among hexes, we assume each active hotspot beacons regularly and is witnessed by an equal number of hotspots for simplification. This assumption allows us to propose that the sum of the transmit scales for hotspots within a hex is proportional to the reward units allocated to that hex.* +_PS: To estimate the reward distribution among hexes, we assume each active hotspot beacons regularly and is witnessed by an equal number of hotspots for simplification. This assumption allows us to propose that the sum of the transmit scales for hotspots within a hex is proportional to the reward units allocated to that hex._ ## Drawbacks @@ -111,7 +113,7 @@ Adjusting HIP17 parameters will alter the reward distribution among hotspot owne ## Rationale and Alternatives -The rationale for the proposed changes is detailed in earlier sections. +The rationale for the proposed changes is detailed in earlier sections. Alternatives include maintaining current parameters, which could exacerbate hotspot density imbalances, or introducing a new algorithm, potentially causing more disruption. We believe that refining the existing parameters is a more manageable, less disruptive solution, allowing for future modifications with greater ease. @@ -416,4 +418,3 @@ The primary indicator of success for these changes is increased network coverage

Istanbul - proposed params

- diff --git a/0105-modification-of-mobile-subdao-hex-limits.md b/0105-modification-of-mobile-subdao-hex-limits.md index 966d224ed..0427edec5 100644 --- a/0105-modification-of-mobile-subdao-hex-limits.md +++ b/0105-modification-of-mobile-subdao-hex-limits.md @@ -9,25 +9,26 @@ - Voting Requirements: veMOBILE Holders ## Summary: -This Helium Improvement Proposal (HIP) is an amendment of [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) to create separate Hex Limits for both Outdoor Wi-Fi and Outdoor CBRS. Each signal (Wi-Fi or CBRS) will have its own limits, meaning adding a CBRS signal to a res12 hex with pre-established Wi-Fi coverage will not negatively impact rewards. -The information within this HIP will supersede HIP 85 upon passing, thus creating one centralized HIP that documents Hex Limits for both Wi-Fi and CBRS deployments. +This Helium Improvement Proposal (HIP) is an amendment of [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) to create separate Hex Limits for both Outdoor Wi-Fi and Outdoor CBRS. Each signal (Wi-Fi or CBRS) will have its own limits, meaning adding a CBRS signal to a res12 hex with pre-established Wi-Fi coverage will not negatively impact rewards. +The information within this HIP will supersede HIP 85 upon passing, thus creating one centralized HIP that documents Hex Limits for both Wi-Fi and CBRS deployments. ## Related Previous HIPs -* [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage for the MOBILE subDAO. -* [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) implemented CBRS Hex limits. -* [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced the addition of Wi-Fi access points and certain limitations. +- [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) established modeled coverage for the MOBILE subDAO. +- [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) implemented CBRS Hex limits. +- [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) introduced the addition of Wi-Fi access points and certain limitations. ## Motivation: -The intentions of [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) was to limit Modeled Coverage Points (MCP) to the top 3 radio signals from CBRS radios; however, since HIP 85 only states "radio signals", and does not specify wether those signals come from CBRS or Wi-Fi, the HIP was implemented to only count the top 3 radio signals, regardless of source (CBRS or Wi-Fi) within each res12 hex. This HIP proposes to fix that, and allow up to three (3) CBRS radio signals and (3) Wi-Fi signals to earn MCP in each res12 hex. +The intentions of [HIP 85](https://github.com/helium/HIP/blob/main/0085-mobile-hex-coverage-limit.md) was to limit Modeled Coverage Points (MCP) to the top 3 radio signals from CBRS radios; however, since HIP 85 only states "radio signals", and does not specify wether those signals come from CBRS or Wi-Fi, the HIP was implemented to only count the top 3 radio signals, regardless of source (CBRS or Wi-Fi) within each res12 hex. This HIP proposes to fix that, and allow up to three (3) CBRS radio signals and (3) Wi-Fi signals to earn MCP in each res12 hex. ## Stakeholders: -Deployers - This HIP will make it more fair for deployers who are able to deploy a more optimal Wi-Fi AP and CBRS setup than current existing setups. -Subscribers - Subscribers may see more coverage of Wi-Fi access as this HIP will encourage Wi-Fi deployments to not be bunched together. +Deployers - This HIP will make it more fair for deployers who are able to deploy a more optimal Wi-Fi AP and CBRS setup than current existing setups. + +Subscribers - Subscribers may see more coverage of Wi-Fi access as this HIP will encourage Wi-Fi deployments to not be bunched together. Service Providers - If better Wi-Fi coverage is added due to this HIP, Service Providers will see an increased amount of data being offloaded onto the Helium 5G network. @@ -36,35 +37,36 @@ Service Providers - If better Wi-Fi coverage is added due to this HIP, Service P Please note, the passing of this HIP will supersede the 5 radio limit proposed in [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) and the 2 Wi-Fi limit in [HIP 101](https://github.com/helium/HIP/blob/main/0101-equalizing-poc-rewards-across-wifi-and-cbrs.md) (assuming HIP 101 passes). ### Indoor Wi-Fi -[HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) established a limit of one (1) indoor Wi-Fi AP per res12 hex will be eligible for PoC rewards. This will remain the limit for Indoor Wi-Fi APs. -### Outdoor Wi-Fi +[HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) established a limit of one (1) indoor Wi-Fi AP per res12 hex will be eligible for PoC rewards. This will remain the limit for Indoor Wi-Fi APs. + +### Outdoor Wi-Fi To ensure that only the best outdoor Wi-Fi setups are rewarded, only the top three (3) ranked signals of Outdoor Wi-Fi APs in each res12 hex will be awarded MCP, with a decaying multiplier based on the AP rank noted below. Any AP not ranked within the top three (3) will be ranked as “Fail”, and receive no MCP for that res12 hex. Please note, these ranks below are only assigned to Wi-Fi APs signals. Therefore, adding one (1) CBRS radio to this equation will not result in less rewards for Wi-Fi. -| Wi-F Rank |Multiplier | -|--------------|-------------| -| 1 | 1X | -| 2 | .75X | -| 3 | .25X | -| Fail | 0X | +| Wi-F Rank | Multiplier | +| --------- | ---------- | +| 1 | 1X | +| 2 | .75X | +| 3 | .25X | +| Fail | 0X | Please note that the multiplier table above only affects the MCP that are given to each Outdoor Wi-Fi AP and does not affect rewards distributed for the transfer of data. - ### Indoor CBRS Limits -This HIP proposes implementing a similar res12 hex limit established in [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) to CBRS Radios, whereas this HIP limits the amount of indoor CBRS radios per res12 hex to 1. Further, Coverage Claim Time (noted in the "Ranking & Criteria" below) will be used to determine which indoor CBRS radio will be rewarded PoC. + +This HIP proposes implementing a similar res12 hex limit established in [HIP 93](https://github.com/helium/HIP/blob/main/0093-addition-of-wifi-aps-to-mobile-subdao.md) to CBRS Radios, whereas this HIP limits the amount of indoor CBRS radios per res12 hex to 1. Further, Coverage Claim Time (noted in the "Ranking & Criteria" below) will be used to determine which indoor CBRS radio will be rewarded PoC. ### Outdoor CBRS Limits -To ensure that only the best outdoor CBRS setups are rewarded, only the top three (3) ranked signals of Outdoor CBRS in each res12 hex will be awarded MCP, with a decaying multiplier based on the AP rank noted below. Any AP not ranked within the top three (3) will be ranked as “Fail”, and receive no MCP for that res12 hex. Please note, these ranks below are only assigned to CBRS radio signals. Therefore, adding one (1) Wi-Fi AP to this equation will not result in less rewards for Wi-Fi. +To ensure that only the best outdoor CBRS setups are rewarded, only the top three (3) ranked signals of Outdoor CBRS in each res12 hex will be awarded MCP, with a decaying multiplier based on the AP rank noted below. Any AP not ranked within the top three (3) will be ranked as “Fail”, and receive no MCP for that res12 hex. Please note, these ranks below are only assigned to CBRS radio signals. Therefore, adding one (1) Wi-Fi AP to this equation will not result in less rewards for Wi-Fi. -| CBRS Rank |Multiplier | -|--------------|-------------| -| 1 | 1X | -| 2 | .75X | -| 3 | .25X | -| Fail | 0X | +| CBRS Rank | Multiplier | +| --------- | ---------- | +| 1 | 1X | +| 2 | .75X | +| 3 | .25X | +| Fail | 0X | Please note that the multiplier table above only affects the MCP that are given to each Outdoor Wi-Fi AP and does not affect rewards distributed for the transfer of data. @@ -72,34 +74,33 @@ Please note that the multiplier table above only affects the MCP that are given All Outdoor Wi-Fi APs and Outdoor CBRS radios that provide coverage to a single res12 hex will be given a Wi-Fi Rank and or CBRS Rank for each res12 hex they provide coverage in based on the following potential attributes (note, this rank is only for a single res12 hex and not the entire AP or radio): -- Modeled Signal Strength +- Modeled Signal Strength - Coverage Claim Time (Only used as a tiebreaker for Modeled Single Strength) If there are more than 1 Outdoor Wi-Fi AP with the same signal strength level, the `coverage_claim_time` value will be used to rank the top 3 oldest installations where `coverage_claim_time` is the timestamp when the Wi-Fi AP was asserted in that hex. The oldest Wi-Fi AP will receive the higher rank, while the newest will receive the lowest rank. To prevent rewarding "dead" Wi-Fi APs, we propose to reset `coverage_claim_time` if the Wi-Fi AP was not generating a Heartbeat for more than 72 hours and use the time of the last Heartbeat as the new `coverage_claim_time`. Note: As the Wi-Fi Rank and CBRS Rank are independent, adding CBRS coverage within a res12 hex that already has coverage from Wi-Fi will not impact earnings of the Wi-Fi signals. - #### Modeling Wi-Fi AP Ranking See the example below of how ranking based on a hex multiplier would affect deployment of five (5) Outdoor Wi-Fi APs and five (5) Outdoor CBRS radios if they are providing modeled coverage to the same res12 hex: -| Wi-Fi | Signal Strength | Coverage Claim Start Date | Wi-Fi Rank | MCP per HIP 93 | New MCP | -|----------|-----------------|---------------------------|------------|----------------|---------| -| A | -63.33 dBm | 01/01/2024 01:01:01 | 1 | 16 | 16 | -| B | -66.75 dBm | 01/01/2024 01:01:01 | 2 | 8 | 6 | -| C | -66.75 dBm | 02/12/2024 18:06:05 | 3 | 8 | 2 | -| D | -75.60 dBm | 01/02/2024 01:01:01 | Fail | 4 | 0 | - -| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 74 | New MCP | -|----------|-----------------|---------------------------|------------|----------------|---------| -| A | -77.33 dBm |05/01/2023 23:24:25 | 1 | 16 | 16 | -| B | -98.75 dBm |12/01/2022 01:01:01 | 2 | 8 | 6 | -| C | -98.75 dBm |12/02/2022 12:11:01 | 3 | 8 | 2 | -| D | -105.60 dBm |12/05/2022 11:51:01 | Fail | 4 | 0 | +| Wi-Fi | Signal Strength | Coverage Claim Start Date | Wi-Fi Rank | MCP per HIP 93 | New MCP | +| ----- | --------------- | ------------------------- | ---------- | -------------- | ------- | +| A | -63.33 dBm | 01/01/2024 01:01:01 | 1 | 16 | 16 | +| B | -66.75 dBm | 01/01/2024 01:01:01 | 2 | 8 | 6 | +| C | -66.75 dBm | 02/12/2024 18:06:05 | 3 | 8 | 2 | +| D | -75.60 dBm | 01/02/2024 01:01:01 | Fail | 4 | 0 | +| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 74 | New MCP | +| ----- | --------------- | ------------------------- | --------- | -------------- | ------- | +| A | -77.33 dBm | 05/01/2023 23:24:25 | 1 | 16 | 16 | +| B | -98.75 dBm | 12/01/2022 01:01:01 | 2 | 8 | 6 | +| C | -98.75 dBm | 12/02/2022 12:11:01 | 3 | 8 | 2 | +| D | -105.60 dBm | 12/05/2022 11:51:01 | Fail | 4 | 0 | **Table Key:** + - **Wi-Fi/CBRS:** Example Wi-Fi AP / radio name. - **Signal Strength:** The Signal Strength of the res12 hex from the modeled coverage explorer. - **Coverage Claim:** The date/time that the Coverage Claim period started. @@ -116,44 +117,44 @@ Since Wi-Fi AP and Radio B and C tied in Signal Strength, the Coverage Claim dat Since Wi-Fi AP and Radio D had the lowest signal strength out of all four (4) Wi-Fi AP, and only the top three (3) Wi-Fi AP will earn PoC rewards, Wi-Fi AP D will not earn any MCP for this res12 hex, and are ranked as "Fail". ### Outdoor CBRS Signal Interference Penalty + Too much CBRS overlap may cause interference, and may not provide the best or even usable experience for end users. Therefore, This HIP proposes that any res12 hex that has greater than five (5) outdoor CBRS signals shall not be awarded any modeled coverage points for that res12 hex that has greater than five (5) signals. See the examples below: As this res12 hex has 5 or less CBRS radio signals, this penalty will not apply. -| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 85| New MCP | -|----------|-----------------|---------------------------|------------|---------------|---------| -| A | -77.33 dBm |05/01/2023 23:24:25 | 1 | 16 | 16 | -| B | -98.75 dBm |12/01/2022 01:01:01 | 2 | 6 | 6 | -| C | -98.75 dBm |12/02/2022 12:11:01 | 3 | 2 | 2 | -| D | -105.60 dBm |12/05/2022 11:51:01 | Fail | 0 | 0 | -| E | -105.69 dBm |08/01/2022 05:01:59 | Fail | 0 | 0 | - -Since this res12 hex has 6 or more CBRS radio signals, no CBRS radio signals within this res12 hex will get rewarded ANY MCP. - -| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 85| New MCP | -|----------|-----------------|---------------------------|------------|---------------|---------| -| A | -77.33 dBm |05/01/2023 23:24:25 | 1 | 16 | 0 | -| B | -98.75 dBm |12/01/2022 01:01:01 | 2 | 6 | 0 | -| C | -98.75 dBm |12/02/2022 12:11:01 | 3 | 2 | 0 | -| D | -105.60 dBm |12/05/2022 11:51:01 | Fail | 0 | 0 | -| E | -105.69 dBm |08/01/2022 05:01:59 | Fail | 0 | 0 | -| F | -108.69 dBm |09/01/2022 06:05:01 | Fail | 0 | 0 | - - +| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 85 | New MCP | +| ----- | --------------- | ------------------------- | --------- | -------------- | ------- | +| A | -77.33 dBm | 05/01/2023 23:24:25 | 1 | 16 | 16 | +| B | -98.75 dBm | 12/01/2022 01:01:01 | 2 | 6 | 6 | +| C | -98.75 dBm | 12/02/2022 12:11:01 | 3 | 2 | 2 | +| D | -105.60 dBm | 12/05/2022 11:51:01 | Fail | 0 | 0 | +| E | -105.69 dBm | 08/01/2022 05:01:59 | Fail | 0 | 0 | + +Since this res12 hex has 6 or more CBRS radio signals, no CBRS radio signals within this res12 hex will get rewarded ANY MCP. + +| Radio | Signal Strength | Coverage Claim Start Date | CBRS Rank | MCP Per HIP 85 | New MCP | +| ----- | --------------- | ------------------------- | --------- | -------------- | ------- | +| A | -77.33 dBm | 05/01/2023 23:24:25 | 1 | 16 | 0 | +| B | -98.75 dBm | 12/01/2022 01:01:01 | 2 | 6 | 0 | +| C | -98.75 dBm | 12/02/2022 12:11:01 | 3 | 2 | 0 | +| D | -105.60 dBm | 12/05/2022 11:51:01 | Fail | 0 | 0 | +| E | -105.69 dBm | 08/01/2022 05:01:59 | Fail | 0 | 0 | +| F | -108.69 dBm | 09/01/2022 06:05:01 | Fail | 0 | 0 | ## Drawbacks: + Implementing this proposal will increase the complexity of modeled coverage scores due to adding additional variables used to calculate total MOBILE rewards. ## Rationale and Alternatives: + An alternative would be only allow the top three (3) radio signals between CBRS and Wi-Fi receive MCP per res12 hex; however, this may discourage the roll out of new outdoor Wi-Fi AP's - ## Deployment Impact: -As [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) has already been deployed by Nova Labs, Nova Labs is able to change the chain variables to implement this HIP. -## Success Metrics: -This HIP is successful if: General consensus is that the coverage ratio between CBRS and WiFi AP is “fair” and that multilayered coverage is achieved in an efficient manner. +As [HIP 74](https://github.com/helium/HIP/blob/main/0074-mobile-poc-modeled-coverage-rewards.md) has already been deployed by Nova Labs, Nova Labs is able to change the chain variables to implement this HIP. +## Success Metrics: +This HIP is successful if: General consensus is that the coverage ratio between CBRS and WiFi AP is “fair” and that multilayered coverage is achieved in an efficient manner. diff --git a/0106-hotspot-bidirectional-coverage-requirement.md b/0106-hotspot-bidirectional-coverage-requirement.md index 28667a7bc..0c158dd15 100644 --- a/0106-hotspot-bidirectional-coverage-requirement.md +++ b/0106-hotspot-bidirectional-coverage-requirement.md @@ -8,42 +8,49 @@ - Vote Requirements: veIOT Holders ## Summary + [summary]: #summary Hotspots that can not provide bidirectional coverage are not useful for the IOT network as well as pose gaming risks. These risks are currently mitigated by the denylist operated by Nova Labs. This proposal proposes to move the bidirectionality metric that is currently enforced by the denylist to the PoC pipeline. This will result in hotspot owners being signaled of the issue faster and subsequently will signal hotspot owners that the issue has been resolved without waiting until the next denylist iteration. ## Motivation + [motivation]: #motivation By moving the bidirectional coverage check from the denylist to the proof of coverage pipeline it will signal a hotspot owner of a problem significantly faster. The hotspot will also be considered for rewards significantly faster after the issue has been resolved. ## Stakeholders + [stakeholders]: #stakeholders All hotspot owners will be affected by this HIP. In particular hotspot owners that have hotspots that are unable to successfully witness or beacon. Two groups of hotspot owners are directly affected: the group of hotspot owners that is currently flagged for not being able to witness or beacon and the group of hotspot owners that experience such a failure in the future. The hotspot owners that are currently flagged for not being able to witness or beacon successfully will have a faster recourse if this proposal passes. The current denylist cadance is roughly 7 days whereas this proposal will determine if a hotspot supports bidirectional coverage much faster, thus offering faster recourse and feedback if such a failure is resolved. -The hotspot owners that will experience an inability to provide bidirectional coverage in the future will have faster feedback because they will stop being rewarded after the After resolving the issue the hotspot owner will not have to wait for the 7 day denylist cadence but instead will have immediate feedback that the issue is resolved as PoC rewards return. +The hotspot owners that will experience an inability to provide bidirectional coverage in the future will have faster feedback because they will stop being rewarded after the After resolving the issue the hotspot owner will not have to wait for the 7 day denylist cadence but instead will have immediate feedback that the issue is resolved as PoC rewards return. + +## Detailed Explanation -## Detailed Explanation [detailed-explanation]: #detailed-explanation **TODO**: _detailed implementation pending discussion with the oracle team to determine whether a rolling window is technically feasible. A rolling window is preferred over a epoch-by-epoch system because it decreases the time between a hotspot owner fixing the issue and rewards being reapplied. See the [Drawbacks](#drawbacks) section._ ### New invalid reasons `GatewayNoValidBeacons` and `GatewayNoValidWitnesses` + [detailed-explanation-new-invalid-reasons]: #detailed-explanation-new-invalid-reasons -There will be two new invalid reasons, `GatewayNoValidBeacons` and `GatewayNoValidWitnesses`. The invalid reason `GatewayNoValidBeacons` will signal a hotspot owner that the reason for not being considered for rewards is that the hotspot is not having valid beacons. Similarly, the invalid reason `GatewayNoValidWitnesses` will signal a hotspot owner that the hotspot is not having valid witnesses and therefore not considered for rewards. +There will be two new invalid reasons, `GatewayNoValidBeacons` and `GatewayNoValidWitnesses`. The invalid reason `GatewayNoValidBeacons` will signal a hotspot owner that the reason for not being considered for rewards is that the hotspot is not having valid beacons. Similarly, the invalid reason `GatewayNoValidWitnesses` will signal a hotspot owner that the hotspot is not having valid witnesses and therefore not considered for rewards. The invalid reason `GatewayNoValidBeacons` will take precedence in the case that a hotspot is both not successfully witnessing and not successfully sending beacons. When a hotspot is coming online for the first time or after being offline for a prolonged time its witnesses will be invalid with invalid reason `GatewayNoValidBeacons` until the first successfull beacon. ## Drawbacks + [drawbacks]: #drawbacks The main drawback of this proposal is that it increases the complexity of the `iot_verifier` oracle and the poc verification pipeline in general. As this proposal primarily moves an existing mechanism (currently as part of the denylist) to the oracle pipeline we believe that the increased complexity is less of a maintenance burden than the manual intervention needed in the denylist mechanism. ## Rationale and Alternatives + [rationale-and-alternatives]: #rationale-and-alternatives The alternative to this solution is to maintain the status quo where a hotspot is added to the denylist for at least 7 days and will have to wait until the next denylist iteration after the issue has been resolved. We think an automated system within the PoC pipeline is a better solution because it resolves some of the problems the community currently experiences. @@ -53,11 +60,13 @@ The alternative to this solution is to maintain the status quo where a hotspot i 3. The currently denylist is largely automated but it still requires amount of manual intervention which could be avoided by this proposal ## Unresolved Questions + [unresolved-questions]: #unresolved-questions There are two general implementation options: per epoch or a rolling window. The preferred method is a rolling window because this will enable a hotspot for rewards as soon as it successfully beacons. The way this proposal is implemented is pending discussion with the oracle team on the technical limitations of the oracles. ## Deployment Impact + [deployment-impact]: #deployment-impact When this proposal passes and is deployed the `iot_verifier` oracle will be upgraded to the version including the proposed changes. After the `iot_verifier` update is successfully deployed the denylist process will cease to include the `witness_reciprocity` metric the first denylist iteration _after_ deployment. @@ -67,6 +76,7 @@ The explorers will have to implement the new invalid reasons `NoSuccessfullBeaco The documentation will have to be changed to reflect the new invalid reasons `GatewayNoValidBeacons` and `GatewayNoValidWitnesses`. The documentation will have to include that `GatewayNoValidBeacons` takes precedence over `GatewayNoValidWitnesses` and that a hotspot becoming active after being offline for a prolonged time will have its witnesses invalidated with invalid reason `GatewayNoValidBeacons` until the first successfull beacon. ## Success Metrics + [success-metrics]: #success-metrics The intended result of this proposal is that hotspot owners are signalled about hotspots not providing useful coverage sooner as well as enabling hotspot rewards sooner after the problem is resolved. The main success metrics for this proposal are: