OUI restrictions and OUI 'advertising'

ChirpStack Network Server
1

I do not think this is part of any standard at the moment, so this might be about creating somethign new…

would it be possible / sensible at the Network server to be able to send OUI restriction lists to all the gateways, so they could filter which OUI’s are accepted/rejected. Sort of like a routing protocol of sorts…

This could be further extended for a network server to ‘advertise’ OUI’s, to other NS’s… You could in effect ‘peer’ between Network Servers…

1 Like
2

It’s a possible approach, sure. There is at least one unnamed proprietary LoRa implementation that does this by running a network server on each gateway. Personally, I care a lot less about using extra bandwidth to send unnecessary payloads than I do about the maintenance burden of filtering at the gateway level.

3

It turns out that “peering” between networks is done using records in DNS already. Its mentioned in this doc. I was reading this yesterday for a differnet reason, and came across that!

TTN is talking about this in ‘low bandwidth mode’ in the v3 gateway agent.

4

This is probably what the Basic Station is doing by filtering on NetID and JoinEUIs :slight_smile: V3 (a test version has been released) of the LoRa Gateway Bride does support sending this information to the Basic Station when the gateway connects, see the config example below:

    # Filters.
    [backend.basic_station.filters]

    # NetIDs to filter on when receiving uplinks.
    net_ids=[
      "000000",
    ]

    # JoinEUIs to filter on when receiving join-requests.
    join_euis=[
      ["0000000000000000", "ffffffffffffffff"],
    ]
5

are you refering to the TTN v3 stack?

Is this a Lorawan standard, or is it an ‘extra’ that TTN has added to their stack? If theres a standard i would rather do that, than reinvent something.

I’ve got data that needs to transverse LTE networks, and sometimes in places where there is quite a bit of other Lorawan traffic, I have one location, where 95% of the data is not interesting to me.

6

putting a Network server on each gateway is an ‘option’ but not one i want to pursue.

7

I’m referring to the LoRa Server LoRa Gateway Bridge component. This is a feature of the Semtech Basic Station forwarder: https://doc.sm.tc/station/tcproto.html#router-config-message

LoRa Gateway Bridge v3 (a test version is already available) implements the Basic Station interface.

8

oh ok, that makes sense.

Do you think this is going to become the ‘defacto’ way to set up this filtering?

9

That I don’t know, but potentially this feature could also be made generic on the LoRa Gateway Bridge so that it will be applied for all backends (Basic Station, Semtech UDP, …).

1 Like
10

Filtering on JoinEUI at the generic gateway bridge level would be a nice feature.

1 Like
11

Would you mind creating an “issue” for this at https://github.com/brocaar/lora-gateway-bridge? That way this feature-request does not get lost :slight_smile:

1 Like
12

Done, much appreciated.

1 Like
13

If its part of the LoRa Gateway Bridge, and your gateways are using MQTT over TLS, woudl this be an issue.?

14

Why would this be an issue?

15

I didn’t have a specific reason. The way I read this was that the ‘restriction’ for Net Id’s / Join Id’s was being done on a LoRa Gateway Bridge. However I didn’t think this quite through and had assumed it was a ‘centralized’ bridge where UDP packet forwarders were pointed to. I can see that this could be implemented on the gateway device as well. Thanks for the explanation. ( and this just needed some more time to think it through )…

Which component of the architecture would send the list of Net_ids / join_euis to the gateway bridge?

16

Ok, so some more reading. Looks like the gateways just need to periodically poll a ‘CUPS’ server via some http and get the relevent info. This doe’snt need to be integrated with the NS or anything. More details here
https://lora-developers.semtech.com/resources/tools/basic-station/the-cups-protocol/

17

I had a play with the example code and have a much better understand of how it works now. Is there any point in trying to integrate this with the NS? The NS, needs to know about its NetID; you doint’ really want to have to configure the same information twice?

18

Not sure to be honest. In some cases this might make sense, but ideally the LoRa Gateway Bridge should be able to work without a NS to provide an API to the gateway. Maybe for now it makes sense to keep this information in the lora-gateway-bridge.toml file.

Potentially CUPS, or other tools allowing you to do remote gateway management could help you to keep the gateway configuration in sync.

19

Thats a good idea, we can just pull the relevent NetID’s / JoinIDs’ from the config files. Easy, simple.
and just one place to configure it.

1 Like