Skip to content

Commit

Permalink
add msgs to support rolling averages for hexes and hotspots
Browse files Browse the repository at this point in the history
  • Loading branch information
andymck committed Sep 5, 2024
1 parent 376765f commit 716a8a4
Showing 1 changed file with 47 additions and 1 deletion.
48 changes: 47 additions & 1 deletion src/service/poc_mobile.proto
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,52 @@ import "mapper.proto";
import "hex_boosting.proto";
import "service_provider.proto";

message hex_data_counts_req_v1 {
// H3 resolution 10 hex tile
string location = 1;
// Average count of unique helium mobile subscribers active in the hex during

This comment has been minimized.

Copy link
@riobah

riobah Sep 10, 2024

Contributor

Is the average counts for a day?

This comment has been minimized.

Copy link
@andymck

andymck Sep 11, 2024

Author Contributor

Its a rolling count of the last 7 days

This comment has been minimized.

Copy link
@riobah

riobah Sep 13, 2024

Contributor

will we be getting data for all possible res10 hexes, every day? or maybe only those with data?
I'm trying to understand how we'll know the most recent snapshot of the network.

This comment has been minimized.

Copy link
@andymck

andymck Sep 13, 2024

Author Contributor

The plan is to output a report for any hex which has data during the previous 7 days

// the previous 7 days ( inclusive of discovery mapping subscribers )
uint64 helium_mobile_subscriber_avg_count = 2;
// Average count of unique helium mobile discovery mapping subscribers active
// in the hex during the previous 7 days
uint64 helium_mobile_disco_mapping_avg_count = 3;
// Average count of unique offload sessions active in the hex during the
// previous 7 days
uint64 offload_avg_count = 4;
// Average count of unique tmo cell tower sessions active in the hex during
// the previous 7 days
uint64 tmo_cell_avg_count = 5;
/// Unix timestamp in milliseconds of when the report was generated
uint64 timestamp = 6;
/// Pubkey of verification mapping service
bytes carrier_mapping_key = 7;
/// Signed payload of the verification mapping service
bytes signature = 8;
}

message hotspot_data_counts_req_v1 {

This comment has been minimized.

Copy link
@riobah

riobah Sep 10, 2024

Contributor

As there is CBSD ID field, I guess this message is for the radio data, not hotspot data. For CBRS hotspots with multiple radios, I guess we'll have multiple messages for the same hotspot.
maybe we should rename this as radio_data_counts_req_v1 instead?

This comment has been minimized.

Copy link
@andymck

andymck Sep 11, 2024

Author Contributor

yeah, I can change it to radio instead of hotspot. makes sense

// The onchain address of the gateway
bytes hotspot_pubkey = 1;
// the cbsd id of the radio if it is a cbrs radio otherwise empty
string cbsd_id = 2;
// Average count of unique helium mobile subscribers which have connected to
// the radio during the previous 7 days ( inclusive of discovery mapping
// subscribers )
uint64 helium_mobile_subscriber_avg_count = 3;
// Average count of unique helium mobile discovery mapping subscribers which
// have connected to the radio during the previous 7 days
uint64 helium_mobile_disco_mapping_avg_count = 4;
// Average count of unique offload sessions which have connected to the radio
// during the previous 7 days
uint64 offload_avg_count = 5;
/// Unix timestamp in milliseconds of when the report was generated
uint64 timestamp = 6;
/// Pubkey of verification mapping service
bytes carrier_mapping_key = 7;
/// Signed payload of the verification mapping service
bytes signature = 8;
}

message speedtest_req_v1 {
bytes pub_key = 1;
string serial = 2;
Expand Down Expand Up @@ -811,4 +857,4 @@ message verified_subscriber_verified_mapping_event_ingest_report_v1 {
subscriber_verified_mapping_event_verification_status status = 2;
// Timestamp in milliseconds since unix epoch
uint64 timestamp = 3;
}
}

0 comments on commit 716a8a4

Please sign in to comment.