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

LoRaWAN packet routing (HIP draft) #9

Closed
wants to merge 12 commits into from
Closed

Conversation

Vagabond
Copy link
Member

@Vagabond Vagabond commented Feb 14, 2020

Copy link
Member

@lthiery lthiery left a 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

# Motivation
[motivation]: #motivation

#Why are we doing this? What use cases does it support? What problems does it solve? What is the expected outcome?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete prompt perhaps?

0008-lorawan-routing.md Outdated Show resolved Hide resolved
@amirhaleem
Copy link
Member

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

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.


## 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.
Copy link
Member

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.

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.
Copy link
Member

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?

Copy link
Member Author

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


## 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
Copy link
Member

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.


## 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
Copy link
Member

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?

@lthiery
Copy link
Member

lthiery commented Feb 20, 2020

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.

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.

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
Copy link
Member

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?

Copy link
Member Author

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.

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
Copy link
Contributor

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?

Copy link
Member Author

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).

Copy link
Contributor

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?

Copy link
Member Author

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
Copy link
Contributor

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?

Copy link
Member Author

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.

@PharkMillups
Copy link
Member

This is mostly done. @Vagabond is going to give it one more review then we'll merge.

@jamiew jamiew added the draft label Jul 3, 2020
@jamiew jamiew changed the title LoRaWAN packet routing LoRaWAN packet routing (HIP8 draft) Aug 26, 2020
@jamiew jamiew added the stale Old and needs attention label Nov 3, 2020
@jamiew jamiew changed the title LoRaWAN packet routing (HIP8 draft) LoRaWAN packet routing (HIP draft) Nov 4, 2020
@jamiew
Copy link
Contributor

jamiew commented Dec 22, 2020

In the interest of keeping PRs moving, I am closing this as stale. Please re-open if you'd like to finalize and merge it for discussion.

@jamiew jamiew closed this Dec 22, 2020
@jamiew jamiew deleted the adt/lorawan-routing branch June 30, 2021 14:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
draft stale Old and needs attention
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants