Packet forwarding to multiple network servers

TTN Network and Services
1

Hello,

I have a Multitech Conduit gateway with the Multi-Protocol packet forwarder running on it. I installed it by following the instructions here.

I registered the gateway to both TTN (The Things Network) and TTI (The Things Industries). I configured the gateway to forward packets to both TTN and TTI back-ends and I can successfully see the gateway connected to both consoles. I am also able to see in the console both in TTN and TTI the traffic of the gateway.

What I want to achieve is to have an application with the same credentials (DevEUI, AppEUI and AppKey) sending their payloads more than one network servers. E.g. I have an application registered to TTN and I want to have the same on TTI or e.g on the open-source LoRa Server, Loriot etc.

I tried to register an application to TTI with exactly the same credentials with an application (OTAA) already registered and running on TTN. I tried to also restart the device so it can try to join the networks. I can only see the data flowing in TTN. I can’t see anything in TTI. Also, none of the gateways is dropping the packet.

The real question is: How can I make a device sending data to two different networks? Is that possible and how? Which method do I use? OTAA or ABP? Since I manage to have my gateway forwarding packets to two different network servers (endpoints) I get that the issue is the authorization for the device. One of the network endpoints just rejects the payload even if the application credentials (DevEUI, AppEUI, AppKey) are the same that the device uses to establish a connection.

Thank you very much.

Christos

2

The network prefix is different in TTN and TTI (and Loriot etc), so even with the same application credentials there is a difference in the packet.
Maybe at this hour my fantasy is exhausted, but it is not clear to me why you want this behavior. Do you have a use case in mind that could not be solved at the integration level?

2 Likes
3

For OTAA, even if both networks would accept the Join Request, the gateway can only transmit the Join Accept from one of them. That Join Accept defines the random session secrets (NwkSKey and AppSKey) and the DevAddr (with the network-specific prefix like @UdLoRa already noted). The networks won’t know each other’s randomly generated secrets, and won’t know which DevAddr was assigned either (if it would ignore the prefix).

Also, for downlinks a gateway needs to adhere to duty cycle regulations, which one, and only one, server should control; see Can the TTN Kickstarter gateway forward to alternative or multiple backend servers?

So: what you want won’t work.

2 Likes