Skip to content

packet_router_packet_report_v1 tuning #271

@mikev

Description

@mikev

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;
}

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions