Multiple netIDs on single network server?

Hi there,

Is it possible to run multiple netIDs on the same network server with Chirpstack?

Or we would need to run two separate network servers and then configure roaming between them?


Not possible to run multiple netIDs on the same network server

You can run two separate NS and configure roaming

That’s a shame.

Is it on the roadmap to add this at all?

Just to understand the question better, what would be the exact use-case you want to achieve? If you want to use multiple (LoRa Alliance assigned) NetIDs as your DevAddr prefixes, then I believe you could set the prefixes here:

  # DevAddr prefix(es).
  # This makes it possible to configure one or multiple sub-ranges within
  # the configured NetID. If left blank, then the complete DevAddr space
  # provided by the configured NetID will be used.
  # If multiple prefixes are configured, a random prefix will be chosen when
  # generating a DevAddr.
  # Example configuration:
  # dev_addr_prefixes=["0000ff00/24"]
  # This example configures the DevAddr range to 0000ff00 - 0000ffff.
  # The /24 means that the 24MSB of the prefix will be used, meaning that the
  # 8LSB will be used as address space.

I have not tested this, but I believe there is no validation (currently) that these prefixes fall within the prefix of the configured NetID.

Hey @brocaar thanks very much for the reply.

The basic use case is that we have 16 x type 7 netIDs from lora alliance.

So do you mean that we can just put one top level NetID, but then put the corresponding NetID devaddrs ranges and it doesn’t check they correspond to that defined NetID?

I have not tried it, but I think that should work. The only thing is if you have roaming enabled then everything which is not matching your top level net_id is considered roaming (and will be forwarded or discarded).

@brocaar I’m slightly confused by what you mean here.

We do have roaming enabled.

Does that mean we can’t use this same method you described?

There are two parts:

  • dev_addr_prefixes, this is used for generating the DevAddr on OTAA. If it is not configured, then the default prefix is derived from the configured net_id. The use-case was to use a sub-set within a single NetID.
  • net_id, this is the NetID of the network-server. If roaming is enabled, then a check is performed if the received DevAddr matches this NetID.

If we want to support your use-case, then the net_id configuration needs to change into net_ids (or maybe secondary_net_ids?), to make sure that uplinks are matched against all configured NetIDs. But this might have impact on some other places as well where the NetID is used. E.g. the join-accept contains a NetID field, I’m not sure how this then should work. Maybe setting this field to the NetID used to derrive the DevAddr from.

I think it will be good to have a primary net_id and secondary net_ids, because there are some places where a NetID is needed without DevAddr context:

This is currently not used by ChirpStack, but the Class-B beacons can also broadcast the NetID of the network. Broadcasting (e.g.) 16 different NetIDs doesn’t sound like a good idea.

As well when making API calls (fNS > nHNS), the fNS (ChirpStack) needs to specify a SenderID which should be equal to the NetID. I think in this case just the primary NetID should be used?