-
Notifications
You must be signed in to change notification settings - Fork 408
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
LoRaWAN packet routing (HIP draft) #9
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a very nice solution to the problem of on-boarding devices with arbitrary credentials. While I believe we should focus on this routing scheme in the short-term, I would note that we have two paths to reduce Join latencies should that become a friction point for network usage:
- we could use a reserved DevEUI range to be a routing "routing mode" indicator; this would allow you to use part of the DevEUI or the AppEUI as a way to signal OUI/deviceID
- we could use the MType bit field to make a whole different message, either Join or normal message
0008-lorawan-routing.md
Outdated
# Motivation | ||
[motivation]: #motivation | ||
|
||
#Why are we doing this? What use cases does it support? What problems does it solve? What is the expected outcome? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
delete prompt perhaps?
We should be cognizant that no off-the-shelf LoRaWAN devices will work this way - we ideally want a solution that is compatible with any LoRaWAN device, not requiring any changes to their credentials or firmware. I'd argue overloading DevEUI is not much of an improvement over the current AppEUI hack we are using today. |
0008-lorawan-routing.md
Outdated
|
||
## What parts of the design do you expect to resolve through the HIP process before this gets merged? | ||
|
||
We need to nail down the permissible sizes of the XOR filters we want to store. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you will have to propose something here @Vagabond, I am not sure how to evaluate this.
0008-lorawan-routing.md
Outdated
We need to nail down the permissible sizes of the XOR filters we want to store. | ||
|
||
We need to decide if these routing table entries also contain a range of | ||
DevAddr entries to be used for routing of non-join packets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the tradeoffs here? If we don't pre-assign DevAddr's to OUI's, how would a Hotspot lookup the correct OUI on subsequent non-join uplinks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a second HIP to this PR that addresses DevAddr routing more thoroughly
0008-lorawan-routing.md
Outdated
|
||
## What related issues do you consider out of scope for this HIP that could be addressed in the future independently of the solution that comes out of this HIP? | ||
|
||
Pricing and availability of routing table entries for organizations operating |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The economics are out of scope here - will kick off a separate discussion/HIP on this.
0008-lorawan-routing.md
Outdated
|
||
## What parts of the design do you expect to resolve through the implementation of this feature? | ||
|
||
We need to define where/how these routing entries are stored, how they're |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to earlier comment I think you should propose a solution (or just start building for future review) - I'm assuming you are talking at the ledger/rocksdb level, and what the transaction structure should look like?
Right - the proposed solution here is great because it allows for arbitrary credentials and creates universal compatibility for off-the-shelf LoRaWAN devices. I'm just leaving notes on a few ideas on how to reduce latencies while remaining compatible with this proposed scheme; I am not suggesting either of those routes be considered for development today. |
Co-Authored-By: Louis Thiery <louis@helium.com>
the command in the README. The benchmark was first run on the Intel machine to | ||
generate the routing tables, run a second time to use the generated routing | ||
tables, and then the tables were copied to the Pi to run the test with the same | ||
databases (generating the tables can be quite RAM intensive, so it is unsuitable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will tables be updated then? Every time someone registers a set of IDs, someone has to do the work to generate and distribute the new table?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, so you'd likely want to batch updates.
0008-lorawan-join-routing.md
Outdated
XOR filter. Both the DevEUI and the AppEUI (totaling 128 bits together) would be | ||
hashed to a 64 bit key, this should help in cases of DevEUI collisions. | ||
|
||
A new ledger entity would be added to the blockchain, a 'routing entry'. These |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The language in the next few paragraphs is unclear. Is there one xorfilter per OUI or one big one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least one per OUI, for very large OUIs there might be several (so we limit the size of any single object we have to examine).
tables, and then the tables were copied to the Pi to run the test with the same | ||
databases (generating the tables can be quite RAM intensive, so it is unsuitable | ||
to be done on the Pi). | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to see some extension briefly discussing the process of generating the table or tables. Who do we trust to do this? How do we certify the validity of a table? How do we keep a customer from shooting themselves in the foot?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added something
milliseconds on an raspberry pi 3b+ in 32 bit mode. The smallest xor filter can | ||
be checked in well under a millisecond. | ||
|
||
In a more complete test, 10,000 OUIs holding device space for 50 million devices |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we doing anything clever here, or just checking them one by one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to do a linear scan, as far as I know.
This is mostly done. @Vagabond is going to give it one more review then we'll merge. |
In the interest of keeping PRs moving, I am closing this as |
Rendered view: https://github.com/helium/HIP/blob/c2f3ce61466b003731bb967959ca8b6e7706fca5/0008-lorawan-routing.md