Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

packet_router_packet_report_v1 tuning #271

Open
mikev opened this issue Jan 25, 2023 · 0 comments
Open

packet_router_packet_report_v1 tuning #271

mikev opened this issue Jan 25, 2023 · 0 comments
Assignees

Comments

@mikev
Copy link
Contributor

mikev commented Jan 25, 2023

The packet_router_packet_report_v1 represents an individual Uplink and will thereby represent billions or even hundreds of billions of packets. It will be worthwhile to tune the data structure to be more memory compact.

Note

All number types except fixed, double, and float are stored as
varints, meaning as long as your numbers stay in about the int8 or
int16 range, they are only 1 or 2 bytes, even though it says int32.

Current protobuf message

message packet_router_packet_report_v1 {
uint64 gateway_timestamp_ms = 1;
uint64 oui = 2;
uint64 net_id = 3;
// signal strength in dBm
sint32 rssi = 4;
// Frequency in hz
uint32 frequency = 5;
float snr = 6;
data_rate datarate = 7;
region region = 8;
bytes gateway = 9;
// Hash of payload within message packet
bytes payload_hash = 10;
uint32 payload_size = 11;
}

Add Uplink, Confirmed Uplink, Join enum named type.

Consider adding the packet header

net_id uint64 -> uint32
(The maximum net_id is 24 bits)

payload_hash
truncate to uint32 or uint64
a MIC is uin32 and is considered sufficient for LoRaWAN
consider directly using the MIC as there is no security issue instead of a generated hash
A MIC would also be future forward-compatible with the new MIC over payload hash.

I would propose replacing other values with uint16, but uint16 or unt8 is not supported by protobuf

The uint32 len followed by the protobuf msg is a little odd. It took me a while to figure out the structure, and especially since the len was little-endian encoded. I'm wondering if this structure wouldn't be better for the entire file:

message packet_router_packet_reports_v1 {
repeated packet_router_packet_report_v1 = 1;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants