Just to be sure I understand the TTN routing correctly: is it possible for an application with as handler ttn-handler-eu to get uplink payloads from a gateway with the router configured to ttn-router-us-west?
We have a customer owning a TTN gateway and an application with a ttn-handler-eu handler. If the customer sets the router to ttn-router-eu, device payloads are correctly processed by the application. But the gateway is located in Canada, so for latency its better to have the router configured to router-us-west. In that case the devices do join and upload there payloads, but these payloads are not received by the application anymore. Is this expected behavior? I would expect that a router in region X could feed an application in region Y.
This should work. In the public community network we route traffic globally. If the device is able to do an OTAA join while in a different region, regular uplinks should also work.
Hi, as my issue is similar iâll post it here in this old thread. Iâm using a Dragino LPS8 gateway in Hong Kong, configured for frequency plan AS923. Geographically Iâm about in the middle of the 3 TTN network servers (EU,US,AU) but Sydney is the closest, so i created my gateway and application (devices) in the TTN Australia 1 cluster, server au1.cloud.thethings.network
All works well, my nodes are joining and uplink data is visible in the console.
My worry is that other users in Hong Kong may choose to create their gateways and/or devices in the EU or US cluster, as this seems somehow arbitrary, and i was wondering if those devices (EU/US) would be able to use my gateway (AU), and vice versa, my devices their gateways.
Iâve done a simple test, creating an application and end device in the TTN Europe 1 cluster, and updated one of my nodes with that DevEUI, AppEI and AppKey, and it seems it cannot join via my gateway (AU). The gateway shows the JoinEUI uplink message but nothing happens after, thereâs no downlink. The node running an arduino-lmic example reports EV_JOIN_TXCOMPLETE: no JoinAccept, and EV_JOIN_FAILED
I noticed a device general setting âexternal join serverâ not enabled by default, but enabling this to au1.cloud.thethings.network does not seem to make a difference, and would not really be a solution.
So iâm afraid that it does not work as @htdvisser says it should, but itâs possible iâm missing something, and i assume it is easy to test for you, just doing something similar to what i did. Please let me know what you find, thanks!
@tomtobback thanks for bringing this old thread up.
The way it works is that we have three TTSCE (community) clusters; nam1, eu1 and nam1, the same three for TTSC (commercial) plus eu2, and we have three Packet Broker clusters that are serving Americas, EMEA and Asia Pacific. The Packet Broker clusters do all the routing between clusters, but there is no interconnection between Packet Broker clusters. So traffic from eu1 does not show up on au1 or nam1, but eu1 and eu2 works.
The short term solution is that people in all Asia use the au1 cluster for now. That region is connected to Packet Broker Asia Pacific which will be used for all Asian traffic.
The medium term solution is that we add one or two Asian clusters to provide enough saturation and clarity what to use where.
The long term solution is that we implement interconnectivity between Packet Broker clusters, so that traffic from the future as1 can flow to eu1 and nam1. We didnât do that for now because we donât see LoRaWAN devices to be roaming globally. But we will need it when bands are more harmonized (e.g. EU 915 MHz or LoRaWAN over 2.4 GHz) and for deployments that are in between Packet Broker Europe and Asia Pacific regions (like Russia and India).
There is a side case used for testing, for developers who need to quickly verify a âforeignâ setup.
You can use the channel plans outside your region on your own home cluster. So I currently have a 915MHz TTIG thatâs on AU_915_928_FSB_2 and an STM32 B-L072Z that mostly tests on EU channels but for about 10 minutes once in a blue moon is told to use AU_915_928_FSB_2.
Works in a similar fashion for NAM.
Obviously transmitting on the âwrongâ channels is illegal, so I put a tin foil hat on and keep it quick.
If I hadnât got myself a 915MHz TTIG I think Iâd still be debugging the ST LoRaMAC-node configuration 4 months on as it has no sense of the AU915 channel plan in its setup. This also applies to the Arduino MKR WAN 1300 & 1310 and indeed any module that uses the Murata ABZ.
Thanks @johan for the clarification, much appreciated. This would be a useful note on the TTN Cluster Picker page https://console.cloud.thethings.network/ to ensure that users in less common locations pick the right cluster. Is the associated cluster part of a gatewayâs metadata? If so, e.g. TTN Mapper could show, that would also help.
Looking at my gateway data, is there anything that confirms that received uplink messages are forwarded to the network server? Is that the meaning of the packetbroker/cluster events?
The first message is from my end node, the second one from an unknown device. Can i conclude from this that the second message is also forwarded correctly (i.e. is also using au1) or is it possible that this message is nam1/eu1 and therefore not reaching its network server via my gateway?
Good suggestion. I filed an internal issue for this.
It is, indeed. TTN Mapper could show it.
In this view, packetbroker means that the message has been forwarded to Packet Broker. Thereâs no feedback from Packet Broker shown in this view what has happened to the uplink message. Likewise, in this view, cluster means that the message has been forwarded to the Network Server in the cluster. It doesnât tell whether the NS has processed the message. We canât give a lot of context on whether NS processed the message from the gatewayâs perspective, because the gateway and any concerning device donât necessarily live in the same security domain (same collaborators).
What would be ideal is showing in the gateway traffic view whether a message has been successfully processed by any NS (via Packet Broker or local). Iâll think about that a bit more and see what we can do.
Well, I am not a commercial customer of TTI, but I fly high altitude balloons that roam around the world. It came as an unexpected surprise that my LoRaWAN end-node would not work when nam1 and au1 when registered on eu1 and vice versa.
It would be so much easier for the application engineer(like me) if we did not have to deal with differences between TTN server regions. It could have been easily been abstracted away such that end-nodes and gateways are registered on The Things Network(either commercial or community) and server location selection all handled behind the scenes.
You could have asked - and it would be fair to acknowledge that you are in a minority group of users so small that even Deadpoolâs new regenerating hand is large in comparison.
This is really a surprise to me. From our previous discussions I thought we should see the same tenant on different clusters as the same network, as they are connected. So apparently that is not true, and they are in fact different networks.
Itâs not as easy as it sounds. But it is our plan. We need something like this with LR-FHSS satellite coverage anyway. Plus itâs nice not to be bothered with different addresses all the time.
For now, different clusters are the three different zones that are not interconnected through Packet Broker. But once we add clusters to EMEA, they are interconnected. Same for Asia Pacific and Americas. What we donât have (yet) is that when end devices registered at nam1 show up on a gateway connected to eu1, that Packet Broker routes it to nam1. Again, there are little use cases for this, but it should be clear which cluster to use where (internal issue is filed for this), and there are use cases on the horizon so we will implement this.
This will indeed be very useful for now. Its unclear to me whether all Japanese/Korean/Hong Kong gateways and endnodes are registered on au1
I donât know if all Japanese/Korean/Hong Kong gateway/end-node owners who live in the middle of EU, US, AU are aware of this. More visibility for this ârulingâ will be appreciated.
My workaround is to assume the worst case scenario where some gateways in Korea and Japan are registered in eu1 and others on au1 so I transmit on end-node credentials registered on eu1 and au1 on alternate transmissions.
