Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Calculate Location Trust Score from asserted distance in heartbeat HIP-119 introduces a new set of tables for location trust scores based on `(radio_type, distance_to_asserted)`. This also allows for a new minimum trust score multiplier of `0x`. * Remove use of max_distance_to_asserted This value is now contained within the function `asserted_distance_to_trust_multiplier` in the coverage point calculator. * Update test for increased allowable location trust multipliers All location trust scores used to be 1.0 or 0.25. HIP-119 adds 0.00 as a multiplier possibility based on distance. * typo in test name * Use lowest possible location trust multiplier value for bad case scenarios * Pass location trust to determine boost eligibility Location Trust Scores are no longer reduced based on the presence of a boosted hex. However, having an average distance from an asserted location past 50m can cause a radio to be ineligible for boosted rewards. * namespace location consts to provide more context Both constants have to do with service provider boosting in regards to a radios location trust scores. Namespacing allows for not needing to shove all possible context into a top level name. * make service provider boosting module It didn't feel quite correct to have half the service provider boosting code in lib.rs and the other in location.rs. The constants have to with location trust scores, but they do not get used there. * Remove trust score tests that expect score modification from boosting The distance to asserted no longer changes trust scores in the presence of a boosted hex. Service provider boosting eligibility is determined from the distance to asserted, that is tested at the top level of this crate. * Test Boosting does not apply when too far away * consolidate seeding heartbeats v1 and v3 The only difference was the location distance from asserted and assigned location trust multipliers. Refactoring heartbeat seeding further is left as an exercise to the next person who has a need to change these tests. * Test being too far from asserted location removes service provider boosting HIP-119 removes the part of calculating coverage points that degrades a trust score when a radio covers a boosted hex and is more than 50m away from their asserted location. Now, being +50m away from an asserted location makes a radio not eligible for receiving service provider boosted rewards. They continue to receive the full force of their location trust score. Being an Indoor radio 100m away from an asserted location is enough to keep a location trust multiplier of 1.0x, but not receive boosted rewards. * add hip-125 mentions in the docs * Try to link to relevant hips when possible Adding links to multiple places so you don't have to know a secret location where they exist. * Active boosting ineligibility takes precendence over passive ineligibility * Remove answered questions Both were answered yes * New location scores apply to Wifi only CBRS is always trusted for location. The location trust score is intercepted earlier when validating heartbeats. If for some reason CBRS radios do make it to this function, they will receive a good trust score anyways. * ServiceProvider -> SP for brevity * Fix updated Assignment enum -> OracleBoostingAssignment Assignment used to be a nested message inside the oracle_boosting_hex_assignment message. It's being referenced in mobile_rewards_v2, so it's been pulled out. * Add basic support for radio_reward_v2 in dumping mobile rewards * Add a getter for bytes per second use `as_bps()` instead of `into_inner()` for the symmetry with `as_mbps()` and to prevent compulsory use of `into_inner()` and wanting a different type. * Add helper crate for CoveragePoints -> radio_reward_v2 proto Put the cumbersome transformations in a helper crate to help keep transforming from a calculator CoveragePoints to proto a little neater. * Construct RadioReward and RadioRewardV2 for mobile rewards Both will live in the proto for a while until we fully move over to v2. To still be done is using the v2 reward for test assertions before we can fully move over. * apply auto-formatting to Cargo.toml * Use RadioRewardV2 in integration tests Until RadioReward v1 stop being output, we can compare the poc_reward fields of both version, they should be the same always. (maybe off by a bone, but that would be a special case indeed.) * Use RadioRewardV2 in unit tests * Move beacon closer to helium-proto Because `beacon` is in the helium-proto repo, when you want to test a different branch you need to update both entries. It is a convenience that they are moved closer together. * Update proto to branch with v2 rewards * Add notes about testing proto changes locally * Name mobile reward proto variables similarly and consistently A blank v2 looked confusing in the diff. * spell out var name, remove println * Update helium-proto to include hip-119 boosting ineligible reason HIP-119 added average distance to asserted further than threshold reason for a radio to not receive boosted rewards. * Prevent indexer from breaking when it encounters mobile_reward_v2 Both `mobile_reward` and `mobile_reward_v2` will be written out for 90 days. Within that 90 days, Indexer will switch to using `mobile_reward_v2` as the source of reward values, then `mobile_reward`s will stop being written. If both messages were used radios would be double rewarded. * proto back to master
- Loading branch information
1 parent
3e142e9
commit d24c9f6