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?
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" ] # ...
@htdvisser Hylke, we had deeper discussion wrt handling of 00/01 here
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.)
@Jeff-UK I also commented on that thread:
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
eu1 Gateway Server will forward all traffic to the
eu1 Network Server, which will try to match that to any devices registered in the
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?!
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.