Local netId 00/01 and TTN connection at the same time possible?

[LanMarc77]

Hi,
my use case is that I am currently having local devices with the experimental netIds 00/01 and at the same time forwarding everything else that is not 00/01 to TTN. I patched the packet forwarder for this to work but this has it’s own drawbacks with priority scheduling as discussed here.
As I understood from here one could get a netId subnet from TTN to have their own devices routed also from other locations (called home network). This might only make sense for installations with a lot of devices. I have 10 currently.
If I install a local v3 stack and only configure it in forward mode, would it be possible to keep NetId 00/01 inside my local network only but at the same time be able to handle TTN NetIds and forward them correctly?

[htdvisser (Hylke Visser)]

You can configure the Gateway Server to forward certain DevAddr blocks to the Network Server of your local cluster and forward (the same or) other DevAddr blocks to Packet Broker. See the configuration reference of the Gateway Server for more information.

You can also configure the Network Server to issue DevAddrs from certain blocks. See configuration reference of the Network Server for more information.

For what you want, that configuration (in yaml) would look a bit like this:

# ...
gs:
  forward:
    cluster: [ "00000000/6" ]
    packetbroker: [ "26000000/7" ]
# ...
ns:
  net-id: "000000"
  dev-addr-prefixes: [ "00000000/6" ]
# ...

[Jeff-UK]

@htdvisser Hylke, we had deeper discussion wrt handling of 00/01 here

Why is uplink message forwarded twice by V3 gateway?

I see a reasonable number of packets arriving on my gateways with NetID = 0x00 rather than 0x13. Reading more detail on Packet Broker I can see the Network Server uses this to determine if it will process the packet or hand it off to Packet Broker to deal with. The application is currently working on V2 with all packets being processed and forwarded to the Application Server. Wondering if you clarify how V3 will handle the packets with NetID = 0x00 as the Australian Community may need to adv…

and down through the thread. TTN V2 handles/shows 00/01 device messages and has proven very useful to many per example use case lower down that thread… will that continue to be the case in TTN V3. (Noting in this case that 00/01 is the ‘universal’ definition of experimental nodes under L-A and isn’t unique to use by just one user as suggested/implied in OP above.)

[htdvisser (Hylke Visser)]

@Jeff-UK I also commented on that thread:

Why is uplink message forwarded twice by V3 gateway?

We have configured all The Things Network clusters such that all traffic that is received by gateways connected to a certain v3 cluster will be offered to the Network Server of that same cluster. Packet Broker does not route NetID 0 (because nobody owns that NetID), so if your gateway is connected to one (v2 or v3) cluster, you will not receive uplinks for DevAddrs 00000000/6 in another cluster.

The configuration of eu1.cloud.thethings.network looks like this:

# ...
gs:
  forward:
    cluster: [ "00000000/0" ]
    packetbroker: [ "00000000/0" ]
# ...
ns:
  net-id: "000013"
  dev-addr-prefixes: [ "260B0000/16" ]
# ...

This means that while the eu1 Network Server will only issue DevAddrs from block 260B0000/16, the eu1 Gateway Server will forward all traffic to the eu1 Network Server, which will try to match that to any devices registered in the eu1 cluster.

[Jeff-UK]

@Why is uplink message forwarded twice by V3 gateway?

you will not receive uplinks for DevAddrs 00000000/6 in another cluster.

Can appreciate PB may not process or transfer say V2 to V3 or vice versa, however if GW in TTN V3 EU1 cluster, will V3 still handle/show 00/01 traffic or is that capability being lost (appreciate PB wont know where to route to so handling through PB not an option). Does the use case I outlined - simple GW mapping using live data - break?!

[LanMarc77]

Ah ok.
I understood, that data can come in via a packet forwarder connection directly to TTN via there endpoints. In this case everything should be seen in the gateway tab, as the gateway is registered directly with TTN (unless someone filters at the packet level, like I described).
If someone routes packets via a packet broker connection no 00/01 are seen at all, as first no gateway is registered within the TTN stack and second packet broker would not know to which home network/server the packet should be routed as no one/everyone owns it.
So finally it depends on how someone connects to TTN if 00/01 is visible or not. I also read somewhere (I think even from you) that packets coming in from gateways connected via packet broker are also (currently) not displayed in the TTN map. From what I have understood of the current packet broker API this should be possible as mapping.proto seems to contain these information.
For my use case the packet broker is probably the most reasonable technical solution as I want to host a local only stack that works also without internet connection.
@htdvisser How would I connect to packet broker if I would only like to be a forwarder for everything but do not have a home network (own netId), except 00/01 which is not forwarded? Would I need to pay to have access?
Thank you all for all these explainations.